One of the more poignant points established in 2008 & 2009 regarding Service Oriented Architecture (SOA) is that success is heavily predicated on the establishment of a solid governance strategy. While SOA success can be achieved without implementing a governance strategy, the likelihood is reduced due to the potential for missing the main target, which is the development of a single approach for delivering a service. Consequently, the IT Service Management Forum’s IT Infrastructure Library (ITIL) defines a framework of best practice guidance for IT Service Management, which is a framework for the governance of IT, and version 3 of their framework, while developed specifically for IT, can be used as a general governance strategy for SOA.
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. Based on their perspective, they would be correct since V2 focused more heavily on operational processes rather than service lifecycle. With ITIL V3, the focus of the framework shifted toward what can only be accurately described as service-orientation. The five core books of ITIL V3 are aptly named: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement; illustrating ITIL’s understanding of the service-oriented lifecycle.
The Role of Governance in SOA
Since there is no single, definitive resource regarding SOA, the term SOA has been commandeered to represent the interests and agendas of many; such is the problem of de jure standards. That said, there’s enough literature on the topic that when analyzed statistically illustrates two particular strong leanings for SOA: business/IT alignment and software systems development. In both of these cases, the same goals of loose-coupling, consolidation and sharing are evident. Given these are appropriate attributes to be striving for, and they do seem to improve service delivery and overall agility when applied, then governance provides the processes, policies, roles and tools necessary to ensure that all efforts deliver on these attributes.
Governance will not magically provide success; it is just a framework that provides answers to the questions that will most easily bottleneck or derail your SOA efforts. Governance will provide accountability and guide the decision-making effort surrounding building and delivering services. For example, the governance process can be empowered to decide if the business will invest in a particular type of service and if that service meets a legitimate need or opportunity. Moreover, the governance process can include individuals from various aspects of the business so as to provide a wide aperture on the positives and negatives of developing a particular type of service.
Interestingly, when it comes to offering services, many businesses are very sophisticated when that service requires cross-departmental involvement. For example, insurance companies invest heavily in examining if they will offer a new insurance service. Their decisions start with market examinations, analyses of customers and prior payoff scenarios and profit potential. This research is then fed into a jointly-represented group that will provide feedback on the new service from the perspective of customer service, accounting, financial management and technology. Finally, the group will make a recommendation to an operational executive empowered to make the final decision on the new service.
However, decisions that are deemed intra-departmental are often made by a select few with limited scope, usually the departmental executives, even if that decision will impact the efforts and capabilities of other departments. That is, where one department owns the entire service offering, such as IT, it is less likely that decision-making will reach out to other departments to see if a particular service makes sense to the business as a whole as is the case in offering a service to the business’ consumers. When this occurs in SOA, you end up with a narrowly-focused service-orientation that may not meet the needs of the business as expected.
ITIL V3 Support for SOA
First, and foremost, ITIL focuses on delivery of IT as a service, which really captures an essence of SOA that is often lost, misunderstood or simply ignored. That is, in contrast to those who view SOA as a means of delivering software systems, ITIL’s focus is on the service itself. In ITIL, the service includes software, infrastructure, help desk, asset management, and more. Thus, this may be the best representation of a governance framework simply because it focuses on service delivery from a purely service-centric perspective and not a technological perspective.
At the heart of ITIL V3 is the concept of service strategy, which focuses on value creation. Much of the literature on SOA kowtows to the meet-in-the-middle approach to SOA, so as not to offend any particular audience. The meet-in-the-middle approach looks at design of a service by focusing on both bottom-up and top-down. However, so much of the bottom-up is so inefficient and lacking quality understanding of the business that incorporating that knowledge into the whole is actually a disservice to the creation of a new service. ITIL’s focus on value creation means that the first step in service delivery is starting from a strategic viewpoint with no limitations placed on the outcome by past attempts at providing this service.
ITIL V3 also focuses on service design, which uses the concept of the service design package to encapsulate all the requirements, addresses the dependencies and rollout, architecture, processes, measurements and metrics. This concept is a great way to think about organizing all the artifacts produced as part of an SOA effort. Included in the service design is the concept of the service portfolio management and service catalog management, which both align well with SOA service registry goals of service inventory, change management and authorization.
Finally, service transition, service operation and service improvement focus on the processes to deliver a service to market, ensure its operational performance and continually tune that service to deliver optimally. Those who view SOA through a technological lens will miss the nuances covered by these practices since it is outside the scope of the software engineering group's efforts. The only way a service can be properly managed after it is deployed is to enable communications with the service consumers and to monitor its usage. Once again, this is more evidence that SOA is a strategic effort that requires the efforts of many within the business and should not be entered into lightly. This point will be addressed more fully in the following section on Big SOA and Little SOA.
Moreover, developers often assume that instrumentation and measurement can be accomplished after the fact and that the service itself does not need to incorporate support for these activities. This shortsightedness is one of the reasons that those focused on SOA for building software services need to employ the ITIL V3 framework to ensure that the services developed do not incur the penalties of having a software engineering bias.
ITIL V3 does not focus on how to build a service, which is important as well. With regard to delivering IT service, there are subsequent, more detailed standards that come into play, such as TOGAF, ISO/IEC 20000, CMMI, COBIT and Six Sigma. However, the lifecycle of the service itself is guided by V3, which is exactly what we want for SOA—a single agreed upon framework that defines SOA and guides the entire lifecycle of the service cradle-to-grave.
Big SOA, Little SOA & SOA Governance
A discussion of SOA governance would not be complete without addressing the Big SOA, Little SOA debate. There are some that believe that SOA can be approached in a tactical, IT-centric manner, or what has been termed “Little SOA” and have termed an enterprise focus on SOA as “Big SOA”. I believe applying ITIL V3 to the SOA governance problem settles this debate once and for all—there is only one SOA. Even if an organization decided that SOA was IT-centric, ITIL V3 illustrates that delivering IT as a service still requires incredible diligence and discipline to ensure that the service consumers are being properly serviced and that the service meets their needs. While perhaps a smaller scale than the entire enterprise, it still requires that the business implement and follow the full practice model to ensure success.
SOA on any smaller scale is merely focusing on application development and using SOA as an alternate way to say component software architecture. Ultimately, this is not SOA as it does not focus on the service lifecycle, but on a means of defining interfaces between software components to enable modularity. Modularity and SOA are not synonymous and the results of this and SOA driven by ITIL V3 governance are very different animals.
Conclusion
There is much attention being paid and monies being spent on SOA governance solutions. In many of these cases, businesses are trying to figure out for themselves the best method for governing their SOA—some of the confusion still stemming from confusion around SOA itself. ITIL V3 offers a comprehensive approach to governing the creation, design, development, deployment, operation, change management and eventual termination of a service.
About the Author
JP Morgenthal works as a Sr. Principal Architect with QinetiQ North America's Mission Systems Group providing enterprise and SOA architecture guidance for Federal civilian agencies and an independent analyst for jpmorgenthal.com. Prior to joining QinetiQ NA, JP founded Avorcor where he developed a SOA-based Enterprise retail/manufacturing PaaS that has been the foundation of three award-winning industry solutions for customers. He is also frequent blogger and noted analyst on enterprise architecture, SOA and cloud computing topics. Morgenthal is also author of "Enterprise Information Integration: A Pragmatic Approach", which defines a methodology for using SOA and semantics to simplify integration.
