Roadmap

From PGFSOA Wiki

Contents 1 A Roadmap for SOA Adoption [Document Section 5] 1.1 SOA Maturity Stages 1.2 Establishing a Core SOA Team 1.3 SOA Roadmap Model

[edit] A Roadmap for SOA Adoption [Document Section 5]

Exhibit 5-1 depicts a high level view of the basic SOA Adoption process discussed in this section. The Practical Guide for SOA presents a series of logical steps that agencies should take, starting with an SOA Readiness Assessment which can help the agency to determine the level of support that exists within the agency. This assessment will help provide the degree of value the agency believes will follow from implementing SOA. We recommend that the agency develop a sound Business Case for SOA that will identify the value proposition, approach, and costs and benefits of pursuing SOA. Depending on the maturity stage the agency finds itself in following an SOA Maturity Assessment, the agency should then develop a more detailed SOA Adoption Roadmap Plan, followed by execution of management processes identified in the Roadmap Plan. This will spawn (multiple) initiatives to implement specific capabilities necessary for effective adoption. Periodically (e.g., annually), the adoption program should be reassessed from a SOA maturity perspective and modifications should be made to the Roadmap Plan based on the advancing maturity of the organization.

An agency that plans to implement SOA should develop a SOA roadmap (i.e., a structured SOA implementation plan for managed adoption based on best practices) that is synchronized with its enterprise strategic goals and objectives. Industry literature indicates that a SOA roadmap can enable an organization’s enterprise architecture to implement business strategic plans through the design of new systems, as well as the transformation of legacy systems.

The SOA roadmap provides a strategy that:

• Considers an enterprise’s rationale for SOA;
• Establishes goals and objectives associated with an enterprise’s target architecture; and
• Applies best practices to SOA implementation.

The SOA roadmap articulates the changes and growth in capabilities over time - expressed as a capability maturity model. It documents the enterprise’s specific approach to reaching the next desired level of maturity and provides a conceptual plan that is used as a basis for developing detailed project plans and allocating responsibility to accomplish each of the activities.

The SOA roadmap, depicted in Exhibit 5-2, allows an agency to leverage industry and government experience and to tailor the approach to the specific needs of the agency. It helps extend and adapt existing governance, application development lifecycle, and support processes to the service-oriented approach, and more closely aligns them with desired outcomes.

Roadmap Critical Success Factors

The following key factors, distilled from the previous chapters, help an SOA roll out succeed :

• Well defined and accepted principles to prioritize when and where to apply SOA.
• Engineering processes that leverage service orientation, i.e., reuse, modularity and composability.
• Enhanced lines of communication across project teams.
• Realtime feedback loop from run-time business activity to design-time planning activity.
• Funds available for business process innovation.
• Measures of effectiveness that specify return on investment through enhanced modularity and composability.
• Steps to establish and support SOA governance policies, procedures and mechanisms.
• Clear and continuing support from IT and business leadership.

Roadmap Focus Areas

In the least, an SOA Roadmap should address the following key areas:

• Identification and Description of Common Services:
  • Activities to increase maturity of service identification, definition, development, implementation, and operation, e.g., Business Process Management and Business Activity Monitoring.
  • Activities to develop and manage the organization’s services portfolio.
  • Coordination of service identification and management activities and responsibilities among COIs.
  • Activities that support the services lifecycle.

• Fiscally Enable Community Of Interest (COI) Governance Bodies to:
  • Manage and monitor the development, integration, testing, deployment and retirement of services.
  • Harvest EA best practices, use cases, architectural patterns and principles, as well as extensions or modifications to existing lifecycle and support processes.
  • Establish and enable key services management roles and responsibilities.
  • Develop and implement communication and training plans.
  • Review and extend existing project support processes for cross-organization, cross-agency services development, and operation.

• Services Infrastructure, Integration Platform and Tooling:
  • Establish and sustain SOA development, test, integration and runtime environments.
  • Identify and implement tools to monitor and enforce governance policies and service level agreements.
  • Establish and cultivate a services-oriented infrastructure environment.
  • Establish repositories/registries that will capture system artifacts, including policies to help enforce governance and manage assets throughout the lifecycle.
  • Identify and implement key SOA management components that integrate with the infrastructure environment.

[edit] SOA Maturity Stages

A SOA maturity model identifies phases that characterize the scope of SOA adoption and experience. There are a number of SOA Maturity Models available (for example, Everware-CBDI, IBM, Oracle, and BEA). This guide does not endorse any particular SOA maturity model, but does draw attention to the fact that there is widespread agreement surrounding the usefulness of leveraging a maturity model. Rather, we suggest that agencies review all of the models available, and select the elements which meet their needs.

