For the past 40 years, networking within the corporate world has evolved in synch with IT. This may or may not change in 2006, depending on whether you believe the vision of Cisco or the IT industry. Computing concepts in the IT industry have evolved over the past four decades from centralized to distributed to client-server to network-based to peer-to-peer to service-oriented.
Within a service-oriented architecture (SOA), the infrastructure building blocks of computing, storage and networking form the foundation. Cisco has challenged this concept by creating its own vision, called Service-Oriented Network Architecture (SONA), in which the network is the foundation for all IT, acting as the glue that holds together every aspect of IT infrastructure — clients, servers and storage.
This is not just an arcane philosophical issue; it is fundamental to how to design, implement, operate and manage a corporate SOA. Based on industry standards, SOA is a multilayer framework that allows all computing concepts to exist in a single architecture with a one mission: technological implementation of the corporation’s business processes.
To achieve this, application-to-application intelligence will be distributed throughout the business process chain, including the corporation, customers, suppliers, and sales and distribution channels. In this architecture, the corporate network becomes the physical “nervous system” that links all third parties with corporate IT, and the enterprise service bus (ESB) becomes the logical electrical signaling for communications.
To complicate the issue, a Cisco service is not a SOA service. A SOA service is defined as reusable software components with well-defined, published, standards-compliant interfaces that perform a specific function on behalf of a computing entity, such as a user or another software component. A SONA service has higher granularity from a software perspective, may or may not be reusable, has no published APIs, is vendor-specific, and performs an interactive communication function between applications and infrastructure.
Last month, two new SOA initiatives were put in place that will allow application virtualization to occur across a network: Service Component Architecture (SCA), created as a model for constructing and assembling networks of services; and Service Data Objects (SDO), created to define a common access methodology to data. SCA and SDO are multivendor IT industry initiatives that have no Cisco representation and will create further differentiation between SOA and SONA.
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 or server virtualization and management in SONA, then any corporate benefits derived from the implementation of dual SOA-SONA may be limited.
From a corporate IT perspective, SONA produces more questions than answers. 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 isn’t a SOA service? How can end-to-end virtualization or workflow performance optimization occur in a multivendor SOA or 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 SOA’s ESB? SOA can be deployed using both insourced and outsourced infrastructure; can SONA be deployed in a similar manner? The questions go on and on.
But one final network industry and corporate IT question needs an answer: Is SONA the creation of hubris or bad “marketecture?”
QuickLink: 064970
–Dzubeck is president of Communications Network Architects, an industry analysis firm in Washington, D.C. He can be reached at [email protected].
