5 Reasons Why Cisco's SONA Will Fail

User Rating: / 1
PoorBest 

How big can a company get before it fails to connect with its core constituency?

Cisco's Services Oriented Network Architecture strikes me as being one of those warning signs that the vendor has lost its way.

The parallel is the IBM SNA environment and its 'leap' from centralized hierarchical to distributed networking (but in a controlled way) called APPN in the early 1990s. 

In those days, IBM SNA was the dominant networking architecture for computing systems which were being challenged by the PC and the LAN and the router, a specialized multi-protocol routing appliance.

APPN involved a new class of technologies that seemingly allowed SNA control over the LAN-LAN environments, which for a fee (or tax) would be more orderly than the nilly-willy approach of the router. Well, APPN did not attract the attention of the SNA installed base, who were gradually removed from the scene by the Cisco router specialist.

SONA, Cisco's network-centric approach to Services-Oriented Architecture, seems to miss the mark for me, and reminds me of the APPN issues of the early 1990s. So, instead of the well reasoned blog entries elsewhere on this site, I thought I'd kick start the dialog around the idea of a list.

At the heart of the SONA is Cisco's Application Control Engine. Cisco acquired Reactivity in February 2007 for $135 million and integrated the XML appliance into the Catalyst switching line where the ACE performs XML traffic analysis, protocol mediation and offloads other IT infrastructures from the burden of XML processing.

1. SONA is proprietary and (cynically) exists to sell more Cisco boxes. Cisco was the greatest beneficiary of the 'rise of the stupid network' and injecting the network with intelligent service processors is counter-intuitive to the ubiquitous availability of IP bandwidth.

2. SOA is about abstracting applications into constituent parts that are published for new kinds of applications or mashups to access and activate at the appropriate time and scale. In this way, developers can pick and choose the processes, information, people and workflows that are energized at different times and stages of the process to create solutions to problems that exist between the major applications of the business.

3. SONA processes those flows locally enabling