Now that 2006 is upon us, it's time to revisit one of my favorite topics: service-oriented architecture (SOA). Based on industry buzz, I felt that 2005 was going to be the "Year of the SOA," and there truly was tremendous SOA activity last year. Many SOA technology vendors were acquired by large incumbents such as Oracle, BEA, and IBM. More startups have emerged to fill various seams in the emerging SOA technology stack. And end-users are really trying to understand SOA and the requirements for successful migration to reusable interoperable services. Let's explore a few of the big SOA ideas to set the stage for 2006.
SOA governance has emerged as a mission-critical facet of SOA. SOA governance establishes the organizational model, processes, and policies and standards upon which an SOA will be based in a given organizational setting. It also defines budgeting and service ownership guidelines for an organization, and it ultimately specifies a body of policies that, when enforced through various governance processes, will drive conformance to the standards and guidelines that help ensure interoperability of services in the SOA.
While SOA governance is recognized as a critical element, many organizations confuse the process of governing with the implementation of governance. Many IT executives recognize the need for SOA governance and acquire a service registry to implement it. Yet buying a service registry, or any product for that matter, does not deliver it. Not even close. SOA governance is an organizational operating model and process that enables the definition, management, and enforcement of SOA policies.
SOA governance can be implemented manually via normal design reviews, project approval, and budgeting meetings, as well as other organizational institutions. It can also be implemented via automated solutions during service development, publishing and discovery, and at runtime. But before implementation, SOA governance must be defined from the perspective of an organization's processes and policies, and then enforcement must be implemented using a combination of manual and automated solutions.
Another SOA term that continues to gain momentum is the enterprise service bus (ESB). Since this term was coined a few years ago, ESB has emerged as a leading solution for enterprise application integration (EAI), Web services runtime support, intelligent routing, and transformation.
ESBs are hailed as the next generation of application integration platforms, except that they are more standards-based and less expensive than traditional EAI solutions. ESB is one possible component of an SOA-enabling technology stack, and an important one at that.
Now that ESB is legitimate, BEA has introduced an ESB in its AquaLogic suite, IBM has introduced its version of an ESB (whose DNA may be based on the old Crossworlds suite it acquired years ago, dusted off and gussied up...), and you can expect more to come.
The ESB hype is problematic, though, because many of the vendors would have you believe that if you buy their ESB, you will have an SOA. This is simply not true. SOA is all about the services, or the Web services, that deliver business functionality to consumers. An SOA is nothing without that fundamental asset: services. Focus on the services first, and the technology decisions will be easy. Don't reduce your SOA to an ESB, but plan for one once you understand your services requirements.