img > Issue II: November 2006 > An SOA Case Study: Agility in Practice
Alcedo Coenen

Alcedo Coenen


Currently an information architect with ING Europe, Alcedo Coenen has nearly 20 years of IT experience, having also worked as a programmer and information analyst.

At ING, Alcedo has been working on multi-channel architecture, a global SOA, a credit card management system and on knowledge systems.

He can be reached at:


rss  subscribe to this author

Dr. Chris Harding

Dr. Chris Harding


Dr. Chris Harding is Director of Interoperability at The Open Group. He has been with The Open Group for over fifteen years and is currently responsible for managing and supporting its work on semantic interoperability, SOA, and Cloud Computing.

Before joining The Open Group, he was a consultant, and a designer and development manager of communications software. With a PhD in mathematical logic, he welcomes the current upsurge of interest in semantic technology, and the opportunity to apply logical theory to practical use.


rss  subscribe to this author


An SOA Case Study: Agility in Practice

Published: November 17, 2011 • Service Technology Magazine Issue II

Abstract: As boundaries within and between enterprises become increasingly permeable, there is a greater need for information flow. This is inhibited by the "information silos" formed by traditional software applications. Service-oriented architecture (SOA) replaces these silos with loosely-coupled services, enabling information to flow as needed, and delivering enterprise agility.

This is a case study from ING Card, a division of the ING Group, member of the Jericho Forum of The Open Group. It describes the first phase of their SOA implementation, with services that are hard-wired rather than dynamically discoverable. It illustrates how even this stage of SOA can deliver real business agility, and contains some interesting lessons for SOA implementation.


ING Card [REF-1] has recently delivered a milestone automation solution that has enabled it to link to new Web sites, implement new product features, and maintain credit scoring rules, with unprecedented ease and efficiently. This was achieved by applying three construction principles, the foremost of which was service-orientation. This case study describes the application and explains how SOA helped to meet the business needs and challenges and of the credit card issuing division of a major financial institution.


A credit card business combines two financial services: payment and consumer credit. Payment by plastic is accepted worldwide thanks to a large payment network, mainly maintained by credit card brands such as MasterCard and VISA. The card issuer usually also provides a revolving credit facility that allows delayed repayment of the balance. The complete product is often referred to as the "revolving credit card."

ING Card was founded as part of the ING Group [REF-2] in 2002, with the objective of centralizing ING's credit card business and extending it to the European market. ING Card became a significant player in the role of issuer in the complex credit card value chain (see Figure 1).

ING Card uses two credit card brands, MasterCard and VISA, which own worldwide payment networks and provide millions of merchants (shops, hotels, restaurants, car renters etc.) with card reading equipment. The reader contracts are usually handled by acquirers: institutions (usually banks) that facilitate the settlement between the merchants and the credit card brands. Another link in the chain is formed by the processors: organizations that execute the actual transactions, provide the card authorization at the time of sale, and carry out the settlement between acquirers, credit card brands and issuers. Some institutions combine the roles of acquirer and processor.

Figure 1: Roles in the credit card world.

From the start, ING Card had some particular challenges that significantly influenced the choice of IT solution.

The first challenge was to handle customers who did not already have a current ING account. Previously, credit cards were only provided to existing customers with an established ING-branded account, which was used for monthly payments. Now, new customers could have a current account at any Dutch bank. All customer systems within ING in the Netherlands were identified and linked to an ING customer account; however, these systems could not be used by ING Card. A complete new customer management system was needed.

Secondly, sales would be concentrated on direct channels (Internet, call center and direct mail) with online account facilities that would provide customer with information about their transactions on a daily basis. Moreover, customer would be able to change the monthly payment amounts (with restrictions) and ask for a credit-limit raises through direct channels.

This marketing strategy meant that:

  • A Web site was needed for online account management by the customer;
  • The call center must be able to enter card applications and customer questions;
  • All data entry facilities must support all channels in order to obtain the same information through all channels; and
  • The customer management processes should be linked to the card processor, which takes care of the distribution of the card, the actual account, and all transactions.

Next came the third challenge, which was related to one of the core competencies of any issuer: credit scoring, which is needed to manage risk. The system must evaluate all card applications using creditworthiness and fraud indicators.

