Yes, we're relevant; here's an acronym to prove it

Last year at this time, IBM foisted a new acronym on this acronym-fatigued world, called Services Oriented Modeling and Architecture (SOMA). Gartner laid something on us called SODA (Service-Oriented Development Architecture), and if that wasn't enough, brought us SOBA, or Service-Oriented Business Applications.
Lately, Cisco has thrown its own acronym into the ring, as a way of making it known that it does not intend to be marginalized at the SOA party. In December, the networking giant began promoting something it calls its Service-Oriented Network Architecture (SONA), which is a framework that the vendor has intertwined with a set of offerings called "Application Network Services (ANS)," all designed around "building an intelligent information network" in the enterprise.
SONA networks are based on a three integrated layers, including an application layer, networked infrastructure layer, and an interactive services layer. The SONA framework, Cisco says, "is the common platform that transparently connects and enables all components of IT infrastructure."
However, at least one industry observer questions what SONA can bring to the SOA table. Frank Dzubeck, writing in IT World Canada this week, wondered out loud if SONA might muddy the SOA waters further than they are already muddied:

"At first glance, SOAs and SONA can coexist; one is applicable to software, and the other to networking. Unfortunately, SONA will, in all probability, complicate and inhibit an optimized SOA deployment. If Cisco is intent on moving functions that formerly resided in software into the network and performing compute/server virtualization and management in SONA, then any corporate benefits derived from the implementation of a dual SOA/SONA may be limited."

Dzubeck notes that two recent SOA initiatives -- Service Component Architecture (SCA) and Service Data Objects (SDO) -- address application virtualization across networks, and that Cisco is not involved in these initiatives.
IDC' Frank Gens, however, begs to differ from this analysis, noting that SOA can play just as vital a role in operations as it will in development and integration. "Almost nothing makes me crazier these days than when people talk about SOA as if it’s just about delivering development and integration flexibility to business applications (by SAP, Oracle, et al.)," Gens said. "SOA is also the core principle behind the rearchitecting of the IT operations world."
In a recent Weblog post, Gens points to SONA as a perfect example of the role of SOA in IT operations:

"The announcement was pretty high-level and conceptual, but Cisco’s main goal was to tell the world (especially CIOs) that Cisco’s products will increasingly be designed and delivered to play in an SOA world. For Cisco, the SONA announcement is a way to say that they understand CIOs’ focus is certainly not about "making the network more intelligent"; it’s about delivering end-to-end functionality (a.k.a., services) – across all the major IT assets (servers, networks, information, applications, etc.) – to support critical business processes."

SONA "aligns with CIOs’ goal of making their operations 'service-oriented,'" Gens adds. The bottom line to the SONA positioning, says Gens, is that it aims to "make Cisco more relevant to the CIO’s agenda; by reorienting its products around a CIO’s services-oriented perspective.  Cisco is not emphasizing that it’s delivering a "smarter router", but that it’s delivering 'service-level management' that may happen to be more efficient or easier to deploy because it sits on the network."
Still, Dzubeck can't contain his skepticism, asking:

"What modeling and development tools exist to blend SOA and SONA services into the business process? How does a corporate business application request a SONA service if it is not an SOA service? How can end-to-end virtualization or workflow-performance optimization occur in a multivendor SOA/SONA environment? Will SONA be compliant with future SCA and SDO industry standards — and what are the industry standards applicable to SONA? Will SONA have a network service bus similar to an SOA’s ESB? An SOA can be deployed using both insourced and outsourced infrastructure; can SONA be deployed in a similar manner? Is SONA a creation of hubris or bad 'marketecture'?"

Both Gens and Dzubeck point out that so far, Cisco is vague about the specifics behind SONA. But perhaps Cisco is taking a page from Microsoft's playbook in assigning its own acronyms to product sets.