Traventec September 2004 Technology Feature Roadmap for Adoption of Service Oriented Architecture ROADMAP FOR ADOPTION OF SERVICE ORIENTED ARCHITECTURE... 2 1. INTRODUCTION...2 2. GET PEOPLE INVOLVED...2 3. PLAN FOR SUCCESS...2 4. ORGANIZATIONAL AND OPERATIONAL CONSIDERATIONS...4 5. CONCLUSIONS...5 6. REFERENCES...6 1
Roadmap for adoption of Service Oriented Architecture 1. Introduction We introduced the concept of a service-oriented architecture (SOA) in an earlier Beacon edition [Beacon0305]. In the previous technology feature of The Beacon we looked at the benefits that an SOA can bring to an organisation [Beacon0704]. In this edition we will take a look at the process of adopting a service-oriented architecture for an organisation. It should come as no surprise that the biggest challenges are not always the technology challenges. To recap, an SOA is focused on creating a concept, technology, and process framework that will allow enterprises to develop, interconnect, and maintain enterprise applications and services efficiently and cost-effectively [KIDD0704]. SOA is concerned with more than technology issues; it provides a vehicle for closer alignment of business objectives with IT operations. 2. Get People Involved Buy-in from across the organization is essential to the success of SOA adoption. The first step is to establish an SOA Center of Excellence (CoE) early and staff it with cross-functional architects, business unit representatives, and business analysts with strong technical, communication and business skills. Although it may be a grandsounding term, a CoE is, at its most basic, a group of people from across the organization who are empowered to ensure the success of the project. It is vital that this group reaches out to the wider communities within the organization. This group needs to foster communications between traditionally disparate groups, and address many issues not the least of which will be political in nature. A responsive feedback loop between business units and development units will go a long way towards establishing the trust that will be necessary for the project to succeed. This could include, for example, establishing incentives and policies to encourage development of new services and reuse of existing services across business units of defined services. A good starting point is to establish an information portal within the organization through which the group can publish service information, design principles, guidelines, best practices, patterns, templates, architecture documents and other artifacts. 3. Plan for Success Overall adoption of SOA can be a lengthy process, but the adoption process can start to deliver value to the organization from an early stage. Early and repeated successes are vital to the continued sponsorship of SOA adoption and to the perceived value that SOA provides. Think big, start small, deploy quickly is a fitting mantra to keep in mind when planning any large-scale endeavor. We recommend that the SOA adoption process evolve over time with a phased delivery plan. For a large organization with several products, multiple business units 2
and a global market presence, the roadmap should consider three distinct phases covering the immediate 18-24 months, as shown in Figure 1. In previous editions of The Beacon we looked at the justification for adopting SOA and the benefits that SOA brings [Beacon0407, Beacon0305]. Some preparation and planning is required before the development of the new SOA platform gets up and running. This time includes a traditional Elaboration Phase involving the primary stakeholders [Beacon0211, Beacon0212]. The main goals here are to build the initial team, create the vision for where the organization is going and how SOA will help, and establish the architectural foundation. The CoE plays a critical role in these early days. The activities in this phase should determine the feasibility of the effort and prepare the organization for the architecture adoption and implementation that lies ahead. Additional activities include performing a detailed audit of existing systems and applications across the organization, including those that will need to be migrated and those that will be integrated. The first strategic services and applications need to be identified and business processes need to be clarified. This is also the time to develop proof-of-concept implementations that address areas of risk in the proposed services, particularly if this is the first time the organization has used SOA-related technology. Figure 1: Roadmap to SOA adoption The diagram in Figure 1 shows the roadmap to adoption at a high level. The vertical axis shows a distinction between business considerations and technology considerations. The business considerations on the upper half of the diagram show the evolution from strategy definition through developing a services model, to developing multi-partner agreements. The technology concerns on the lower half of 3
the diagram address issues such as development of service interfaces through architecture evolution and service orchestration, to service discovery and development of richer service models. Phase 1 of the adoption process focuses on integration. This is the time during which the first real deliverables from the SOA adoption process are created. This phase should typically be no more than 6 months in duration, and should include a development effort of approximately 16 to 20 weeks. The target for this phase is to introduce SOA to the organization, to achieve some reuse of services within a business unit, and to use SOA for the first time to deliver a solution to some strategic problem. The adoption plan needs to include a strategy to access enterprise data via services and to achieve quick integration to legacy applications using Web services. The project itself should be of relatively low complexity, without being trivial. Phase 2 builds on the early success of Phase 1 and brings more focus to service processes, workflow, and interoperability. The organization now has the confidence that comes with experience and success. Eight to 12 months duration is typical for this phase. Phase 1 starts to build the core SOA infrastructure within the organization. Phase 2 builds on this to deliver additional applications and services for multiple business units and functions across the organization. The adoption plan needs to define how the organization is to achieve wider reuse of services across business units. It is during this phase that you will start to gain some real and valuable insights into issues of reuse, discovery, publication, and control of services. Duplicate efforts across the organization can be more readily identified and refactored into common services. In addition, the adoption plan needs to identify shared services for security, authentication, logging, and quality-of-service implementations. Phase 3 looks at the long-term strategy for SOA and its continued success within the organization. There is more focus on dynamic discovery of services, including discovery of external services in partner organizations. At this point there are many enterprise-wide applications built and deployed on the SOA platform. Phase 3 should see company-wide participation in defining the SOA infrastructure, and wide sharing of services among business units, partners, and customers. As highlighted in previous Beacon editions [Beacon0305, Beacon0407], SOA also brings the potential benefits of reduced application development and maintenance costs. Those benefits are realized during Phase 3. 4. Organizational and Operational Considerations A danger in adopting SOA is the temptation to treat the adoption as a purely technology-driven process. One of the most essential considerations in successful SOA rollout is achieving buy-in from the business unit leaders. These are the people who can validate the needs of your customers and the value provided by an SOA to your strategy and product lines. In adopting SOA, you should start small with a pragmatic, yet non-trivial, use case. Grow the platform incrementally, and plan to add applications and services using an evolutionary approach. All of the principles we discussed in our series on iterative and incremental software development processes are valid for SOA adoption [Beacon0211, Beacon0212]. 4
The services that will be implemented as part of the SOA should start to provide early value to the organization. It should be clearly articulated how this value will be measured and evaluated. Early plans for SOA adoption should include strategies for how these services can generate revenue or reduce costs. In addition, funding for the infrastructure that will support shared services should come from across the organization; it should not be left to a single business unit to bear the risk of the initial investment. Support groups and operations groups need to understand and learn new administrative tools for managing services in a SOA environment. There are a rich set of operations tools available, which themselves will require integration into the organization. 5. Conclusions Education is the single biggest critical success factor in rolling out a successful strategy for SOA adoption. This includes education of everyone that will be involved in the effort; development teams, architects, project managers, product managers, and business unit leaders and their teams. The next step is appropriate and sufficient planning and starting the right way. Minimize risk and increase the likelihood of delivering business value by developing the SOA platform and services in an iterative and incremental way. Finally, consider the non-obvious impacts that the new SOA platform will have on your organization and develop a plan to address them in advance. 5
6. References All issues of The Beacon are available from www.traventec.com/. [Beacon0201] Web Services Part 1: Introduction to Web Services. The Beacon. January 2002. [Beacon0211] Iterative Software Development Processes. The Beacon. November 2002. [Beacon0212] Iterative Software Development Processes Part 2 (Coauthored). The Beacon. December 2002. [Beacon0302] Enterprise Application Integration with J2EE. The Beacon. February 2003. [Beacon0303] Enterprise Application Integration Models (Co-authored). The Beacon. March 2003. [Beacon0305] Service Oriented Architecture. The Beacon. May 2003. [Beacon0407] Service Oriented Architecture delivering agility to the travel domain. The Beacon. July 2004. [BLUESPEC04] The Middleware Company. SOA Blueprints Specification. May 2004. [CBDIR04] Sprott, David. Service Oriented Architecture: An Introduction for Managers. CBDI Report commissioned by IBM. 2004. [Chappel0406] Chappel, Dave. Enterprise Service Bus. O Reilly June 2004. ISBN: 0-596-00675-6. [IBM1203] Channabasavaiah, Kishore, Kerrie Holley, Edward M. Tuggle, Jr. all of IBM. Migrating to a service-oriented architecture, Part 1. December 2003. [KIDD0704] Kidd, Rob. SOA Blueprints: An Executive Summary. July 26, 2004. [RMH0310] Monson-Haefel, Richard. J2EE Web Services. O Reilly October 2003. ISBN: 0-321-14618-2. 6