SOA agility in practice

Transcription

1 SOA agility in practice Service rientatin in a credit card management applicatin 1 Alced Cenen ING Card 2 built an applicatin fr its custmer base that enables it t link t new websites, implement new prduct features, and maintain credit scring rules, easily and quickly. It achieved this by applying three cnstructin principles, ne f which was service rientatin. This article describes the applicatin, and explains hw SOA helped t meet the business needs f a credit card issuer with particular challenges. Challenges A credit card business cmbines tw financial services: payment and cnsumer credit. Payment by plastic is accepted wrldwide thanks t a large payment netwrk, mainly maintained by credit card brands such as Mastercard and VISA. The card issuer usually als prvides a revlving credit facility that allws delayed repayment f the balance. The cmplete prduct is ften called revlving credit card in rder t stress this. ING Card was funded as part f the ING Grup3 in 2002, with the bjective f centralizing ING s credit card business and extending it t the Eurpean market. ING Card became a significant player in the rle f issuer in the cmplex credit card value chain (see Figure 1). ING Card uses tw credit card brands, Mastercard and VISA, that wn wrldwide payment netwrks and prvide millins f merchants (shps, htels, restaurants, car renters etc.) with card reader equipment. The reader cntracts are usually handled by acquirers: institutins (usually banks) that facilitate the settlement between the merchants and the credit card brands. Anther link in the chain is frmed by the prcessrs: rganizatins that execute the actual transactins, prvide the card authrizatin at the time f sale, and carry ut the settlement between acquirers, credit card brands and issuers. Sme institutins cmbine the rle f acquirer and prcessr. 1 This article was riginally published in Dutch. A shrter versin was published as Wendbaarheid dankzij SOA in Infrmatie nvember 2005, nr 47/9, page The extended versin was published in Charles M. Hendriks & J. Arn Osterhaven (red.), Architectuur in ntwikkeling. Landelijk Architectuur Cngres 2005, Academic Service Den Haag, 2006, ISBN , page Translatin by the authr, assisted by Chris Harding. 2 See and Octber

2 Custmer Prvides card Credit relatinship Issuer Mnthly payment Shws plastic Gds r service delivery Order fr mnthly payment Custmer s bank Payment Prcessr Merchant Authrisatin (per payment) Payment Brand Payment Acquirer Payment Figure 1 Rles in the credit card wrld Frm the start, ING Card had sme particular challenges that had a majr influence n the chice f IT slutin. The first challenge was t handle custmers wh did nt already have a current accunt with ING. Previusly, credit cards were nly prvided t existing custmers with an ING-branded current accunt, which was used fr the mnthly payment. Nw, new custmers culd have a current accunt at any Dutch bank. All custmer systems within ING in the Netherlands were identified and linked t an ING custmer accunt; but these systems culd nt nw be used fr ING Card. A cmplete new custmer management system was needed. Secndly, sale wuld be cncentrated n direct channels in the first place (Internet, call center and direct mail), with nline accunt facilities that wuld prvide the custmer with infrmatin abut all his r her transactins n a daily basis. Mrever the custmer wuld be able t change the amunt f the mnthly payment (with restrictins), and ask fr a creditlimit raise, thrugh direct channels als. This marketing strategy meant that: A website was needed fr nline accunt management by the custmer; The call center must be able t enter card applicatins and custmer questins; All data entry facilities must supprt all channels, in rder t btain the same infrmatin thrugh all channels; and The custmer management prcesses shuld be linked t the card prcessr, which takes care f the distributin f the card, f the actual accunt, and f all transactins. The third challenge was related t ne f the cre cmpetencies f any issuer: credit scring, which is needed t manage risk. The system must evaluate all card applicatins using creditwrthiness and fraud indicatrs. The furth challenge fr IT was t be prepared fr sme future develpments that were clear frm the beginning. ING card planned t rll ut in multiple cuntries and there wuld be Octber

