Section 14.2. Implementation

14.2. Implementation

As mentioned previously, the main reason for implementing the SOA at Deutsche Post was the realization that the IT landscape existing at that point in time was too expensive and complex to maintain and extend. Interestingly, this was not due to the existence of mainframes and host applications, as is often the case in large corporations.^[7] No such systems were in use at Division Mail. Complexity simply stemmed from the interfaces and the high degree of intertwining between the existing point-to-point interfaces and applications.

^[7] This is further evidence for the fact that the quality of a software architecture is largely independent of technology. Both brand new developments comprising Java, C++, and decentralized servers and traditional environments based on COBOL, C, and centralized mainframes can equally serve as a base for an efficient architecture.

As this complexity led to the failure of projects at Deutsche Post, it prompted a change in the infrastructure. No real alternative to an SOA was investigated in detail, as no other option seemed sufficient. At the beginning of the SOA introduction, costs for the initial business projects and for the Service Backbone development were estimated. However, no detailed business case was compiled, as it seemed obvious that changing the infrastructure into an SOA was inevitable.

Although there was no resistance on the conceptual level against the SOA approach, some problems arose as soon as implementation started. The next section describes the processes and structures used by Deutsche Post to overcome these challenges.

14.2.1. PROCESSES AND STRUCTURES

Deutsche Post differentiates two major types of components in its SOA. There are service providers, which offer services, and service consumers, which use those services. Obviously, a piece of code can act as a service consumer with respect to some services and as a service provider with respect to other services (see Chapter 5 for the discussion of basic and intermediary services).

Deutsche Post defined a clear process for achieving a service design that was accepted across the borders of a single department (see [HBa04]). When implementing a new service provider, the following steps must be executed:

• Identify all potential service consumers.

• Specify business functionality of the new service according to the requirements of all potential service consumers.

• Match business requirements to Business Domain Model and implemented services.

• According to the findings, define and start an implementation project for this new service provider.

• Create a service description, service-level agreement, and an XML Schema for publishing the service to potential service consumer.

• Connect service provider to Service Backbone by deploying the SBB interface locally.

• Register service provider in SBB user directory.

In order to connect a new service consumer to the SBB, the following two steps must be processed:

• Insert service consumer information in SBB user directory for authentication and service authorization.

• Connect service consumer to SBB by deploying the SBB interface locally.

As we mentioned earlier, when this process of service development was introduced at Deutsche Post, some problems emerged that were mostly related to division of labor and sharing of responsibilities. For example, when a project initiated the development of a service, all potential consumers of the service had to be consulted. On one hand, it was not easy to get future consumers interested, and on the other, it meant that actors "not paying" for the service development gained influence. In general, business units were concerned that they would lose control over their services.

The SOA development at Deutsche Post started with a "closed user group," which helped to keep resistance limited. The business units involved in the initial projects were in principle in favor of the SOA. But even here they had to be constantly convinced that the SOA would help them to make their own development projects more efficient and less expensive. They were also offered support by the SOA team on the technical level.

However, it became clear quickly that introducing the SOA at Deutsche Post amounted to a paradigm shift within the corporation. To successfully perform this shift, a dedicated business unit was set up. This unit comprises teams that are responsible for supporting the individual business units, making sure that each business unit has a specific team available to help them with the implementation of the SOA.

Work in the unit centered around two focal points: governance and business support. Governance was concerned with the development of strategies and guidelines and was mostly internal. Business support consisted of helping the business units involved in development projects with any SOA-related challenges they encountered. In doing so, adherence to the internally developed strategies and guidelines was also ensured.

Half of the business unit was hired externally through head hunters, contacts within the SOA community, and word of mouth. Only a few employees from Deutsche Post were included in the business unit. This was because the number of IT experts available for internal relocation at Deutsche Post was simply not sufficient. In addition, employees of this new business unit needed special skills.

The skill profile demanded, on one hand, extensive knowledge of Service-Oriented Architectures, object-oriented programming, XML technology, and open W3C standards such as Web services. This included in particular knowledge about available state-of-the-art tools, discussion topics in forums, and current trends in these areas. On the other hand, employees had to have experience regarding project management, quality assurance, requirements analysis, and the corresponding soft skills needed in team-oriented development projects.

The business unit is directly responsible to the management board of Division Mail at Deutsche Post AG and is thus on the same level as Marketing, Sales, or Production.

Another concern with the introduction of the SOA consisted of the overhead it caused during the initial development of services. Deutsche Post used two means to make sure that reusability was taken into account during the design process. First, potential service consumers were involved in the design process. Second, the IT strategy unit reviewed the service designs and insisted on a level of abstraction that would make sure that the services would be reusable.

Interestingly, the experience gained regarding the SOA overhead was that the additional costs were rather limited. In particular, they were mostly caused by increased communication requirements and not related to technological issues. Nevertheless, it is important to take into account the communication overhead when planning project budgets. One way that Deutsche Post dealt with it was allowing the central business unit responsible for the SOA introduction to subsidize the overhead resulting at the business units. Of course, to make this possible, a suitable budget has to be foreseen for these subsidies.

14.2.2. SERVICE REGISTRY

Deutsche Post uses a registry to store information about available services. It basically contains:

• Syntax of the service interface

• Meta information concerning security, binding, and authorization

• Versioning information

Versioning turned out to be a particularly important aspect of service development at Deutsche Post. Because services were developed incrementally, it often happened that new versions had to be released to address new requirements. Because it was not feasible to migrate all service consumers immediately to new service versions, different service versions were provided in parallel. However, obsolete versions were only supported for a transitional period to avoid uncontrolled growth of service variants.

14.2.3. PROJECT MANAGEMENT

For Deutsche Post, the SOA's main benefit from the project management point of view consists of the reduction of interface complexity and the decentralization of software development. Because individual service implementation projects can be carried out flexibly and in a decentralized fashion, the risks inherent in large projects are substantially reduced. Moreover, the application landscape can be developed step by step, while the strategic flexibility is maintained in the long term.

Although its general approach to project management did not change drastically, Deutsche Post did have to make some adjustments and extensions. The most obvious innovations concerned the establishment of a dedicated IT strategy unit (see Figure 14-3) and the process for service design as depicted in Section 12.1.1. As a consequence, development became slightly more complex, and new roles and activities had to be included because of the reusability aspect. However, it should be noted that the effort for developing the functionality itself was not affected. An overall service coordination had to be established, which had two main purposes. First, guidelines had to be developed including standards for service interface design. Second, adherence to these guidelines had to be checked constantly during the development process.

Figure 14-3. The business unit "IT Strategy Mail" provides distinct teams supporting the individual business units.