Abstract. 1.1 Intended Audience

Transcription

1 Abstract SOA is relatively new, so companies seeking to implement it cannot tap into a wealth of practical expertise. Without a common language and industry vocabulary based on shared experience, SOA may end up adding more custom logic and increased complexity to IT infrastructure, instead of delivering on its promise of intra and inter-enterprise services reuse and process interoperability. To help develop a shared language and collective body of knowledge about SOA, a group of SOA practitioners created this SOA Practitioners Guide series of documents. In it, these SOA experts describe and document best practices and key learnings relating to SOA, to help other companies address the challenges of SOA. The SOA Practitioners Guide is envisioned as a multi-part collection of publications that can act as a standard reference encyclopedia for all SOA stakeholders. 1.1 Intended Audience This document is intended for the following audience: Business and IT leaders, who need to start and manage an SOA strategy across the enterprise/lob Enterprise Architects who need to drive the vision and roadmap of the SOA program and the architecture of each implementation that falls under it Program Managers who need to manage a portfolio of sub-projects within an overall SOA business strategy Project Team Members, who need to map dependencies and develop a timeline that meets the business expectations Vendors who provide solutions and tools for new business capabilities to the business and IT Standards bodies which need a better understanding of use cases of how business and IT plan to leverage technology to meet their objectives. Date: 5/11/2007 Source: SOA Practitioners Guide, Part 1: Why Services-Oriented Architecture? Page 1 of 7

2 SOA Lifecycle Approach The lifecycle of SOA is similar to that of an enterprise architecture, with an emphasis on business processes. Unlike an enterprise architecture approach, however, SOA requires both business and IT transformation, replacing traditional governance and organization models with a methodology that enables greater flexibility. Business and IT stakeholders need to look past their immediate areas of responsibility and partner to define the strategy and the roadmap to achieve their objectives. SOA Definition SOA is a business operations strategy for leveraging information to meet the organization s objectives, such as increasing overall revenue, boosting customer satisfaction, improving product quality, and enhancing operational agility. In practice, SOA means different things to different people. To an IT Architect, it means the overall enterprise architecture definition and the process that enables IT to develop and deploy business capability rapidly. Architects seeking information usually go to vendor sites for product details, case studies, and best practices which they then compare to other publication and standards sites such as The Server Side, W3C, java.net, and OASIS. To the LOB-IT liaisons it means the governance, organization, and process for project/program management and the various business building blocks that could potentially be reused in order to reduce cost. The LOB-IT and CIOs typically attend CIO Forums or subscribe to journals that provide information from vendors or analysts. For the legal team, SOA is a potential liability: they want to know whether the service is delivering information to partners, customers, and others outside the company firewall, and what regulatory issues and exposure might arise. And finally, for the CIO, SOA is the IT strategy for delivering business capability. What business functions will be automated: which services, and what maturity, cost, and SLA to expect? Date: 5/11/2007 Source: SOA Practitioners Guide, Part 1: Why Services-Oriented Architecture? Page 2 of 7

3 SOA Lifecycle Stages The SOA lifecycle covers the stages of implementing SOA within the enterprise or LOB and is different from the service lifecycle, which is the process for managing individual services. The SOA lifecycle has three stages: initiate, develop roadmap, and execute plan. Figure 1: SOA Lifecycle 1.2 Initiate SOA First, IT and business must decide which business function and underlying processes SOA will enable, enhance, or even replace. This often takes the form of IT pitching a project to a business stakeholder, presenting the business and/or technical events that the proposed SOA-based strategy will address, and what benefits this new approach will deliver. At this phase, the company establishes a project team, objectives, and timelines & deliverables. The objective is to create a roadmap that combines business and IT efforts, and that will be approved by an IT Board of Directors. Date: 5/11/2007 Source: SOA Practitioners Guide, Part 1: Why Services-Oriented Architecture? Page 3 of 7