The fourth challenge was in relation to future developments that were known in advance. ING Card was planning a roll-out across multiple countries involving the delivery of different card products. The system needed to be flexible enough for deployment in multiple geographical locations, where processes, products, and credit scoring was subject to change.

The final challenge for IT arose because ING Card became commercially responsible for all existing credit card portfolios of ING in the Netherlands (the brands being Postbank and ING Bank), with more than one million customers. This meant that the new system must fit in with existing processes and organizations. It soon became clear that the credit scoring should be performed centrally and made be available to all other card systems within ING, thereby establishing a single source for credit business rules.

In summary, the following requirements had to be met:


  • customer administration
  • online facilities for the customer
  • multi-channel support
  • credit scoring
  • support for multiple countries
  • support for multiple products

System Features

  • agility to different processes
  • agility to changes in product features
  • coupling to other processes, based on the same business logic

The Solution

A decision was made at an early stage to build the system from scratch. Furthermore, it was decided that the solution be built on IBM Websphere and Oracle platforms and be given the name "New Card System" (NCS).

The required level of agility was ultimately achieved by using three fundamental construction principles:

  1. A layered architecture (known then as the "n-tier architecture").
  2. Service-orientation (which we also referred to as "the service concept").
  3. Parameterization of select business classes.

The traditional three tiers (presentation, business logic, data) were enriched by service-orientation through the introduction of a service layer and a business model layer, both of which resided within the business logic layer. Moreover, the overall data tier was enhanced by the separation of the data access layer from the data store layer. The layers are depicted in Figure 2 along with the techniques and technologies used for their implementation.

Figure 2 - The layered architecture of NCS.

