Section 12.5. The Real WorldOrganization-Wide Standards


12.5. The Real WorldOrganization-Wide Standards

This section presents some examples from the real world. We begin with an example of the failed introduction of a platform project, and afterwards, we summarize the positive aspects of two of the use cases presented in detail in Part III of this book. We conclude with a summary of the lessons learned from these real-word examples and a brief sketch as to how to deal with standards spanning several enterprises.

12.5.1. AN EXAMPLE OF FAILURE

The example in this subsection is based on real-world experiences in a platform development project of a large corporation. We will use the arbitrary acronym COLOSS in the following to refer to this project and the platform itself.[2] COLOSS is realistic example of a failed introduction of a new technology and offers instructive insights into the challenges and pitfalls of such an undertaking.

[2] There is definitely no connection to the EU project in the 5th framework bearing the same name, or any other projects named COLOSS that we are not aware of.

We would like to point out that although the following description is based on a single project, it is in no way unique. Many of the problems described here are typical for large-scale projects introducing or applying new innovative technology.[3]

[3] In fact, we expect many readers to immediately notice parallels between COLOSS and their own experiences with similar projects.

The main purpose of the COLOSS platform was to provide host functionality in a standardized way, such that arbitrary frontend and mid-tier applications could easily use this functionality. The following is a brief description of the results:

Launch postponed. Initially, the project was supposed to deliver a first version of the platform after three years. This is already a considerable time frame, even for a strategic development project. However, when the platform was not "finished" after the initial three-year period, its launch was postponed several times, until after five years it became apparent that the whole endeavor was seriously flawed.

Scope creep. During the project, more and more functionality was assigned to or claimed by the platform. This particularly included functionality for session management, security, and transactional behavior.

Obsolete technology. Due to the long project duration and the additional delay, the technology used in the project became more and more obsolete.

As a consequence, support for the COLOSS platform crumbled. Whereas in the beginning, the platform was envisaged as a significant step forward that would considerably facilitate development of new applications, it was seen as more and more of a bottleneck threatening all development projects in the enterprise.

For example, projects began to devise workarounds that would access host functionality the "traditional" way because it was unclear whether COLOSS could provide the corresponding functionality on time. Similarly, projects developed their own solution for platform functionality such as transactions, security, session management, etc.

Instead of standardizing and facilitating the enterprise-wide development process and fostering reuse, the failure of the COLOSS project caused an even more heterogeneous infrastructure with many redundancies.

In hindsight, several lessons can be learned from this failure. You should bear in mind the following key recommendations when introducing a platform based on new technology:

Avoid Technology Focus. Perhaps the most critical mistake of the COLOSS project was that it was conceived as a technical platform development project that was not immediately tied to any business project. Though this made sense from a conceptual viewpoint, the IT focus caused a lack of synchronization between IT and business projects and was also ultimately responsible for scope creep and the delayed launch.

Start Small. Instead of aiming at a fully developed platform providing a high degree of functionality, it would have been more reasonable to start with a small prototype offering limited functionality. First, such a prototype would have been finished after a smaller time span. Second, it would have been possible to combine this prototype with a specific business project, allowing for immediate evaluation.

The next section will present some positive examples from the real world, which contrast pleasantly with the failings described in this section.

12.5.2. TWO SUCCESS STORIESSOAS AT CREDIT SUISSE AND WINTERTHUR

In this section, we briefly cover the SOA introductions at Credit Suisse and Winterthur, which will be described in detail in the respective case studies in Part III. Credit Suisse Group is a leading global financial services company headquartered in Zurich. Founded in 1856, the company operates in over 50 countries with around 64,000 staff members. Winterthur Group is a leading Swiss insurance company providing a broad range of property and liability insurance products. Winterthur Group has approximately 23,000 employees worldwide.

For the moment, we will concentrate on the main characteristics that helped to make the SOA introductions a success. Interestingly, the purpose and intended functionality of these SOA introductions are quite similar to the COLOSS project. The main focus is on making existing host functionality available in a standardized way so that it can be efficiently used by newly developed business applications.

Probably the most striking difference from the COLOSS project is that both Credit Suisse and Winterthur adopted a type of bottom-up approach. Instead of first developing a complete platform, which would then be utilized in concrete business applications, platform development was accompanied and even driven by small pilot projects.

This approach helped prevent isolation of the platform development and kept the focus balanced between business needs and technological features. It also facilitated the quick gathering of experience and the adoption of the SOA strategy accordingly.

Moreover, this approach was emphasized by the fact that both Credit Suisse and Winterthur focused on SOA as a general philosophy so that the platform used to implement it was only seen as one of several ingredients, albeit an important one. From the beginning, great care was taken to establish structures and processes supporting the SOA introduction. In particular, dedicated teams were set up whose members acted as evangelists, educating business departments and development teams of application projects using the SOA.

Both groups also allocated a sufficient budget to the pilot projects and to the SOA teams. This enabled the SOA teams, for example, to compensate the business departments for the overhead caused by aligning the pilot projects with the SOA philosophy, such as adopting reusability considerations.

Finally, special boards monitored compliance with the enterprise-wide SOA standards and "enforced" reusability of the developed services. These boards include representatives from different business departments together with those of the IT department. This yielded several positive effects. First and foremost, it guaranteed a basic level of transparency and visibility from the very beginning. Business departments that were not yet developing or using the new services were already involved in the design process to ensure reusability. As a side effect, these departments obtained information about the progress and benefits of the SOA.

This process also helped to avoid the creeping emergence of diffuse fears. Staff and departments not involved in the development of a new silver bullet that is supposed to change the whole enterprise inevitably start to worry about their own place in the enterprise's future. If this development takes place not behind closed doors but openly instead, risks of sabotage and hidden or open opposition should hopefully diminish drastically.

Due to careful planning and execution, the SOA introductions at Winterthur and Credit Suisse received widespread recognition across the enterprise. The respective SOAs are seen as a success, and departments contribute actively and apply the SOA principles in their day-to-day routines. They do so not only because these principles are mandatory but also because they can see the associated benefits for their own activities in addition to the enterprise as a whole.



    Enterprise SOA. Service-Oriented Architecture Best Practices
    Enterprise SOA: Service-Oriented Architecture Best Practices
    ISBN: 0131465759
    EAN: 2147483647
    Year: 2003
    Pages: 142

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net