This chapter is from the book
This chapter is from the book
This chapter is from the book
Staying on Track
There are four keys to staying on track with the total architecture approach to SOA. The first is to justify each project on its own business merits. Each project should make business sense on its own. It should tackle specific business problems with measurable objectives and constraints. It should identify the business processes that need to be modified in order to achieve its objectives. It should maintain focus on modifying those business processes to achieve the business objectives, doing so within the project's cost and schedule constraints. Organizing projects around business objectives and business processes ensures that each project yields a recognizable business value and justifies its own cost.
The second key is to have an explicit architecture step in every SOA project that precedes the actual development work. In this step, you consider ways in which the business process participants might collaborate to get the job done and select the approach you will actually take. Some of these participants will be providing services, while others orchestrate the use of services and access legacy systems. It's a shell game, with the participants (both people and systems) being the shells and their responsibility assignments being the peas. Once you select a satisfactory architecture, you will have a detailed inventory of the required development work. From this, you can determine the cost and then know whether the project can produce the expected business benefit within the given cost and schedule guidelines. This sequence is total architecture at work.
The third key is to have an active SOA architecture group. Total architecture spans all projects and all silos. The results of each project must integrate smoothly with those of others. In fact, this is the prime requirement for service-oriented architectures—services must fit smoothly into future projects. In order to achieve this, someone must have the responsibility to determine how these pieces will fit together and to shape them accordingly, with the authority to ensure project compliance. This is the role of the SOA architecture group.
The SOA architecture group is responsible for the total architecture of the enterprise. It establishes the vision of where the enterprise is going in terms of both business process architecture and systems architecture. It is responsible, directly or indirectly, for the common infrastructure, shared services, best practices, and architectural patterns employed in the enterprise. The SOA architecture group is not an ivory-tower organization. It gets its hands dirty making sure that the work of each project integrates smoothly into the enterprise architecture. It does this through a combination of direct participation, training, mentoring, and governance reviews.
The fourth key is to have a living SOA project roadmap. The roadmap lays out the plan for present and future projects, with a two- to three-year planning horizon. It not only lays out a sequence of projects based on business priorities but also lays out the roadmap for services development: which projects will produce which services, and which future projects are expected to employ those services. This roadmap is a joint effort between the business leadership team, the IT leadership team, and the SOA architecture group.
These four keys provide the strategy for succeeding with SOA. The roadmap plans the services development. The SOA architecture group ensures that services are well conceived. The architecture step ensures that they are used appropriately. Most importantly, justifying each project on its own business merit makes it possible to sustain the investment in services indefinitely. This winning formula has been time-tested in top global and Fortune 500 companies.