3 different card prducts. The system must be flexible enugh t be rlled ut in different cuntries, with pssible changes in prcesses, prducts and credit scring. The fifth and last challenge fr IT arse because ING Card became cmmercially respnsible fr all existing credit card prtflis f ING in the Netherlands (the brands being Pstbank and ING Bank), with mre than 1 millin custmers. This meant that the new system must fit in with existing prcesses and rganizatins. It sn became clear that the credit scring shuld be perfrmed centrally and made available t all ther card systems within ING, s that there wuld be a single surce fr the credit business rules. In summary, the fllwing requirements had t be met: Functinal: Custmer administratin Online facilities fr the custmer Multi-channel supprt Credit scring System features: The slutin Supprt fr multiple cuntries Supprt fr multiple prducts Agility t different prcesses Agility t changes in prduct features Cupling t ther prcesses, based n the same business lgic. A decisin was made at an early stage t build the system frm scratch. A further decisin was that the system shuld be built n Websphere and Oracle. The slutin was given the name New Card System (NCS). Agility was achieved by using three cnstructin principles: 1. A layered architecture, knwn as the n-tier architecture. 2. The service cncept. 3. Parameterizatin f sme f the business classes. The traditinal three tiers (presentatin, business lgic, data) were enriched by a service layer and a business mdel layer, bth within the business lgic layer, as the means f intrducing the service cncept. Mrever the data layer was enriched by the separatin f a data access layer frm the data stre layer. The layers are depicted in Figure 2 tgether with the techniques used fr their implementatin. Octber

