Having seen many vendor presentations announcing new products and strategies recently, I’ve noticed a common thread. The IT world has embraced the concept of total multivendorism based upon agreed-to industry standards. Corporate IT chooses vendors based not on incumbency but the age-old metric of price/performance combined with ROI and total cost of ownership. Integration, legacy application encapsulation and database federation have become software mantras. Data centre consolidation has become a business issue, not an IT nightmare. Evolving a corporation into the world of service-oriented architectures (SOA) requires corporate commitment to business process and organizational changes that may have a far greater impact than IT technology changes.
The SOA concept, while business driven, is based upon the way we look at information and IT services. The IT industry has strived to eliminate vendor lock-in at any layer in the architecture. Decoupling of the layers using Web services instead of procedural calls creates a virtualized model from the application to the infrastructure layer. Information is divorced from computation and transmission. The theory is simple yet powerful and elegant. The execution is another matter.
As the SOA concept developed, issues began to surface. Security and management for Web services were the obvious first pain points. Industry forums quickly were created and populated with representation from all major vendors. The issues were addressed and standards published. The same approach was taken to create a service component architecture, which will provide a model for constructing and assembling a network of services. This will allow multivendor middleware enablement software, as well as application software, to interact at the component level.
The next creation was service data objects (SDO) that provides common access to data. SDOs make it easy to manage and exchange data across services with heterogeneous formats. The most recent SOA fix is the ability to federate and access/share information across multivendor configuration management databases (CMDB) and other data repositories. CMDB federation will give corporations another guarantee for choice and flexibility in terms of adding new IT hardware, applications and middleware, in addition to assisting with corporate compliance and governance issues.
Building a corporate SOA is like building a cathedral. It may take years to accomplish, but the business rewards can be magnificent. IT vendors are committed to making SOA simplification a reality through multivendor technological agreements that are the burden of vendors, not customers. They realize that the size of the IT pie always will increase proportionally to business productivity and growth, and they all can share in that increase. We in the network and communications world seem to be on a totally different path than our IT brethren. At a recent industry analyst presentation, Cisco equated simplification to fewer vendors and offered slide after slide to prove how complex it is to manage and operate any network in a multivendor environment. Is the network industry that different from the IT industry?
IT vendors have learned to cooperate and get results outside of standards organizations. The IT industry informally agrees on a problem, formally addresses the problem by a division or work/responsibility and then takes it to a standards group ready for implementation. Even then, customers may delay or never employ the standard, as with SNMPv3 and IPv6.
After years of proprietary focus, voice communications vendors realize that embracing SOA requires a new multivendor perspective. They are no longer in control of their strategic destiny but are part of the bigger SOA picture.
Similarly, all software-based network and communications vendors must comply with SOA tenets or be rele
