By Awel Dico, Bank of Montreal
Service Oriented Architecture (SOA) has promised many benefits for both IT and business. As a result, it has been widely adopted as an architectural style among both private business and government enterprises. Despite SOA’s popularity, however, relatively few of these enterprises are able to measure and demonstrate the value of SOA to their organization. What is the problem and why is it so hard to demonstrate that SOA can deliver the much needed business value it promises? In this post I will point out some root causes for this problem and highlight how The Open Group’s new guide, titled “Using TOGAF® to Define and Govern Service-Oriented Architectures,” can help organizations maximize their return on investment with SOA.
The main problem is rooted in the way SOA adoption is approached. In most cases, organizations approach SOA by limiting the scope to individual solution implementation projects – using it purely as a tool to group software functions into services described by some standard interface. As a result, each SOA implementation is disconnected and void of the larger business problem context. This creates disconnected, technology-focused SOA silos that are difficult to manage and govern. Reuse of services across business lines, arguably one of the main advantages of SOA, in turn becomes very limited if not impossible without increased cost of integration.
SOA calls for standard-based service infrastructure that requires big investment. I have seen many IT organizations struggle to establish a common SOA infrastructure, but fail to do so. The main reason for this failure is again the way SOA is approached in those organizations; limiting SOA’s scope to solution projects makes it hard for individual projects to justify the investment in service infrastructure. As a result they fall back to their tactical implementation which cannot be reused by other projects down the road.
The other culprit is that many organizations think SOA can be applied to all situations – failing to realize that there are cases when SOA is not a good approach at all. An SOA approach is not cheap, and trying to fit it to all situations results in an increased cost without any ROI.
Fortunately there’s a solution to this problem. The Open Group SOA Work Group recently developed a short guide on how to use TOGAF® to define and govern SOA. The guide’s main goal is to enable enterprises to deliver the expected business value from their SOA initiatives. What’s great about TOGAF® in helping organizations approach SOA is the fact that it’s an architecture-style, agnostic and flexible framework that can be customized to various enterprise needs, architectural scopes and styles. In a nutshell, the guide recommends the incorporation of SOA style in the EA framework through customization and enhancement of TOGAF® 9.
How does this solve the problem I pointed out above? Well, here’s how:
SOA, as an architectural style, becomes recognized as part of the organization’s overall Enterprise Architecture instead of leaving it linked to only individual projects. The guide advises the identification of SOA principles and establishment of supporting architectural capabilities at the preliminary phase of TOGAF®. It also recommends establishment of SOA governance and creating linkage to both IT and EA governance in the enterprise. These architecture capabilities lift the heavy weight from the solution projects and ensure that any SOA initiative delivers business value to the enterprise. This means SOA projects in the enterprise share a larger enterprise context and each project adds value to the whole enterprise business in an incremental, reusable fashion.
When TOGAF® is applied at the strategic level, then SOA concepts can be incorporated into the strategy by indentifying the business areas or segments in the enterprise that benefit from a SOA approach. Likewise, the strategy could point out the areas in which SOA is not adding any value to the business. This allows users to identify the expected key metrics from the start and focus their SOA investment on high value projects. This also makes sure that each smaller SOA project is initiated in the context of larger business objectives and as such, can add measurable business value.
In summary, this short and concise guide links all the moving parts (such as SOA principles, SOA governance, Reference Architectures, SOA maturity, SOA Meta-model, etc.) and I think it is a must-read for any enterprise architect using TOGAF® as their organization’s EA framework and SOA as an architectural style. If you are wondering how these architectural elements fit together, I recommend you look at the guide and customize or extend its key concepts to your own situation. If you read it carefully, you will understand why SOA projects must have larger enterprise business context and how this can be done by customizing TOGAF® to define and govern your own SOA initiatives.
To download the guide for free, please visit The Open Group’s online bookstore.
Awel Dico, Ph. D., is Enterprise Architect for the Bank of Montreal. He is currently working on enterprise integration architecture and establishing best practice styles and patterns for bank wide services integration. In the past he has consulted on various projects and worked with many teams across the organization and worked on many architecture initiatives, some of which include: leading mid-tier service infrastructure architecture; developing enterprise SOA principles, guidelines and standards; Developing SOA Service Compliance process; developing and applying architectural patterns; researching technology and industry trends, and contributing to the development of bank’s Enterprise Reference Architecture blueprint. In addition, Dr. Dico currently co-chairs The Open Group SOA Work Group and The Open Group SOA/TOGAF Practical Guide Project. He also co-supervises PhD candidates at Addis Ababa University, Computer Science – in Software Engineering track. Dr. Dico is also a founder of Community College helping students in rural areas of Ethiopia.
Comments are closed.