This is a case study from ING Card, a division of the ING 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 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 efficiency. 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.
Challenges
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 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
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
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.
[IMAGE]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:
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 were 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:
Functional
System Features
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.
[IMAGE]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:
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.
[IMAGE]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).
[IMAGE]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).
[IMAGE] 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.
[IMAGE]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 application. 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 been 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
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:
Conclusion
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.
About the authors
Read more about Alcedo Coenen and Dr. Chris Harding
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.
This English version of this article was originally published in The SOA Magazine The SOA Magazine, a publication officially associated with "The Prentice Hall Service-Oriented Computing Series from Thomas Erl" . Copyright © 2006 SOA Systems Inc..
