Section 12.4. An Ideal World

12.4. An Ideal World

In the previous section, we discussed four pillars for ensuring the successful introduction of an enterprise's SOA. In this section, we will describe in more detail those structures and processes that should be established to achieve success. In doing so, we will draw the rosy picture of an ideal world. Subsequent sections will deal with the intricacies you will encounter in real-world scenarios.

12.4.1. STRUCTURES AND PROCESSES

A number of building blocks are useful for the successful introduction of any new enterprise-wide technology or methodology, namely:

• Whitepapers

• SOA board

• Multi-project management

• Standard processes

• Support of all actors

The following paragraphs will describe these generic building blocks in more detail. We will then address issues that are specific to the introduction of an SOA.

Whitepapers are a good medium for describing basic principles and should be used to manage the "why" and "how" issues. Ideally, there should be several whitepapers, each dealing with a particular aspect of the SOA (see Figure 12-5). A strategy whitepaper should explain the overall goal of the enterprise's SOA and its perspective over the next three to five years. Aspects to be addressed include, for example, integration with the existing infrastructure, the main business drivers behind the architecture, and the potential for integration across enterprise boundaries, such as with suppliers, partners, and customers.

Figure 12-5. Whitepapers must address various target groups.

A business whitepaper should focus on the business benefits expected from the introduction of an SOA. Ideally, it should contain a business case including predictions concerning the ROI. It should at least demonstrate the benefits of an increased reuse of implemented business functionality and the potential for the efficient development of new services for customers, employees, and partners. It could also highlight those aspects of business functionality that are ideally suited to reusability.

Finally, a technology whitepaper should address the technological issues involved in implementing the SOA. On one hand, it should explain in detail how integration of the SOA with the existing technological infrastructure is envisaged, in particular concerning issues such as asynchronous messaging or transactional behavior. On the other hand, it should describe details of the technological realization of the SOA itself. In many cases, a special platform will be used or developed to realize the technical infrastructure of the SOAthe service busand a technical whitepaper is a good place to specify the scope of such a platform and a roadmap for its implementation.

The repository is one of the key ingredients of an SOA, and it will be highly visible when services are available. The technical whitepaper should describe the repository structure in addition to processes for using and enhancing it.

Whitepapers are a good starting point for disseminating information about a new technology or methodology in an enterprise. However, as they are merely papers, their power is rather limited. What is definitely needed is an organizational entity responsible for making a technological vision work in everyday life. One way of achieving this is to establish a dedicated SOA board, which is responsible for the promotion of the SOA idea and the monitoring of its application in actual projects (see Figure 12-6).

Figure 12-6. The SOA board drives the processes and establishes the overall standards of the SOA in the enterprise's organization.

Multi-project management is required to coordinate the development of the general SOA as a generic IT strategy, in its potential as a specific technology platform, and the individual projects implementing SOA-based business functionality.

Because reuse is one of the fundamental characteristics and benefits of an SOA, the scope of a pilot project will usually have impact on other pilot projects, too. When changing project plans, such as by postponing the implementation of a service, you must therefore examine how your choice affects other projects that might rely on the timely provisioning of the service in question.

Figure 12-7 shows an example of how individual projects and the development of the SOA's infrastructure can be dependent. In this example, we assume that there is a single ongoing effort to create the initial SOA infrastructure and develop the amendments that are required by the business projects that run in parallel. We assume that the project "Pilot 1" is rolled out in two steps. Each of these steps requires certain functionality of the SOA infrastructure. Step 1 might comprise the integration of synchronously coupled frontends, while step 2 might require asynchronous backend integration. The ongoing development of the necessary infrastructure must therefore deliver the appropriate functionality in a timely manner in order to enable the rollout schedule of this project. In addition, other concurrent business projects might also require amendments to the SOA infrastructure. In our example, there is a project "Pilot 2," which is also rolled out in several steps. The last step might require asynchronous back-end integration similar to the second rollout step of "Pilot 1." Consequently, the projects "Pilot 1" and "Pilot 2" and the SOA development cannot be considered separately. Instead, multi-project management is required. Due to these dependencies, budgets must be steered not only individually but also in the context of a multi-project program.

Figure 12-7. SOA pilot projects require multi-project management.