4 Presentatin layer Public access layer Internal access layer Realised with Struts, JSP Business layer Service layer Business mdel layer Realised with IBM Websphere (J2EE) Data layer External data surces layer Data access layer Data stre layer Realised with Realised with DAO, Hibernate Oracle Figure 2 The layered architecture f NCS The presentatin layer frms the exterir f the system and cnsists f a series f screens, supprting the main prcesses. NCS currently has the fllwing instances f the presentatin layer: Several public websites ( and which prvide the screens fr applying fr a new card. These screens call services frm the service layer that implement the applicatin prcess. A clsed and secure web envirnment that is accessible by the custmer. Here the custmer can lg in, review transactins and mnthly statements, and manage his r her accunt. It prvides facilities fr requesting a credit-limit raise, changing the amunt f the mnthly payment, requesting a secndary card, and entering persnal changes such as t the custmer s address. A data entry system fr the call center with similar functins t thse that the custmer has, and with additinal functins such as viewing all custmer data and histry. A data entry system fr the back ffice, supprting its wrk f dealing with all card applicatins. In accrdance with the layered architecture principle, the business layer is nly accessible thrugh the presentatin layer. This enables the screen designs t be independent f the business lgic. The business mdel layer is in turn accessible nly thrugh the service layer. Services are functins that are meaningful t the business. Services d nt execute these functins Octber

5 themselves, they are just a shell r facade, behind which the real functin is executed by the business mdel layer. An example f a service is findcreditregistratinpersn, which takes care f finding the right persn at the credit bureau s system (BKR is the Dutch natinal credit bureau). See Table 1 fr its full definitin. Name Service Grup Release 2.0 Usage Input Output Precnditin Pstcnditin Actins Business classes invlved findcreditregistratinpersn NewAccuntCntrller Finds persns in the BKR system creditregistratinpersn Cllectin f creditregistratinpersns The creditregistratinpersn must have agreed n checking BKR NA 1. determine the necessary data 2. sends the data t BKR 3. receives the results frm BKR 4. return the infrmatin creditregistratinpersn Table 1 Example f a service definitin The presentatin layer culd say t the business layer, Find this persn at BKR, here are the data that yu need fr it. The presentatin layer can then rely n the executin f this request and n btaining an answer. This design has three advantages: 1. The presentatin layer des nt need t be aware f technical cnsideratins (fr example, it des nt need t knw that cnversin f sme data is needed befre it can be used). 2. The sequence in which services are called can be changed easily withut any change in the business lgic layer. 3. The service call des nt need t be changed when its implementatin is changed, fr example, findcreditregistratinpersn need nt be changed when the implementatin f the CreditRegistratinPersn class is changed. The independence f presentatin frm business lgic is imprved, cmpared t the traditinal 3-tier architecture. The rder f tasks can be changed, r anther website can be added, fr example with a limited selectin f services just t shw the custmer infrmatin. There is n need t mdify the business lgic layer fr such changes. When ING Card is launched in anther cuntry, the findcreditregistratinpersn service will have anther technical implementatin fr anther credit bureau. The dialgue in the presentatin layer des nt need t be changed fr that, because the name and call f the service remain the same. The third cnstructin principle f class parameterizatin was applied within the business mdel layer. This layer cntains the real business lgic, implemented as peratrs n classes that represent the Business Object Mdel (BOM). The BOM determines the language and cnsists f a set f classes with their interrelatinships, implemented in the frm f java classes. In Figure 3 the main classes and their interrelatinships are shwn. Sme f the classes are parameterized, which makes them mre pwerful. Octber

6 NewCardRequest MaintenanceRequest Persn Organisatin Address Rule Request * 1 Party PartyRle CntactMment 1 Reference * * * 1 * Prduct Accunt Card Feature Figure 3 Extract frm the Business Object Mdel (UML class ntatin) While the classes Accunt, Party and Card are straightfrward. (they just represent accunt, custmer and card), the classes Request, Rule and Prduct have a much mre parameterized structure t give the flexibility that is needed. When a variatin f a prduct is launched in a marketing campaign, nly the cnfiguratin f the Prduct class need be changed, nt the structure f the class itself. That is made pssible by defining a generic attribute called Feature, which can cntain any pssible feature fr a prduct, which makes the Prduct class cnfigurable as required. A feature such as ne year fr free can be added easily withut having t reprgram; the actual implementatin f such a feature is nt implemented in NCS but is executed by the card prcessr; NCS nly needs t frward the right features t the prcessr. The Request and Rule classes are defined in a similar way. Fr the Rule class, there is a separate rule engine that enables flexible cnfiguratin f credit rules. In shrt, the business layer prvides services t the presentatin layer and takes care f transactins in the business mdel layer in a way that reflects the language f the credit card administratin. The business mdel layer is set up with simple and parameterized classes; the parameterized classes enable changes in prduct features, credit scring rules and request items withut impact n the verall system. The result NCS has becme the system that takes care f the management f custmers, as it was meant t be. Mrever NCS has becme the system that executes all services that custmers are ffered thrugh the website, such as making address changes r requesting a credit limit raise. Octber

7 Finally NCS has als becme the system that des the assessment f card applicatins and ffers the pprtunity t manage all kinds f credit and fraud risks. The three cnstructin principles f layered architecture, service rientatin and class parameterizatin have each cntributed t the meeting the requirements, in particular the requirements fr agility (see Table 2). realized in requirements Online facilities Multi-channel Credit scring Multi-prduct Multi-cuntry Agility f prcesses Agility f prduct definitins Pssibility t link t ther prcesses Layered architecture Services cncept Table 2 Which requirements are satisfied by which principle Class parameterizatin The layered architecture is needed t deliver multi-channel supprt. If the same infrmatin, and partly the same functinality, is t be presented t the custmer via Internet, call center and the back ffice emplyee, then a separatin between presentatin and business layer is essential t avid duplicate implementatin f functins. Class parameterizatin is needed t deliver the required time-t-market fr the intrductin f new prducts, and fr adapting credit scring and fraud detectin rules. The service cncept turns ut t be the mst imprtant f all three principles. Offering this facade f business lgic makes it pssible t rll ut NCS relatively easily in ther cuntries, enables ptimizatin f prcesses withut having t change the system, and facilitates linking with ther prcesses r ther systems. The best example f the pwer f the service layer is in internatinal rll ut. It is nw relatively easy fr ING Card t use NCS in any ther cuntry, even when there are sme majr differences. Checking the natinal credit bureau, fr example, needs a different implementatin in each cuntry. The wrk f building the interfaces remains, but the service that is called t execute the check des nt need any change. Anther example is the ability f a call center t use its wn preferred system that supprts mre than just the credit card prduct; this preferred system nly needs t call the apprpriate NCS services when a call center agent is handling a credit card request, using the screens and dialgues f its wn system; there is n need fr a deep integratin between the systems. There are many situatins where the independence f the service layer shws its value, sme f which are illustrated in Figure 4. Octber

8 custmer emplyee emplyee Website in anther language Prtal Other applicatin Wrkflw layer Other applicatins TCP-IP / HTTPS NCS service layer NCS business layer Figure 4 Several pssibilities fr the use f services Nt all aspects f SOA have been realized in NCS. The NCS layers cmmunicate via J2EE bjects, nt messages. Therefre there is n message bus and the web prtcls SOAP, WSDL and UDDI are nt used. The services have been published in a Wrd dcument, and management and definitin f services are manual peratins. In this respect the slutin appears little different frm a traditinal ne based n APIs. There is a significant difference, hwever. Services are empty, they d nthing themselves, except calling the apprpriate business functins in the right rder. This makes services much mre independent than the functins f an API design. The SOA implementatin f NCS was designed t be realized in phases. In the first phase, NCS is a simple system with a limited number f presentatin layers; that is why the services need nt be published and can be invked withut using standardized prtcls. But as sn as NCS services need t be called frm ther applicatins, it is necessary t invke them in a standardized way and prvide standardized mechanisms fr publishing and finding them. NCS has the ptential t participate in a netwrk f multiple systems, which cntributes t the agility needed by the business. NCS is a frm f agile SOA. Lessns learned Althugh many architectural principles were settled befre develpment started n NCS, many issues requiring new principles emerged during the develpment prcess. Sme interesting lessns were learned. Octber

9 Applicatin management must be prepared fr a new rle f guardian f the service catalgue. SOA needs active management f the cllectin f services (the s-called catalgue). When a prject implements new functinality, the danger f duplicatin f services must be avided. Applicatin management must be prepared fr this new task. All parties must be familiar with the service cncept; and this includes business stakehlders as well as applicatin managers and sftware develpers. When ne f these parties is frgtten there is a majr chance fr misunderstandings and bad decisins. Fr instance, when a business stakehlder des nt understand that a service can be used by an additinal system, the service culd be rebuilt in that system. When a traditinally-educated designer nly knws abut bject rientatin, there is a danger that he will make the service t tightly-cupled t the actual functin. The granularity issue (hw much functinality des a service cver?) shuld be reslved during the design, nt befrehand. Discussins abut granularity can becme unmanageable and meaningless if nt related t the actual analysis f functins. It shuld be a rule that the business mdel layer can nly be accessed via the service layer and nt directly frm the presentatin layer. It is tempting t call business class peratrs directly frm the presentatin layer, especially when the system is still islated and nt yet cnnected t ther applicatins r presentatin layers; the service layer seems redundant, and the prject may have strict deadlines that impel the prgrammer t take shrtcut slutins. Such shrtcuts, hwever, have a disastrus effect n the time t market f future develpments. All wrkflw-related functins shuld be kept ut f the service layer. When the rder f a series f functins depends n external knwledge that is nt available in the system, it is advisable t put its cntrl int a separate wrkflw layer. The use f tls that frce cnsistency between (UML) mdels is highly recmmended. In the NCS develpment prject, using a single tl fr class, activity and sequence diagrams prved t be a significant time-saver. Cnclusin Service rientatin is a cnstructin methd mre than a technlgy. Therefre SOA can be applied t just ne system, particularly when this system needs t ffer functins t ther systems r presentatin layers. Service rientatin is the next step after cmpnent based develpment, because the services prvide a shell r facade that is meaningful t the business and hides the technical cmpnents. Applying service rientatin can help the business t create the flexibility and agility that it needs, as was prven in this case f ING Card. Alced Cenen ING alced.cenen@gmail.cm Octber