The architectural consideration of SOA in the preceding chapter offers advice on what directions to choose and how to define the strategic goals for an SOA project. This chapter takes the next step toward execution by focusing on how to plan an SOA project. The topics in this chapter constitute the best practices we have uncovered for forming a project office (see Section 4.1), how to define the phases of SOA adoption, the need for and mechanisms of SOA governance, and finally, the various project roles and how they interact with each other.

This is not intended to be a complete template for a project plan, nor do we intend to show the optimal organizational structure for the parties involved in SOA projects. Based on our vigorous experience with different clients in various industries around the world, we are fully aware that there is no one-size-fits-all solution, nor is there a perfect approach to building an SOA for any scenario. An organization's specific circumstances will dictate its individual needs for project structure and plans. This chapter simply proposes ideas that you can adapt based on your scenario.

The first step is to establish the project office.

4.1 Organizing Your SOA Project Office
As seen in the preceding chapters, SOA implies a greater focus on business value. Business models are described as modular processes. This is achieved by breaking down the business and respective IT systems into components, providing reusability and modularity. Componentization, in this context, applies not just to software systems, but also to the business units across the enterprise and the organization of the enterprise in question. Implementing an SOA project involves not just a consideration of how the project is implemented in an IT infrastructure setting, but in the end, it also results in a business transformation process across the whole enterprise. To accomplish your project, you first need a roadmap to guide the strategy for your SOA adoption. To build your SOA adoption roadmap, you need to identify who is involved in the SOA project. These individuals should come from the contributing cross-business-unit teams. The actual teams you involve will depend on the level of SOA adoption you choose (see Section 4.2). Depending on business value analysis and the consequent prioritization of business objectives and services, the team defines "what to do," "how to do it," "who should do it," and "how success is measured." The SOA project team creates the rules, processes, metrics, and organizational structures needed for effective planning, decision-making, steering, and controlling the SOA endeavors. They define the common business service model, the common core processes and business components involved in the SOA project, and the core set of assets that they will use.

Building a suitable team for an SOA project requires a careful avoidance of making radical changes to existing team strategies because such changes can unduly disrupt the culture in the workplace. However, at the same time, the teams need to align with the SOA goals, which usually cut across business units. In addition, the SOA project might need to adopt a management structure - especially at larger IT shops with substantial project goals - to manage the development processes for implementing components or to expose existing applications or legacy functions in terms of the appropriate service granularity.

Achieving the right organizational structure is one of the critical challenges in implementing SOA. At organizations new to SOA, one often encounters strong resistance to change that keeps the focus on short-term successes rather than directing appropriate business transformation to align with the business challenges.

Mature SOA organizations, on the other hand, span business lines and the boundaries of roles while achieving interdisciplinary coordination. However, starting small can help to mitigate risk by allowing you to choose a well-scoped and focused services-integration project that has a modest plan for organizational evolution. A cross-unit, organization structure can address all the aspects of the SOA. Based on our experience, this structure should include the following:

• SOA business transformation architecture council: This team is in charge of gathering the business requirements, performing business domain analysis and process engineering analysis, and identifying the necessary business components, services, and process modules. Instead of following a strict top-down approach, the council should use a mixed approach in blending top-down, bottom-up, and goal-based methods to ensure appropriate services identification. In particular, this team ensures that the exposed granularity of the defined services matches the business requirements and specifications - matching business components to IT components as services. More details on granularity issues and associated services layers are described in Chapter 5, "Aspects of Analysis and Design."
• SOA technical architecture board: This team ensures the alignment of business and IT, following industry and enterprise standards, and technically ensures that exposed services match the requirements for evolution and reusability as defined in the general guidelines for the enterprise IT development. Its members are well versed in emerging industry trends, state-of-the-art technologies, and standardization efforts. They are responsible for framing the technical enterprise architecture blueprints (the master IT plan for the enterprise), identifying niche architecture patterns, and promoting reusability principles. They work closely with the SOA transformation team.
• Component design and development centers: These are the usual IT teams. They provide design and development of the components and processes, along with new skills such as business process modeling (see Chapter 5). This team delivers a solution design outline, high- and low-level design abstractions, service-oriented analysis and design (the essential aspects of which are described in Chapter 5), and various test phases such as unit, integration, system, and acceptance tests.
• Operations center: Finally, there is a production team in charge of the services components operational aspects. These aspects include managing quality of service, enforcing business and service-level agreements, managing the security context, charging back services, and assuring revenue. The team is responsible for rolling out the service, performing regular maintenance, and providing overall system management.

Based on their definitions and the associated expert knowledge, each team has a certain scope of decision-making. Depending on the size of the enterprise, the scope, the reach of the project, and the institutionalized IT governance structures, the individuals assigned to the teams can vary. Section 4.3 further explains the need for SOA governance.

4.2 SOA Adoption Roadmap
An SOA strategy should not be a big-bang replacement of an existing IT environment; rather, it should be a progressive and evolutionary roadmap. Often an overall replacement is impossible when the majority of people in the IT organization are busy maintaining the running systems. Therefore, the roadmap should reflect an iterative process.

An enterprise has several options for entry points into a service-oriented architecture. These options identify how much the SOA model penetrates into the business and defines levels of adoption. The options are as follows:

• Initial adoption: Enterprises that want to reduce risks initially go through a technology validation and a readiness assessment that analyze the technical and business impact in a defined scope. Eventually, the business and technical value realized from this scope can be extrapolated to actual implications for the organization; this usually translates into a deeper commitment to move to SOA. It involves early pilot tests consisting of creating and exposing services from business operations contained in new or existing applications. These tests are used for an early validation of several decision points such as the following:
  - The capability to transform existing legacy systems. This might include technical solutions such as messaging, adapters, and connectors, or it might lead to partnership with vendors that can provide products for a service-oriented integration.
  - The nonfunctional requirements capabilities such as performance, security, manageability, and the availability of tooling.
  - The organizational structure required to support an evolution of the enterprise, especially one that addresses skills gaps and institutes governance structures.