The detailed specification of standard processes and procedures can help to significantly reduce the amount of work for the SOA board. Such processes should define how new application projects should proceed to make sure that the enterprise's SOA principles are adhered to. In particular, it is useful to define a process for the development and design of new services that also contains specific points at which the SOA board should be involved.

The process specification can be based on generic frameworks for the standardization of processes, such as 6 Sigma or ISO 9000. This is very reasonable if these frameworks are already in use within the enterprise. However, more lightweight approaches can also yield the desired effects. The important factor is to ensure that the day-to-day activities applied in designing and developing new applications or in executing projects in general comply with the principles of the enterprise's SOA.

Finally, it is vital to include all relevant actors in the establishment and implementation of the SOA. This includes management, the IT department(s), business departments, and administrators. Ideally, all actors should actively and enthusiastically support the SOA, but at least you should make sure that no actors oppose the SOA, either openly or covertly through sabotage or lack of activity.

Representing all relevant actors in the SOA board and the standard processes is a good starting point for ensuring their support, as is the constant communication with these actors and continuous monitoring of their contribution to the SOA. It is also important to appoint as board members only employees who are already well established in the enterprise. You should avoid the temptation to choose "new people for a new technology."

12.4.2. SOA SPECIFICS

In the previous subsection, we presented rather generic building blocks that are useful for introducing new methodologies and processes within an enterprise. This subsection addresses more specific aspects relevant for the successful establishment of an enterprise-wide SOA.

The most obvious starting point for standardization is the service contract used to describe and specify services. Service contracts should be made available through a central repository. In addition to the interface description, such as CORBA IDL (Interface Definition Language), WSDL (Web Services Description Language), or a tailor-made XML format, the service contracts should contain all information relevant for using the service in applications. This usually includes preconditions for service usage, special cases, potential errors, versioning information, and access rights.

It is important to make sure that the repository is broadly used and is the sole source of information regarding services. Whenever new applications are designed and developed, it should be sufficient to consult the service contracts in the repository to decide whether and how existing services can be used to build the desired functionality. If it is necessary to access additional information to make this decision, such as by interviewing service developers, this additional information should be included in the repository.

Everyone on the team must perceive the repository as a useful tool, including non-technical people. In addition to technical information, it should therefore contain detailed descriptions of the services from the business perspective. Business experts need such semantically rich descriptions to decide whether a service can be reusedthat is, whether it does what a new application requires.

Finally, you need an appropriate tool to implement the repository. As we have already briefly discussed in Chapter 4, various options for implementing a repository exist. However, the particular technical solution is often not pivotal for the successful adoption of the repository. Often, it is more important to carefully design and monitor the day-to-day processes concerning the repository.

This brings us to the issue of policies. It is vital to establish a process to ensure firstly that all service-worthy business logic is actually implemented as a service and secondly that service reuse is maximized. In order to achieve this, policies must be set up to ensure that the implementation of a service is not only tailored toward immediate requirements but that it also takes into account potential future applications. A simple means of achieving this is through a special technical or architectural board that reviews all proposed service interfaces and contracts.

A dedicated architecture board should manage the repository and review service contracts, which helps to ensure that these central artifacts find support across departments and business units.

Moreover, there should be a well-defined process for the design and specification of new applications. In particular, reuse of existing service functionality should be favored over implementation of new service functionality, even if such a reuse requires a modification of the original implementation. Again, such a process is best realized by involving a dedicated technical or architectural board.

Finally, a bonus system rewarding successful SOA projects and people can provide additional incentives to adhere to the enterprise's SOA principles and to apply them in day-to-day routines. As with any bonus system, the main challenge is to define the criteria used to evaluate success. The reuse factor of a service, that is, the number of consumers it actually has, is a good candidate. In addition, the usage (number of times a service is invoked) should be included in the equation.

Because money is ultimately one of the key factors both for people and the project, financial bonuses for successful projects are one of the best incentives. This usually requires clear target agreements with all key actors. In order to reward reusability, business departments could, for example, receive retrospective funding for their development projects after the developed services have actually been reused.

It should be clear that the setup of all these techniques and tools amounts to more or less the establishment of an SOA organization within the enterprise. This chapter will conclude with a real-world perspective on politics and strategies.