SOA maturity models generally have four to five linked stages of maturity moving from very little understanding of, or activity associated with SOA adoption, to a business model thoroughly organized around services. This guide offers a generic maturity model to assist agencies in determining where they are on this continuum. Our generic model represents a composite of publicly available information from the four cited commercial models which has five stages that build on one another: Early Learning, Application, Adoption, Optimization, and Federation.

Within each maturity stage, the state of the agency’s SOA adoption is expressed in terms of the six key dimensions listed above. Based on an assessment of the agency against this basic information, or a similar SOA maturity model, the agency should be able to identify where it lies along the maturity continuum as well as prioritize how to move to successively higher stages of maturity. This information is important for developing the agency’s specific SOA Roadmap.

	[ EARLY LEARNING ]
Initiative Management	Funding is primarily directed to individual projects.
Organization	Either individual application architects or the Chief Architect sponsors SOA.
Collaboration	Application projects are generally focused on their own deliverables; limited cross-project collaboration.
Architectural Process and Alignment	Architecture is fragmented and exploratory. Architecture frameworks are ad hoc; no mature enterprise approach.
Services Lifecycle Management	Services are mostly not identified. If services are identified, they are not managed in a cross-project, enterprise manner.
Services Infrastructure	Limited services infrastructure; primarily supports individual Proofs-of Concept; possible project Enterprise Services Bus.

	[ APPLICATION ]
Initiative Management	Services are identified and managed as an IT architecture concept.
Organization	SOA is generally a project level responsibility and is found consistently in most appropriate projects.
Collaboration	Service delivery and usage governance, process and practices are incorporated into projects and projects collaborate to share services. Management recognizes the need for a collaborative DT&E process.
Architectural Process and Alignment	Project architectures are service oriented; no enterprise level service orientation within the enterprise architecture. There are consistent project level architectures; no overall enterprise level SOA reference architecture.
Services Lifecycle Management	Services are available for individual projects to use and leverage.
Services Infrastructure	There is an Enterprise Service Bus Proof of Concept; some projects beginning to use common services and sharable services.

	[ ADOPTION ]
Initiative Management	Funding processes specifically support the development, implementation and use of shared services; governance processes are in place to manage services effectively.
Organization	There is a single organizational entity responsible for integration and processes in place to facilitate integration.
Collaboration	Project processes and governance are built around identifying and incorporating shared assets. Some projects are beginning to perform collaborative DT&E.
Architectural Process and Alignment	SOA is employed as a component of EA. There are standards in place for rich service specification and use. There is an enterprise level SOA reference architecture and implementation processes in place; they are governed at the enterprise level.
Services Lifecycle Management	There is an enterprise level services repository that provides consistent lifecycle governance of run-time service assets.
Services Infrastructure	There is an enterprise level ESB that is mandatory for project use; common enterprise services are available, well governed, and can be found and used.

	[ OPTIMIZATION ]
Initiative Management	Services are managed effectively as enterprise business assets. Governance processes for managing services are mature, applied consistently across the organization.
Organization	Services are owned by business units but managed as enterprise business assets.
Collaboration	There are processes in place for service quality management that are understood and used by individual projects. Collaborative DT&E occurs regularly across internal projects.
Architectural Process and Alignment	Internal agency EA goals and objectives are realized. The agency has an enterprise services portfolio plan and uses it to identify, develop, and use service assets as a fundamental way of doing business. There are agreed-to and managed business processes and business architectures for business collaboration. Services are managed within a service-oriented enterprise architecture as shared federated assets.
Services Lifecycle Management	The enterprise registry and repository provides design and runtime service asset lifecycle governance and asset dependency analysis.
Services Infrastructure	There exists a common framework and tools for enterprise management of services, and security services facilitate inter and intra business collaboration.

	[ FEDERATION ]
Initiative Management	Services facilitate inter and intra business collaboration.
Organization	Services are defined and managed within an inter-business, collaborative basis.
Collaboration	Collaborating parties within the SOA relationship operate and act as service provider and consumer. Collaborative DT&E occurs seamlessly and virtually across multiple agencies.
Architectural Process and Alignment	EA goals and objectives are realized across multiple agencies. There are agreed business processes and data architectures for integration and business collaboration. A complete, agreed SOA reference architecture exists and is used to manage key collaboration points.
Services Lifecycle Management	Ecosystem registries provide governance structures and processes over collaborative business processes.
Services Infrastructure	Services are managed as enterprise sharable but federated assets. Structures, tools and processes are in place at the infrastructure level to facilitate this.

