Section 16.2. Implementation

16.2. Implementation

Although the CIO backed the SOA, uncertainty remained, mainly regarding technical issues. The main problem was its complexity and the overheads it created. Specifically, ensuring reusability was considered by many as a major factor in the increase of the design process cost. In addition, technical objections to the use of CORBA, which is the base of CSG's service bus, arose. Host developers believed it to be too resource-intensive, and Java developers argued that a pure J2EE approach would be more slender and thus preferable.

From the outset, Credit Suisse took this opposition seriously. The architecture was given a strong, central position within the IT department, and it was made clear that exceptions and deviations from the chosen approach would not be tolerated. Reuse was demanded, documented, and aggressively marketed, as was decoupling of systems.

A strict pursuit of the aims of the SOA and the application of rigorous processes helped to make the Credits Suisse SOA a success, and most opponents were eventually convinced by the benefits obtained by the SOA.

16.2.1. PROCESSES AND STRUCTURES

Credit Suisse established two infrastructure teams dedicated to the establishment of the SOA-based integration architectureone responsible for engineering the required middleware, and the other supporting developers using the technology. These teams were responsible for several different though related tasks and were supported by integration architects from the central architecture department (see Figure 16-4).

Figure 16-4. Different teams at Credit Suisse support the projects and maintain the SOA infrastructure.

First, the teams had to set up processes and structures accompanying the SOA introduction. In particular, this concerned stipulations for the service contracts and interfaces, in addition to the definition of a clear design and development process for services.

Second, the team had to educate and support developers from the different business units with respect to these concepts. The central challenge was to sell the concept of reusability, which at first glance, generated nothing but overheads from the perspective of developers and individual projects.

Finally, the teams were responsible for reviewing service definitions and thus acting as a kind of quality assurance. Again, reusability was the key concept here and was also the distinguishing factor compared to "traditional" project management. The team had to ensure that service development followed the established processes and fulfilled the requirements imposed by the integration architecture. In particular, it had to ensure that business units did not succeed in circumventing the SOA and get permission from management to make "exceptions."

One of the most important aspects of the SOA introduction was the establishment of a clearly defined process for service development. This process started with a communication between service consumers and service providers and resulted in a coarse-grained specification.

Based on these specifications, a decision was taken to either develop a new service or to use an already available service, which potentially had to be modified or extended to fit the new application. The architecture board reviewed this decision before the design and implementation of the service could commence.

The architecture board is composed of experienced service designers from the central architecture group and from development support.

Service development proceeded in a strict bottom-up mannerno prior planning of the service landscape took place. Instead, a service would be defined and implemented whenever a specific client application required the respective functionality (see Figure 16-5). This enabled the construction of the service architecture to take place in an efficient and incremental fashion.

Figure 16-5. The SOA-based design process at CSG: Requests are generated bottom-up, and quality assurance is ensured top-down.

16.2.2. SERVICE REPOSITORY

Credit Suisse uses a central repository to publish all relevant information about a service. The main building blocks are the business-level description of the service and the technical interface specification based on IDL (CORBA's Interface Definition Language).

Usually, different user groups require both descriptions types, but in some cases, developers access the business-level description to first produce the coarse-grained specification and then the IDL description during the actual implementation phase.

The repository also contains information about service updates, which is of particular importance for enhancing Credit Suisse services.

16.2.3. PROJECT MANAGEMENT

As explained previously, the complexity of the CSG IT infrastructure reached a critical level at the end of the 1990s. Because a complete reimplementation of the existing functionality was economically and technologically infeasible, the Managed Evolution [Ha03] approach was adopted, whereby the system is transformed step-by-step into a new state. Each project in this step-by-step process is expected to contribute to the structural optimization of the IT system.

Figure 16-6 illustrates this principle, which comprises two basic dimensions of an IT infrastructure: IT efficiency on one hand and business value on the other. Whereas IT efficiency captures how quickly and inexpensively the system can be changed, business value regards the benefit of the infrastructure for its users, that is, the business units in the enterprise. Each project should ideally contribute positively on both dimensions (see Chapter 1, "An Enterprise IT Renovation Roadmap").

Figure 16-6. The principle of Managed Evolution.

In order to guarantee this level of contribution to the overall architecture, clear guidelines, processes, and structures must be established to help distinguish "good changes from bad ones." Credit Suisse has a special architecture team responsible for defining such guidelines and monitoring their application with the chief architect reporting directly to the CIO.

The Credit Suisse methodology for the management of concrete business projects is mainly based on the waterfall model. However, the critical success factor of business projects at Credit Suisse is its control over deliveries such as interface specifications and coordination with the appropriate infrastructure teams.