The presentation layer forms the exterior of the system and consists of a series of screens supporting the automation of the main business processes. NCS currently has the following instances of the presentation layer:

  • Several public Web sites ( and which provide the screens for applying for a new card. These screens call services from the service layer that implement the application process.
  • A closed and secure Web environment that is accessible by the customer. Here the customer can log in, review transactions and monthly statements, and manage his or her account. It provides facilities for requesting a credit-limit raise, changing the amount of the monthly payment, requesting a secondary card, and entering personal changes (such as to the customer address).
  • A data entry system for the call center with similar functions to those that the customer has and with additional functions such as viewing customer profile and history data.
  • A data entry system for the back office, supporting the processing of card applications. In accordance with the layered architecture principle, the business layer is only accessible through the presentation layer. This enables the screen designs to be independent of the business logic.

In accordance with the layered architecture principle, the business layer is only accessible through the presentation layer. This enables the screen designs to be independent of the business logic.

The business model layer is in turn accessible only through the service layer. Services are functions that are meaningful to the business. Services do not execute these functions themselves, they are just a shell or facade, behind which the real function is executed by the business model layer.

An example of a service capability is findCreditRegistrationPerson, which takes care of finding the right person at the credit bureau's system (BKR is the Dutch national credit bureau). See Table 1 for its full definition.

Table 1 - An example of a service definition.

The presentation layer could say to the business layer, "Find this person at BKR, here is the data that you need for it". The presentation layer can then rely on the execution of this request and on obtaining an answer. This design has three advantages:

  1. The presentation layer does not need to be aware of technical considerations (for example, it does not need to know that conversion of some data is needed before it can be used).
  2. The sequence in which services are called can be changed easily without any change in the business logic layer.
  3. The service call does not need to be changed when its implementation is changed, for example, findCreditRegistrationPerson need not be changed when the implementation of the CreditRegistrationPerson class is changed.

Independence of presentation from business logic is increased in comparison with the traditional three-tier architectural model. For example, the order of tasks can be changed or another Web site can be added with a limited selection of services required that output the required customer information. There is no need to modify the business logic layer for such changes. When ING Card is launched in another country, the findCreditRegistrationPerson service will have another technical implementation for another credit bureau. The dialogue in the presentation layer also does not need to be changed, because the name and call of the service remains the same.

The third construction principle of class parameterization was applied within the business model layer. This layer contains the real business logic, implemented as operators on classes that represent the Business Object Model (BOM). The BOM determines the "language" and consists of a set of classes with their inter-relationships, implemented in the form of java classes, as shown in Figure 3 (note that some of the classes are parameterized).

Figure 3 - An extract from the Business Object Model in UML class notation.

While the classes Account, Party and Card are straightforward (they just represent account, customer and card), the classes Request, Rule and Product have a much more parameterized structure that provides increased flexibility. When a variation of a product is launched in a marketing campaign, only the configuration of the Product class need be changed, not the structure of the class itself. That is made possible by defining a generic attribute called Feature that can contain any possible feature for a product and which makes the Product class configurable as required.

A feature such as "one year for free" can be added easily without requiring redevelopment. The actual implementation of such a feature is not implemented in NCS but is executed by the card processor; NCS only needs to forward the right features to the processor. The Request and Rule classes are defined in a similar way. For the Rule class there is a separate rule engine that enables flexible configuration of credit rules.

In short, the business layer provides services to the presentation layer and takes care of transactions in the business model layer in a way that reflects the language of the credit card administration. The business model layer is set up with simple and parameterized classes; the parameterized classes enable changes in product features, credit scoring rules and request items without impacting the overall system.

The Result

NCS has fulfilled expectations by establishing itself as the system responsible for customer management. Additionally, NCS reliably executes all of the services that customers are offered over the Web (such as making address changes or requesting a credit limit raise). Finally NCS also now performs the assessment of card applications, thereby allowing it to mediate all kinds of credit and fraud risks.

The three construction principles of layered architecture, service-orientation, and class parameterization have individually and collectively contributed to the fulfillment of the original requirements, in particular those associated with agility (Table 2).

Table 2 - Requirements satisfied by principle.

The layered architecture is needed to deliver multi-channel support. If the same information, (and partly the same functionality) is to be presented to the customer via the Internet, the call center, or by an office employee, then a separation between presentation and business layer is essential to avoid the duplicate implementation of functionality. Class parameterization is needed to deliver the required time-to-market for the introduction of new products and for adapting credit scoring and fraud detection rules.

Service-orientation turned out to be the most important of all three principles. By establishing a business logic facade it was possible to roll out NCS relatively easily in other countries. Furthermore, service-orientation enabled optimization of processes without having to change the system and even facilitated connectivity with other processes and systems.

The best demonstration of the power provided by the service layer came with the international roll-out. It is now relatively easy for ING Card to use NCS in any other country, even when there are major environmental differences.

Checking the national credit bureau, for example, requires a different implementation in each location. The work of building the interfaces remains, but the service that is called to execute the check does not need to change.

Another example is the ability of a call center to use its own preferred system that supports more than just the credit card product. This system only needs to call the appropriate NCS services when a call center agent is handling a credit card request, using the screens and dialogues of its own solution. In other words, there is no need for a deep integration between systems. There are many situations where the independence of the service layer shows its value, some of which are illustrated in Figure 4.

Figure 4 - Different service consumers using the services in different usage scenarios.

Not all aspects of modern-day SOA have yet been realized in NCS. For example, the NCS layers communicate via J2EE objects, not messages. Therefore there is no message bus and the Web technologies (SOAP, WSDL and UDDI) commonly used to build services as Web services are not used. The service contracts have been published in a Word document and the governance of these services are manual processes.

On the surface, the solution may not appear to be much different from a traditional, API-based applications. There is a significant difference, however. The services are not embedded with specific logic. In other words, they do nothing on their own because their primary responsibility is to compose and invoke the appropriate business functions in the right sequence. These services - the components shaped by service-orientation - therefore establish themselves as much more independent members of the solution than if they had bee developed as functions in a traditional API-based design.

The SOA implementation of NCS was designed to be realized in phases. In the first phase, NCS exists as a simple system with a limited number of presentation layers. This is why the services need not be published and can be invoked without using standardized protocols. But as soon as NCS services need to be called from other applications, it will become necessary to invoke them in a standardized way (most likely using Web services) and provide standardized mechanisms for publishing and discovery. As a result, NCS has the potential to participate in a network of multiple systems, which contributes to and fosters the needed levels of business agility.

Lessons Learned

How do you make your enterprise's SOA a success?

Service-Oriented Architecture (SOA) is now widely accepted as an architectural style organizations are leveraging to attain enterprise agility and Boundaryless Information Flow™. But, as with any area of IT deployment, there are difficulties and pitfalls. A decision to use SOA does not of itself guarantee success. IT architects must understand what SOA can and cannot do, and how to apply it within the particular circumstances of their enterprise.

The Open Group's SOA Working Group provides a forum for people from companies that are implementing SOA and companies that provide SOA solutions to discuss SOA and work on SOA-related artifacts that will benefit the IT community. As manager of that group, I have observed a very strong growth over the past year of confidence in SOA, as the evidence mounts from companies that have tried SOA and found that it works. At the same time, the supporting infrastructure needed for SOA deployment - tools, training, etc. - has become much more established. The conditions now exist for SOA to become a major style of IT architecture - perhaps the predominant style - over the next five years.

This case study from ING Card is a good illustration of the power of SOA to deliver enterprise agility. It comes from the financial sector, an area that has been at the forefront of SOA adoption. But SOA is of course also being widely used in other sectors, such as government, manufacturing, telecommunication, and utilities. In fact, in every field that uses information technology, enterprise IT architects are thinking about SOA, and what it can do, and how to use it.

The best way to make your SOA a success is to learn from the experience of others, and take advantage as enterprises with similar problems to yours report on what has worked for them. ING Card has produced a valuable report of its experience, and its case study includes many useful learning points. It is an excellent example to follow.

Although architectural principles were chosen and settled upon prior to the development of NCS, many issues requiring new principles and approaches emerged during the development process.

Listed below are some of the more interesting lessons learned:

  • IT managers must be prepared for the new role of service catalogue guardian. SOA requires the active governance of the collection or inventory of services that is accumulated so that when subsequent projects deliver new functionality the accidental duplication of services is consistently avoided.
  • All parties must be familiar with service-orientation. This includes business stakeholders as well as application managers and software developers. When any one of these parties is left out of the loop, there is a major risk of misunderstanding and, subsequently, poor decision making. For example, traditionally-educated designers who only know about object-orientation may be inclined to couple services too tightly to the actual functions.
  • Service granularity issues (such as the amount of logic encapsulated by each service) should be resolved during the design stage and not beforehand. Discussions about granularity can become unmanageable and meaningless if not related to the analysis of the actual functions that will require encapsulation.
  • It should be a rule that the business model layer can only be accessed via (and therefore only abstracted by) the service layer. It is tempting to call business class operators directly from the presentation layer, especially when the system is still isolated and not yet connected to other applications or presentation layers. From this perspective, the service layer may seem redundant and typical pressures and deadlines may incline developers to bypass services as a tactical shortcut. Such shortcuts, however, have a disastrous effect on the time-to-market of future solutions that will need to rely on the standardized interconnectivity established by the services.
  • All workflow-related functionality should be kept out of the service layer. When the order of a series of functions depends on external knowledge that is not available in the system, it is advisable to put its control into a separate workflow layer. This preserves the services as agnostic resources that can be reused in the future.
  • The use of tools that force consistency between (UML) models is highly recommended. In the NCS development project, using a single tool for class, activity, and sequence diagrams proved to be a significant time-saver.


Service-orientation is a distinct construction method. Therefore, the concepts behind SOA can be applied to just one system, particularly when this system needs to share functionality with other systems or presentation layers. Service-orientation follows component-based design as the next generation of distributing computing. Services can be positioned to provide a shell or facade that is meaningful to the business, while abstracting technical components and implementation details. Applying service-orientation can help organizations attain the flexibility and agility they require, as was proven in the case of ING Card.


[REF-1], and


Note: This article was originally published in Dutch. A shorter version was published as "Wendbaarheid dankzij SOA" in Informatie November 2005, nr 47/9, page 64-69. The extended version was published in Charles M. Hendriks & J. Arno Oosterhaven (red.), Architectuur in ontwikkeling. Landelijk Architectuur Congres 2005, Academic Service Den Haag, 2006, ISBN 9012113199, page 93-105. Original translation by the author, assisted by Chris Harding.