Everware-CBDI SOA Maturity Stages

(CBDI Journal 2005, December Best Practices Report)

[edit] Establishing a Core SOA Team

It is crucial to establish a focused team of specialists that have both a commitment to the change process that an SOA vision requires and also the technical skills required to sustain the process. Those general skills should include leadership, engineering, and business acumen with specific expertise in things like change management, security, agile methods, modeling and simulation, and business process analysis. This team has been variously called a “Tiger Team,” an SOA Center of Excellence (COE), or SOA Program Management Office (PMO). Any of these approaches will work if the team has top management support, the ability to interact effectively with program managers, project managers and developers within the agency, as well as adequate resources.

The Core SOA Team introduces new integration technologies, selects standards and develops reference models for services, identifies service domain owners, and creates the agency SOA governance model. The most effective approach is to employ pilots and proofs of concepts that quickly and clearly demonstrate value to the entire organization.

[edit] SOA Roadmap Model

Using the SOA Maturity Model phases described above, an agency can begin to build a customized Roadmap based on the stage when they start the adoption process, what changes need to be accomplished at each stage in the process, and what level of maturity the agency decides is appropriate for its strategic objectives. Every agency does not need to reach the highest level of maturity to fulfill its business goals.

The table below, Exhibit 5-3, provides a general example of an SOA Roadmap that can help agencies develop customized roadmaps.

Exhibit 5-3: An Example SOA Implementation Roadmap Based on Maturity Phase

TIMELINE :	Phase 1	Phase 2	Phase 3	Phase 4
MATURITY PHASE :	Early Learning	Application	Adoption	Optimization/ Federation
Scope of SOA Adoption	Project-Centric, Opportunistic	Strategic, Business Segment Wide	Enterprise Wide	Business Transformation
Timeframe	0-6 months	6-12 months	12-18 months	18 months to indefinite
Key SOA Implementation Processes	*Secure executive support for SOA pilot Create rudimentary collaborative DT&E environment Establish a core SOA Team Establish incentives for collaborative SOA governance Lay out scope, objectives and governance for SOA pilot. Re: Business Engagement SOA Design Patterns. Basic integration platform & middleware. SOA Standards. Service level metrics. Business improvement goals.	* Document tangible performance improvements based on SOA pilot. Extend collaborative DT&E environment to active and critical candidate projects. Extend common services discovery scope to include: Individual project analysis, Critical support of business domain requests, and legacy systems analysis. Execute analysis to fulfill business and IT strategies for initial portfolio assessment Develop and implement services funding and pricing models for a few services. Extend scope and depth services available to project developers including security, data sharing, and run-time integration services. Core SOA team propose candidate enterprise services. Core SOA team identifies touch-points and approach to align IT strategies Identify key commodity services that support multiple lines of business. Identify customized services that support core business areas. Project engagement process documented and provided to projects at onset of engagement. Define strategic planning services identification process Extend service level metrics Implement pilot service performance dashboard.	*Extend service level metrics to encompass all projects using enterprise services. Utilize full scope of SOA design patterns across all candidate projects. Services funding and pricing models are in use for all enterprise services and tied to SLAs. Full portfolio of services is developed and used to identify key SOA initiatives. Engage in enterprise-wide analysis to accelerate SOA benefits. Service level metrics in place for all projects tied to performance and business agility. SOA executive dashboard providing real-time performance results of service level metrics. SOA enables top-down EA analysis Identify cross lines of business and cross agency integration opportunities Create SLAs between mutual services providers and mutual lines of business for shared services. Establish run-time SOA governance across lines of business Identify common services through: process for bottom-up discovery. Strategic planning with business partners. Implement run time discovery processes.	*Identify mechanisms and processes to consolidate and optimize services. Continuously evaluate alternative approaches to allow adaptation and evolution. As the industry matures, evaluate and adopt/adapt alternative approaches, Federated services discovery, run-time policy governance and performance monitoring are in place and drive service delivery. Service level performance is provided real-time to program managers who use it to perform business process innovation Standards based business systems are composed rapidly to react to business performance requirements. Development and operating environment are fully service oriented. Cross domain collaborative incentives are clear and collaborative process for mutual investment and engineering are seamless Collaborative DT&E environment is, continuous, seamless, virtual, and ad hoc.