COMMENTARY--The organization able to correctly identify the winners and losers among evolving technologies will benefit from lower cost of operations, reduced complexity of the computing environment and improved readiness to respond to new business requirements. What characteristics make Service Oriented Architecture (SOA) one of those technologies destined to survive, and how can SOA be successfully implemented? Technology pundits like to talk about SOA as if it were a new idea. But seasoned technology practitioners know better. SOA is really the latest stage in a gradual evolution of ideas that began in the early 1980s within the Object Oriented Programming community, and continued into the 1990s in other communities such as DCE, COM/DCOM, CORBA and J2EE.
One of the common elements to every “species” of architecture that has survived during the past 20 years has been an underlying set of technology standards. For example:
• Networked computing is based upon Ethernet and TCP/IP
• Distributed databases depends on SQL
• Web enablement requires HTML and HTTP
By contrast Enterprise Application Integration (EAI) is not based upon any standard, and has largely failed (one prominent trade publication covering the genre has even taken “EAI” out of its name).
SOA will likely prevail because it is based upon Web services, and the primary technology standard supporting Web services is XML. Even Microsoft recently proclaimed that XML is the most important standard in the next 10 years. Every document created in .NET is in XML. And major vertical industry data standards are also now organizing around XML: HL7 in healthcare, SWIFT in banking, CIDX in chemicals and Rosettanet in high tech, among others.
The realities of SOA adoption
While SOA promises to be far less costly and time consuming to implement than non-standards based architectures such as EAI, organizations still need to have realistic expectations.
First, you will stub your toe a few times when applying SOA because of its overall lack of maturity. It will require patience and a willingness to learn. Anyone involved in networking in the late 1980s remembers the challenges associated with making Ethernet and TCP/IP products from different vendors work together.
Second, organizations need to fight the instinct to use SOA to “boil the ocean.” Just as the temptation with CORBA was to turn everything into an object, so the lure with SOA will be to turn everything into a service.
Because of these realities, a flexible process is required to overcome the glitches of early adoption while at the same time moderating the natural tendency to overreach.
"T3P": A process for SOA implementation
When implementing SOA keep in mind the acronym "T3P," which represents four essential ingredients for success: technology, training, tools and projects.
Technology: Your technology must be able to interact with current open standards. XML enabling your systems is one way to provide a standards-based transport, management and storage format for all structured data and unstructured content within the organization.
Tools: Don't try to handcraft everything; invest in a set of standards-based development tools that will serve the organization for the long term.
Training: Assign your most skilled and experienced people to the first project--specifically those who have experience with n-tier architecture. See that these people are well trained on the standards-based tools you have selected. Success or lack thereof on the first SOA project will lay a foundation for future SOA projects within the organization. (Hint: one key indicator of success will be thorough documentation at the end of the project.)
Projects: To maximize the replicability of SOA as well as generating measurable benefit, begin with a single project that lends itself to SOA implementation. This project can be narrowly or broadly defined.
For example, in a well-known financial institution a change of address for a client required 300,000 lines of code spread across 30 systems. The organization applied SOA to that one specific function. As a result, change of address was reduced to a total of 20K lines of code, providing better service to the customer and reducing the burden on IT by decreasing the amount of code that needed to be maintained across the organization.
Conclusion
Once an organization has made the decision to meet the challenges associated with implementing a SOA, has selected an appropriate project, has assigned the best talent and given them the right tools, and has set proper expectations with leadership, the benefits can be tremendous. They include a lower cost of training developers, reduced dependence on proprietary technologies and the ability to quickly create new internal and external data services – as well as cost benefits that multiply as the technology propagates through the organization.
Because SOA, Web Services and XML share the essential qualities of their long-lived predecessors, they will not only survive, but have the potential to change the way that systems are built and connected within and between organizations. As with successful architectures and standards of the past, skillful and appropriate implementation should bring about a phenomenal payoff for an organization.
biography
William (Bill) Ruh brings more than 17 years of industry experience and an expertise in enterprise application integration and object technology to Software AG, Inc. He's currently Senior Vice President, Professional Services.
