Section 16.1. Project Scope

16.1. Project Scope

The central book entry system of Credit Suisse comprises approximately 5 million accounts with roughly 218 million account movements per year. The service architecture described in this chapter covers the banking business. Winterthur,^[2] who also belong to the Credit Suisse Group, have their own IT infrastructure.

^[2] See Chapter 15 for the Winterthur case study.

The Credit Suisse IT infrastructure is typical of a large financial corporation and comprises around 600 applications, approximately 12 million lines of code (counting only core systems), and an application landscape based on heterogeneous platforms (IBM mainframe, Unix, Windows) grown over several decades. The roots of its IT systems reach back to the 1970s and terminal-based applications. At the end of the 1980s and the in the early 1990s, client/server applications were added, based on the then-innovative 4GL generators and object-oriented technologies using Smalltalk. With the rise of the Internet and intranets, multi-tier architectures were favored, and today, new applications are mostly built using Java. However, mainframe applications are still supported and updated, and the mainframe continues to be the preferred platform for transaction-oriented applications.

16.1.1. BUSINESS IMPACT

The main driver for the SOA introduction at CSG was the fact that the former IT infrastructure could no longer support the required business functionality. Ad hoc solutions for integrating IT systems, such as after mergers and acquisitions, were not successful.

Credit Suisse was dissatisfied with point-to-point integrations.^[3] This had made development of new applications extremely complex and sometimes unfeasible. Although no business plan was compiled prior to introducing the SOA, the decision for the SOA was made directly by the CIO in connection with two other major projects at Credit Suisse: the reconstruction of the data centers, which was necessary due to a number of mergers and acquisitions, and the clearing up of the data warehouse.

^[3] In fact, Credit Suisse suffered from the classical middleware overload created by too many products and point-to-point connections. Scenarios like that ultimately create the famous "integration spaghetti."

The SOA introduction started with small pilot projects in 1997, but it was the intention from the very beginning to use it as a basis for the overall IT infrastructure of Credit Suisse, in particular for providing host access functionality.

From the business point of view, the SOA infrastructure should become the basis for

• Multi-channel banking

• Online trading

• Consolidation of the core-business application portfolio

As the foundation of its SOA Credit Suisse designed a business-critical infrastructure that was meant to provide

• Centralized administration and management

• 24-7 operations

• Support for several thousands concurrent users

• High throughput

• Sub-second response time

The applications built on top of the new infrastructure were supposed to provide access to customers over the Internet and to employees over the intranet. This included all types of clients. Finally, extra gateways were built to realize B2B integration with partners over the Internet.

16.1.2. TECHNOLOGY IMPACT

According to [Ha03], CSG had five main goals when introducing its SOA-based integration architecture:

Technical integration. The management of dependencies between technical platforms.

Logical integration. The management of dependencies between applications and components at the level of business semantics.

Process and desktop integration. The integration of heterogeneous applications according to business processes and end user workflows.

Integration of purchased software. The introduction of methods and tools to integrate external software as efficiently as possible.

B2B integration. The integration with partners, suppliers, and customers.

CSG addressed these five goals with three different types of complementary integration infrastructures, accompanied by a workflow infrastructure for process integration. The Credit Suisse Information Bus supports synchronous communication, the Event Bus Infrastructure supports asynchronous communication, and the Bulk Integration Infrastructure uses file transfer as the basis for communication. Together, the three infrastructures form the foundation of the Credit Suisse IT landscape, whose goal is to connect business applications based on clearly defined contracts.

Figure 16-1 illustrates the domain-based integration approach underlying the Information Bus. Communication across different domains, such as securities, sales support, logistics, or data analysis, is achieved using the Information Bus and ensures a loose coupling between domains. As you can see from these examples, some domains correspond to products offered by Credit Suisse, whereas others are more horizontal and product-independent.

Figure 16-1. The Information Bus integrates different domains.

With respect to asynchronous communication, the main technical requirement was guaranteed once-and-only-once delivery of messages. The main architectural requirements for message-based interaction were

• Asynchronous connectivity and message transformation

• Real-time dissemination of critical data

• Static and content-based routing

• Topic-based publish-and-subscribe

• Point-to-point messaging

• Increased data consistency across multiple applications

• Integration of standard software

The backend core applications for integration were mainly running under IMS (80%) and CICS (20%) on large S/390 mainframes. Applications were also hosted on Unix and Windows servers. The application frontends, which were partly in use and partly under development, were based on technologies such as J2EE, C++, Smalltalk, HTML, COM, and Visual Basic.

When the Information Bus went live in 1999, five application frontends were in place, providing 35 business services to about 800 users. One year later, available applications had already risen to 21, with 173 business services and 9,000 users. These figures increased rapidly to 500 business services in 2000, used by more than 50 application frontends and over 100,000 users (this includes both Internet banking customers and internal staff).

Currently, the information bus offers more than 700 services and handles between 1.5 and 2 million requests per day, with a total of 10 million requests per week or 50 million requests per month. The Event Bus, which serves about 20 applications, processes another 500,000 messages per day.

Figure 16-2 shows the development of available services at CSG from 2000 to 2003. Figure 16-3 shows the corresponding development of service calls. The stagnation during 2001 and 2002 was due to the difficult business environment.

Figure 16-2. Development of available services at CSG from 2000 to 2003.

Figure 16-3. Development of service calls at CSG from 2000 to 2003.