Confronted with the age old problems of agility and complexity, today’s CIOs are under more pressure than ever to improve the strategic value of IT to the business. At best, these challenges have increased costs, limited innovation and increased risk. At worst, they have reduced IT’s ability to respond to changing business needs in a timely fashion.
Yet, changes for business and IT are continuing to occur at an ever-increasing pace. To keep up, enterprises need to adopt an agile, flexible architecture style with a proven strategic approach to delivering IT to the business.
Over the last year, I have seen a resurgence of CIOs using enterprise architecture (EA) as a key tool to address these challenges. In the past, EA has experienced difficulties within the enterprise. It has been unfairly seen as primarily a documentation exercise and, when applied incorrectly, EA can — ironically — become a silo in of itself. To make sure that EA has better success this time, CIOs must make their EA efforts more actionable.
Step back: SOA
Service oriented architecture (SOA) has been positioned as an architectural style specifically intended to reduce costs, increase agility and, most importantly, simplify the business and the interoperation of different parts of that business.
A key principle of SOA is the structuring of business capabilities into meaningful, granular services as opposed to opaque and siloed business functions. This makes it possible to quickly identify and reuse any existing realized functional capabilities, thus avoiding the duplication of similar capabilities across the organization. By standardizing the behavior and interoperation of these services, it’s possible to limit the impacts of change and to forecast the likely chain of impacts.
Despite its popularity, relatively few enterprises have been able to measure and demonstrate the value of SOA. This is due primarily to the approach that enterprises have taken when adopting and applying SOA. In most cases, enterprises interpret SOA as simply another solution development approach. As a result, SOA has been relegated or wrongly positioned as a purely integration technology, rather than the strategic enabler that it can be.
Because of this, SOA must not be seen as a solution development approach that starts and ends once a solution is delivered. It must be seen as an on-going process that, when coupled with a strategic framework, can change and evolve with the business over time. Unfortunately, many enterprises adopt SOA without utilizing a strategic framework, causing a host of challenges for their business.
Just a few of the challenges I have seen include:
- More complexity and moving parts
- Increased costs
- Projects taking longer than before
- Solutions more fragile than ever
- Little or no agility
- Difficulty identifying and discovering services
- Exponentially growing governance challenges
- Limited service re-use
- Duplication of effort leading to service sprawl
- Multiple siloed technology focused SOAs
- Funding for service oriented projects being cut
It’s no wonder that SOA has a bad reputation.
To address these challenges, enterprises utilizing or considering adopting SOA must align it with an EA framework that elevates the importance of the needs of the enterprise rather than only considering the requirements of individual projects.
Step forward: TOGAF v9
Now used by 80 percent of the Fortune Global 50, TOGAF, an Open Group standard, is an architecture framework that contains a detailed method and set of supporting resources for developing an EA. As a comprehensive, open method for EA, TOGAF v9 complements and can be used in conjunction with other frameworks that are more focused on specific aspects of architecture, such as MDA and ITIL.
The Open Group’s new guide,Using TOGAF to Define and Govern Service-Oriented Architectures aims to facilitate common understanding of the development of SOA while offering a phased approach to maximizing its business impact based on the popular TOGAF methodology. Let’s take a look at the main takeaways from the guide:
Organization readiness – An enterprise first needs to adopt the principle of service-orientation. However, successful SOA depends on the readiness of the enterprise to become service-oriented. To get started with SOA, the guide recommends conducting a maturity assessment. Such an assessment is available from The Open Group and enables a practitioner to assess an organization’s SOA maturity level and define a roadmap for incremental adoption to maximize business benefits at each stage along the way.
Organization readiness – An enterprise first needs to adopt the principle of service-orientation. However, successful SOA depends on the readiness of the enterprise to become service-oriented. To get started with SOA, the guide recommends conducting a maturity assessment. Such an assessment is available from The Open Group and enables a practitioner to assess an organization’s SOA maturity level and define a roadmap for incremental adoption to maximize business benefits at each stage along the way.
Scope – The size and complexity of an enterprise affects the way it’s architecture develops. Where there are many different organizational and business models, it is not practical to integrate them within a single architecture. It is therefore generally not appropriate to develop a single, integrated SOA for a large and complex enterprise.
TOGAF defines enterprise as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.
The guide highlights an approach for enterprise architects to identify the business areas where SOA will be of greatest benefit and make a significant impact so that they can be prioritized. This approach will help organizations avoid using SOA with the wrong situations to maximize their investment and overall business impact.
Communication, communication, communication – Aspects of TOGAF v9 were extended and enhanced to cover specific service-oriented concepts and terminology such as service contracts. Service contracts formalize the functional and non-functional characteristics of a business service and how it interacts with other business services. This enables a business vocabulary to be derived that allows IT to converse with the business in terms of business process and business services and abstracting away the complexity of the underlying technical services.
Governance – The identification of service and service portfolios is a key task for SOA. The questions of what service and service portfolios the enterprise will have, and how they will be managed must be taken with an enterprise level view.
Just because you have identified a number of services does not automatically mean they will add value to the enterprise and that they should be realized (at least not initially). Governance plays a key role here and the guide recommends the establishment of a SOA governance and creating a linkage to both IT and EA governance in the enterprise.
The Open Group has a wealth of information available in this area, specifically a SOA governance frameworkthat provides context and definitions that enable organizations to understand, customize, and deploy SOA governance.
The relationship between EA and SOA is a powerful and synergistic one. They are key enablers for one another, making EA actionable while making the wider business benefits of SOA obtainable.
SOA is certainly not the only architectural approach that your enterprise will require. But it can smooth the alignment and adoption of other architecture styles (e.g., business process management, event-driven architecture) into an EA framework. So rather than reinvent the wheel, organizations should consider using a well-established framework such as TOGAF to elevate and extend the value of SOA.
The Open Group’s new guide is a must-read for any enterprise architect currently using TOGAF, but remember that it needs to be customized and extended to your enterprises unique situation. Now, if only The Open Group had a guide on using TOGAF to define and govern cloud computing!
Stephen Bennett is a senior enterprise architect at Oracle and a 25-year technologist focused on providing thought leadership, best practices, and architecture guidance around SOA and cloud computing. Stephen is a published author on topics such as SOA governance and cloud computing. He has co-chaired a number of working groups within the Open Group organization around SOA Governance and TOGAF/SOA.
Source : http://www.cioupdate.com/technology-trends/finding-the-value-in-soa-1.html