SATURN 2013 Keynote Address: 15 Years of SOA at Credit Suisse: Lessons Learned and Remaining Challenges, Stephan Murer

Notes by Frank M. Rischner, Ian De Silva, and Brendan Foote

SATURN 2013 Keynote Address: 15 Years of SOA at Credit Suisse: Lessons Learned and Remaining Challenges

Stephan Murer, Credit Suisse

Murer works for Credit Suisse, which finds competitive advantage in creating their own systems, rather than outsourcing that work to software vendors. The company handles a large-scale user base, with almost 67,750 users in 550 locations. The data is managed and stored in four main data centers. Currently, Credit Suisse manages about 6,400 applications as well as about 70,000 email accounts. The volume of the applications developed in-house is about 200 million lines of code. The number of managed applications at Credit Suisse is of course lower than in any app store, but the focus is more on the integration of the applications. The largest scalability concern Murer sees coming is storage, for example, if regulators require them to start recording video conferences for compliance reasons.

Credit Suisse was trying to reuse common, trusted applications across their entire organization to reduce their risk exposure. Indeed, they have developed over 6,000 home-grown applications that must integrate with each other to support their day-to-day business. They realized early that replacing their entire infrastructure as a whole would be cost-prohibitive. At their size, Murer finds that constant, piecemeal evolution of their infrastructure over time is the only option. To support the reuse and reduce risk, they turned to what is now known as service-oriented architecture (SOA). Key to this approach was decomposing systems into discrete pieces with clear boundaries and minimal coupling that are discoverable and interoperable. This gets them reduced integration costs, increased asset reuse, increased business agility, and reduced business risk.

Murer discussed three parts of this scheme for Credit Suisse. The first was the company’s information bus, which let the systems integrate their data. The second was creating the Global Personal Banking SOA for getting their systems to talk to other international banking systems. And finally, a platform for workflow as a shared service would allow this SOA to be leveraged easily to meet business needs.

Case 1: Information Bus. The first internet banking application was offered in 1998. Now there are about 1400 public web services and 70 message publishers. All applications offer and use services at credit Suisse. Credit Suisse used the first three years to build up the infrastructure. In 2008, they had the services complete, so it took about 10 years. It took 3–4 years until the institute believed in it, and another 5 years until the services were accepted. The process could have been completed sooner, but Credit Suisse was quite satisfied with the progress and the time spent. An organization needs time to learn, especially in larger companies.

In order to reduce risk by reusing existing back-end functionality and to support front-end modernization, Credit Suisse developed an information bus on which all of their functionality is componentized and built as software services. This support of the user interface modernization has, in their observation, reduced costs as the main functionality has remained constant over the decades, but the presentation has changed.

Governance has been key to their success. Without knowing what will be reused and what won’t, they took a build-when-needed approach, taking care not to duplicate existing services.

While reuse is an important concept in SOA, the distribution of reuse is uneven and varies based on the type of service. Where reference data services have the highest reuse, about 50 percent of the services are reused. On average, four client applications used any given service. They curate the services using an interface management system—a searchable service catalog that contains data about the services (like performance statistics) and the artifacts necessary for their use (such as UML and WSDLs). The curation support remains a challenge for them.

Case 2: Global Personal Banking SOA. Many banks expand to new geographies by acquiring local banks. Because different countries have different requirements, they want to reuse the same front end with different local back ends. In 2006 Credit Suisse started the program. The challenge here was to connect all the services in various countries and branches. Credit Suisse could not do this with a top-down approach. To perform this meet-in-the-middle development, they had to develop a business object model to improve transparency. They had to deal with heterogeneity of local back ends, distributed responsibilities, and overlaps between them. They found that an object model really enabled development by supporting understanding. The Business Object model is completely modeled with UML. Credit Suisse used the proven governance model.

Case 3: Workflow as Shared Service. Credit Suisse also wished to manage workflows (business process management) to integrate processes, decouple process management from the application, and support common activities across the company. To do this, they turned to a ready-made BPM solution supported by a custom JavaEE platform to consume services and orchestrate them. Their goal is the automation of workflows using services provided by different organizations. For example, when on-boarding new employees, many things need to be orchestrated to get the employee set up. By exposing services from the different organizations—such as HR, identity management, and payroll—they were able to automate this process.

As seen from these examples from Credit Suisse, SOA has varied uses. Indeed, Credit Suisse is working to standardize messages across the financial sector to allow multi-organization integration.

Credit Suisse did, however, encounter some problems with SOA. Security is a major challenge in banking. One example problem is that certain data cannot be combined. A service may have legitimate reasons to access data from two services, but if the service combines the data in some way, the company’s security policies are broken. This sort of access control is currently not possible. All services should be explorable but still secure. Credit Suisse takes an approach to solve this issue with a “second line of defense,” an application-level firewall.

Another difficulty is managing large service networks. Credit Suisse wants to ensure that the services are available, fault-tolerant, and compatible with each other, but it is unclear how this can be done. They want high-volume, low-latency implementations (to the order of 105 messages per second distributed to many clients). Simplified protocols (using something simpler than XML) can help with performance problems as XML can be expensive to process.

The semantic alignment is very important, since all the developers have to speak the same language.

Further, as service networks get increasingly complex, how can testing be done effectively?

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s