4 Following are some examples for this proposal: Project Milestones Following is an example of a high-level project for initiating SOA. The proposed project is expected to last 11 weeks and each organization should modify the timeline according to their needs. The relative effort and the tasks would potentially be the same. Figure 2: High-Level Project Plan to "Initiate SOA" Best practices for initiating SOA include: Creating an actionable roadmap, one that both business and IT leadership are committed to Having the Enterprise Architecture team lead the effort Pulling together a project team including all key personnel from business, IT leadership, LOB-IT, operations, and partners such as systems integrators and ISVs Documenting clear business objectives, plans, and financial information Securing a balanced and unbiased opinion from a system integrator to identify the business benefits and develop the ROI Leveraging resources from ISVs, including product roadmaps and best practices Setting a reasonable timeframe for the project, typically between 8 and 24 weeks. Date: 5/11/2007 Source: SOA Practitioners Guide, Part 1: Why Services-Oriented Architecture? Page 4 of 7

5 1.2.2 Project Team CIOs frequently sponsor SOA initiatives with an IT Board of Directors as the steering committee. The following business personnel should be included in the project team: Business Team Members o VP, IT/Business Strategy o VP Business Operations o Representatives from each business operations team. Their responsibilities include identifying, defining, and prioritizing business processes and benefits. The following IT personnel should also be included in the project team: IT Team Members o VP IT Application Development o VP PMO o VP Technology/Architect o Divisional CIO/LOB-IT head. Their responsibilities are to translate business strategy to IT strategy, develop an IT execution plan aligned to business priorities, develop reference architecture, identify architecture components, and estimate cost Project Objectives Define how IT should align to the business Develop an execution plan for achieving the vision Create governance and organization model to execute the vision Estimate expected business benefits (ROI) for the investment Date: 5/11/2007 Source: SOA Practitioners Guide, Part 1: Why Services-Oriented Architecture? Page 5 of 7

6 1.2.4 Project Deliverables Statement of SOA principles, as they relate to the business, application, technology, and data (for more information, visit Inventory of current situation, including business applications, owners within business and IT, functionality, support contacts, technology providers, data flows, and skills of current staff Recommended target state consisting of the reference architecture, gap analysis, roadmap, and technology required Execution plan consisting of application portfolio, implementation sequence based on business priorities, and mapping of infrastructure needs to provide business capability Date: 5/11/2007 Source: SOA Practitioners Guide, Part 1: Why Services-Oriented Architecture? Page 6 of 7

7 1.3 Develop Roadmap The team needs to create a roadmap, which spells out the process for conducting an SOA assessment for the organization, developing the SOA principles, defining the reference architecture (future state), and making the transition from the current situation to the future state. Following are the three key deliverables for this stage of SOA: Develop SOA principles: define the SOA principles in a clear and concise manner. SOA reference architecture: describe the future state for the IT organization. The SOA reference architecture maps out the technology end-state and as part of this stage, the team needs to define the business end-state. This will help develop the SOA roadmap for the enterprise/lob. SOA roadmap: the roadmap should clearly define the phases for deploying business solutions and the infrastructure required to support them. It should also identify opportunities for quick wins to validate the benefits of SOA. 1.4 SOA Execution Plan The execution plan describes how to execute towards the SOA roadmap. Execution has two tracks: Projects: teams execute projects in the sequence described in the roadmap and build out the infrastructure as required to provide the business capability Governance and organization: teams implement this in parallel to enable efficient project execution based on SOA. Teams need to review the SOA execution plan on a regular basis and update the roadmap whenever there is major change to the plan. Contributing SOA Practitioners Surekha Durvasula, Enterprise Architect, Kohls Martin Guttmann, Principal Architect, Customer Solutions Group, Intel Corp Ashok Kumar, Manager, SOA Architecture, Avis/Budget Jeffery Lamb, Enterprise Architect, Wells Fargo Tom Mitchell, Lead Technical Architect, Wells Fargo Private Client Services Burc Oral, Individual Contributor Yogish Pai, Chief Architect AquaLogic Composer, BEA Systems, Inc. Tom Sedlack, Enterprise Architecture & Engineering, SunTrust Banks, Inc. Dr Harsh Sharma, Senior Information Architect, MetLife Sankar Ram Sundaresan, Chief Architect e-business, HP-IT Date: 5/11/2007 Source: SOA Practitioners Guide, Part 1: Why Services-Oriented Architecture? Page 7 of 7