11/9/2016 SOA in Banking: A Review of Current Trends and Standards based on an Example of a Real-Life Integration Project Delivered to a Financial

Services Cu
RelatedSites

ServiceTechMag.com>IssueLXXXIV,May/June2014>SOAinBanking:AReviewofCurrentTrendsandStandardsbasedonanExampleofaRealLifeIntegrationProjectDelivered
toaFinancialServicesCustomer

LeszekJaskierny

SOAinBanking:AReviewofCurrentTrendsandStandardsbasedonanExampleof
aRealLifeIntegrationProjectDeliveredtoaFinancialServicesCustomer
Published:June11,2014ServiceTechnologyMagazineIssueLXXXIV

Biography
MasterITArchitect,workingforHewlett
Packardsince2002,has17yearsof
experiencewithComputingIndustry,
deliveringprojectfortheFinancialServices
customers.Leszekhasgained
programming,solutiondevelopmentand
projectleadingexperience,buildingIVR
systems,databaseprojectsandWeb
applications.PriortojoiningHP,Leszek
workedforMetrosoft,Inc,delivering
solutionsformajorUSbrokeragehouses
andinvestmentbanks.
Representativeaccomplishmentsare:
SOAplatformimplementationforNational
BankofPoland,MultiChannelPlatform
andCorporateElectronicBanking
applicationforLukasBank(Credit
Agricole),InvestorPhoneSystemforTD
WaterhouseandQuick&Reilly,
BloombergInvestorPhoneforGTEAirfone
(Verizon).Leszekscurrentfocusison
InternetBankingSolutions,Service
OrientedArchitecturefeaturingboth,JEE
and.NETtechnologies,Enterprise
SecurityandMasterDataManagement
solutions.
Contributions
SOAinBanking:AReviewofCurrent
TrendsandStandardsbasedonan
ExampleofaRealLifeIntegration
ProjectDeliveredtoaFinancial
ServicesCustomer

Abstract:Thefollowingarticleisbasedontheexampleofanactualbankingproject,deliveredbyHP
ProfessionalServicestoamajorEuropeanbank.Asimilarapproachhasbeentakeninotherintegration
projectstoextents,dependingonthelegacyconstraintsandrequirementsofthecustomer.
Introduction
Duetorapidgrowthinthemarket,aEuropeanbankdecidestoreplaceitsITapplicationinfrastructure,
includingitscoreprocessingsystem,integrationplatformandallfrontenddeliverychannels.Oneofthe
challengesofthisprojectwastheintegrationofover20backendsystemsbeingusedbythebank,as
wellasintegrationwithexternalserviceproviders.
Threemainchallengesoftheprojectwere:(1)businessrelated,tobridgethegapbetweenbusiness
requirementsandtechnicalspecifications,(2)managementrelated,toshortendevelopmenttimeand
meettheaggressivetimelineoftheproject,and(3)technical,toassurethatperformancerequirements
willbemetonthegivenhardwareplatform.Theperformanceofthetransactionalsystem,especiallythe
middlewarelayer,isextremelyimportantbecauseofstrictrulesimposedbythesystemsbeinginterfaced.
AnexampleishowATMrequestsprocessedintheonlinemodearegovernedbystricttimeoutrules.
Twokeyareasofthesolutionwere:(1)thedefinitionofaunified,enterprisewidedatamodelfor
communication,and(2)selectionoftools,allowinghighleveldefinitionoforchestratedservices,thatwill
meetagreedperformancerequirementsintheproductionenvironmentandallowbusinessanalyststo
participateintheservicedesignprocess.
Theprojectteamacknowledgedthattheresultingdatamodelwouldneedtofollowbusinessrequirements
butalsoneedtocomplywiththerequirementsoftheexistinglegacysystems.Whilebasicdata
transformationscanbeperformeddirectlyintheserviceinterfaceofthebackendsystems,finegrained
businessrequirementscanbefulfilledonlybytheorchestrationofcoarsegrainedbackendservices.
Incontrasttobusinessservicesexposedbythebackendapplications,servicesresultingfromthe
orchestrationwerecalledvirtualservices.

Bookmarks
DiggThis
De.licio.us
Slashdot
Technorati
StumbleUpon
GoogleBookmark

Figure1
UnifiedDataModel
Buildingaunifieddatamodelwasthefirststeponthetransformationroadmapforaserviceoriented
architecture.AfteranITassessment,21differentbackendapplicationshavebeenidentifiedthatprovided
variousservicesinthebank'sproductionenvironment.Applicationswereoperatedinternallybythebank
itselforexternally,usuallybyanotherbank,exposingasetofremoteservices.Afteridentificationofthe
distinctdataareas,a"primaryowner"or"sourceapplication"(applicationthatownstheparticulardata)
hasbeenassignedtoeachdataarea,redundancies(multiplesystemsstoringthesamedata)havebeen
identifiedandfinallysystemsthatweredependentontheselecteddatahavebeenfound.Asaresult,
representationoftheparticulardataitemhasbeendefinedasanXMLschematype.
HowtoStarttheProcess?
Commonapproachestothedatamodelingwereto:
Selectanduseanindustrystandarddatamodel
Selectandcustomizetemplate(s)
Buildmodelfromscratch
Thefirstoptionwasruledout,becausetherewerenosinglestandarddefiningendtoendbanking
operations.Also,countryspecificregulationsareveryofteninconsistentwithparticularstandards,leading
totheneedforproprietaryextensions.
Thelastoptionwasruledout,becausetheeffort(costandtime)estimatedforthe"buildfromthescratch"
approachfarexceededtheavailableresources.

http://www.servicetechmag.com/I84/0514-2

1/7

11/9/2016 SOA in Banking: A Review of Current Trends and Standards based on an Example of a Real-Life Integration Project Delivered to a Financial Services Cu
AUnifiedDataModelwascreatedbasedonatemplate:XMLReferenceDataModeldevelopedbyour
team,usingseveralindustrystandardsandapplicabletothefinancialindustry,likeSWIFT,IFX
(InteractiveFinancialeXchange)orISO20022(ISOStandardforFinancialServicesMessaging),and
drawingonourpracticalexperiencespreviousprojects.
Thisselectionallowedforapragmaticapproachtothestandardizationprocesswithinthebank.Insteadof
enforcingsomespecificstandard,itprovidedaneffectiveframeworkandtemplatesfortheimplementation
teamsinalltherelevantbankingoperations'areas.ItwaspositionedaneffectivebaselinefortheGap
Analysisandsubsequentanalyticalanddesignactivities,withthefinalresultbeingafull,customizedXSD
representationoftheactualbank'senvironment.Wefoundsuchanapproachverypracticalandeffective
inseveralotherbankingprojects.
Anotherquestiontobeansweredwasthescopeoftheproject,definedas:
enterprisewideproject
domainorientedproject
Althoughtheprojectwouldfollowsimilarstepsandactivitiesinbothcases,anenterprisewideproject
wouldrequiremuchstrongergovernance,inordertosynchronizeworkperformedbytheteamsfocusing
onparticulardomains.
Theprojectreferencedinthisarticlewasrecognizedasanenterprisewideproject,andtheworkwas
organizedaroundthefollowingactivities:
1.createcatalogoffunctionalandnonfunctionaldomains
2.recognizelinksbetweenidentifieddomains
3.createacommondictionarythatwillbesharedbyalldomains
4.createdomainspecificdictionariesappropriateforparticulardomains
5.identifyanddocumentdomainspecificdatastructures,startingfrommostcharacteristicdataentities
relatedtoparticulardomain
IdentificationofBusinessDomains
ParticulardomainsandsubdomainshavebeenassociatedwithdifferentbusinessunitsoftheBank.For
example:
Usermanagement,includingmaintenanceoftheuserdata,permissionmodels,relationswiththe
customershavebeenassociatedwithelectronicbankingdepartment
Managementofthebankingproductshasbeensplitintoseveraldepartmentsresponsiblefordifferent
productlines,e.g.deposits,linesofcreditandcreditcards
Transactionprocessingwasalsosplitbetweenthebackoffice,whichisresponsiblefortransactions,
versustransactionoriginationandauthorizationthathasbeenmanagedbytheelectronicbanking
department.
Althoughsalesprocessesaremainlyorganizedaroundsalesofthebankingproductsandproduct
relatedservices,theyareusuallymanagedbyaseparatedepartmentratherthandepartmentsbeing
responsibleforparticularproductsthemselves.
Anotheraspectofsuchasplitwasthedefinitionofdataownership.Dataownershipcanbeviewedfrom
anIT(technical)orabusinessperspective.ITismainlyfocusedonwheredataisbeingstored,while
businesslooksatthedatafromanoperationalperspective.Veryoftenthosetwoperspectivesare
different.Forexample,incaseofthebankusingmultiplecorebankingsystems(CBS)dataentities
belongingtothesamelogicaldomainarestoredindifferentcoresystems.Lookingfromthisperspective,
theapplicationoflogicalviewsallowsfortheidentificationofimportantlinksthatarenotvisibleonthe
technicallevel.
Thefollowingdiagrampresentsdifferentwaystosplitthedata,dependingontheviewpointsdescribedin
thenextchapter.

Figure2
DefinitionoftheDesignStandards
Theconsequenceofthedecisiontofollowserviceorienteddesignapproachwastheabilitytoinvolve
businessatanystageoftheproject,startingfromtheanalysisthroughtodesign,implementationand
maintenance.Inordertoensurethatsuchcooperationispossible,theprojectteamhadtopreparesetof
simple,yetextremelyimportantdesignstandardsenablingthiscooperation,suchas:
namingconventions
organizationofthephysicalassetsoftheproject,includingorganizationoftheprojectfoldersandfiles
structureofthedatadependenciesontheanalyticallevel
decisionsonthetoolsanddocumenttemplatesthatwillbeusedbytheanalystanddeveloperteams
introductionoftheservicegovernanceelements
NamingConvention
Aruleofthethumbisthatnamingconventionsshouldbeselfexplanatoryandhumanreadable.Itisalso
goodtoagreeontheconsistentusageofastructureandtousefixedpartsofthenamedefiningits

http://www.servicetechmag.com/I84/0514-2

2/7

11/9/2016 SOA in Banking: A Review of Current Trends and Standards based on an Example of a Real-Life Integration Project Delivered to a Financial Services Cu
purpose.BelowareexamplesofnamesusedasapartofdefinitionoftheXSDschema:
AmountType
CrcType(currencyISOcode)
NameType
AddressType
EmailAddressType
PhoneNumberType
...
UserBasicType
UserPersonalType
UserCorporateType
UserPermissionsType
UserType(orUserElement)
...
SetUserReq
SetUserResp
GetUserReq
GetUserResp
...
Thefirstpartoftheexampleshowsbasictypes,thatmightbeeitherenterprisewide(asAmountor
Currency),ordomainspecific,suchasAddresstype.
Thesecondpartshowsdomainspecifictypes,where"basic"typeisalwaysdefiningaminimumsubsetof
thedatacommonforallthesubtypes.Anexampleishow"personal"and"corporate"subtypesofthe
userisdemonstratingdifferentidentitiesofthesameentity(e.g.theusercanbeidentifiedasanemployee
ofthecorporation,orindividualcustomerofthebank)."Permission"typeisanexampleofasetof
propertiesthatareapplicabletoanyuser.Finally,UserTypeisasupertype,groupingallpossibledetails
oftheusertogether.
Thethirdpartoftheexampleispresentingmessagepartsthatwilllaterbeusedtobuildservicesand
serviceoperations(functions).
OrganizationofthePhysicalAssetsoftheProject
Althoughitmaysoundlikeaminordecision,theorganizationofthedatamodelintermsoffoldersand
filescanhavesignificantconsequences,bothforITandforbusiness.Whilethetechnicalapproach
focussesontheorganizationoffilesbasedontheirtechnicalproperties(e.g.simpletypes,complextypes,
interfaces),thebusinessapproachwouldbeorientedaroundgroupingthefilesbasedondataownership.
Enterprisescaleprojectsusuallyrequireanumberofteamsworkinginparallel.Properorganizationofthe
physicalassetswasveryhelpfulinachievingacertainlevelofindependencebetweentheteams,focusing
ondifferentbusinessdomainsandworkingwithdifferentcounterpartiesfromthebank.
StructureoftheDataDependenciesontheAnalyticalLevel
Anotherfundamentaldecisionistodistinguishbetweenenterprisedatathatwillbesharedbetween
variousbusinessdomainsanddomainspecificdatathatmostlikelywillbegovernedwithinthedomain.
Inbothcases,commondatawillbeorganizedintheformofdictionaries.Whiledomainspecific
dictionariesaregovernedlocallybytheteamresponsibleforthatparticulardomain,enterprisedictionaries
willbesharedbetweentheteamsandhencewouldrequirespecialgovernanceprocedures.
ToolsandDocumentTemplates
Themostimportantpartofcollaborationbetweentheprojectteamsistofocusonthebusinessand
functionalcontexts.Thisiswhyproperselectionofthedesigntoolsanddocumenttemplatesiscriticalfor
effectivecollaborationbetweentheteams,ensuringthattheresultscanbeeasilysharedandmerged
togetherontheenterpriselevel.
Selectionofthetoolsfordatamodeling.
Intheprojectreferencedinthisarticle,achoicewasmadebetweentwotools:
EnterpriseArchitect(SparxSystems)
XMLSpy(Altova)
Whilethosetoolsaresignificantlydifferentinnature,bothallowforthedefinitionandmaintenanceofthe
datamodel.Themaindifferencesarethefollowing:
EnterpriseArchitectallowscreationofvariousviewsofthemodel,startingfromahighlevel,logical
model,followedbydifferentbusinessandimplementationperspectives
XMLSpyfocusesonthetechnicalviewofthemodel,showingonlyoneperspectiveorganizationof
thedatathatwillbeusedbytheservices.
ThechoicemadeontheprojectlevelwastouseXSMSpyasaprimarydatamodelingtool,becauseof
theoutstandingqualityoftheXSDproducedbythistool.
Intheotherproject,asimilardecisionrelatedtothechoicebetweenEAandXMLSpyledtomixed
approach.ThanksahighqualityAPIexposedbyEA,smallapplicationweredevelopedtoautomatically
synchronizeworkbetweenthetwotools.
IntroductionofServiceGovernance
Servicegovernanceisessentiallyrelatedtocentralmanagementoftheenterpriseresourcesthatspan
betweendomainsandbusinessareas.Allthealreadymentioneddesignstandardsarecontributingtothe
overallgovernance,butcoveronlyoneaspect.Toolsandtemplateswon'tworkwithoutstrong
managementproceduresthatneedstobefollowedatanystageoftheproject.
Unfortunately,eventtemplatesandproceduresarenotsufficientforoverallsuccess.Itcouldbethecase
that,especiallyduringtheanalysisphaseoftheproject,workdoneinaccordancewithagreedstandards
couldleadtomeaninglessresults.Intheprojectreferencedinthisarticle,ateamworkingonthe
transactionauthorizationprocedurescametothepointwhereprocessesweresocomplicatedthatthere
wasnosimplewaytomodeltheminanyoftheavailabletools.

http://www.servicetechmag.com/I84/0514-2

3/7

11/9/2016 SOA in Banking: A Review of Current Trends and Standards based on an Example of a Real-Life Integration Project Delivered to a Financial Services Cu
Suchilluminatethemostimportantaspectofgovernancestrongleadership.ItcouldbetheChief
Architectoranyotherteammemberwithaclearvisionoftheoverallsolutionandtheabilitytoputseveral
smallbitsandpiecesintothebigpicturetorepresentexpectedresultsoftheproject.Inthereferenced
project,thedecisionwasmadetoestablishanArchitectureBoardconsistingoftheChiefArchitectanda
fewotherteammemberswithgoodoverallknowledgeoftheproject.Throughouttheprojectthe
ArchitectureBoardwasresponsibleforreviewingofalltheanalyticaldocuments,toachieveoverall
consistency.Incaseofconflicts,membersoftheArchitectureBoardweredealingwithbusinessto
producesatisfactorysolutions.
DefinitionofthePhysicalDataModel
Definitionofthephysicaldatamodelwasfollowingtopdownvs.bottomupapproach.
TopDownApproach
Theprimaryfocusofthetopdownapproachwastounderstandthefutureneedsofthebusiness
stakeholders,by:
gatheringuserrequirements
definingandcatalogingtheservicesrequiredtosupporttheuserrequirements
mappingtherequiredservicesonthedatamodeltemplates
finetuningthemodel

Figure3
BottomUpApproach
Thebottomupapproachfocusedontheexistingapplicationsby:
reviewingenterpriseassets
identifyingandcatalogingtheservicecandidatesfromtheexistingapplicationassets
mappingselectedservicecandidatesonthedatamodeltemplatesandfinetuningthemodel

Figure4
DesignoftheXMLSchema
Resultsofthetopdownandbottomupanalysesleadtothecreationoftheunifieddatamodeldefinedas
anXMLschema,where:
functionalblocksweregroupedaccordingtobusinessdomains,suchascustomerdata,
account/productdata,transactiondata...
technicalandbusinessdatatypesweredefinedincommondictionariessharedbyallthebusiness
domains

http://www.servicetechmag.com/I84/0514-2

4/7

11/9/2016 SOA in Banking: A Review of Current Trends and Standards based on an Example of a Real-Life Integration Project Delivered to a Financial Services Cu
thereferencedatamodelprovidedbasicstructures(ortemplates)thatmaybeextendedduringthe
analysisprocess

Figure5
TheprefixCFMstandsforCommonMessageFormat.Invariousbankingprojects,datamodelsdefined
forparticularbankswerenamedindividuallyforeachbank.Forexample,themodelforBankXcouldbe
namedBXMF.
DesignoftheServiceMessages
AlthoughXSDwasusedtodefinedatastructures,theultimategoaloftheSOAprojectwasdefinitionof
theservices.Thisiswhythedatamodelwasusuallyreferredtoasa"messagemodel".
Messagespecificdatatypesextendedthefollowingabstracttypes:
CommonRequestType

Figure6
CommonResponseType

Figure7
Usageofthecommontypesforrequestandresponsemessagesbroughtanotherlevelofstandardization.
DespitetechnicaldatatransferredincaseofWebservicesintheSOAPheader,commontypeswere
definingcommonpartsofthebodyofthemessages.
DesignofWebServices
TheWebservicesweredefinedfor"businessservices"exposedbythebackendsystemsandfor"virtual
(orchestrated)services"exposedbytheserviceorchestrationengineseparately.Inbothcases:
TheWebservicedefinitions(WSDLs)referredtodatatypesdefinedbytheunifieddatamodel(XSD)
Theunifieddatamodelwassharedbetweenalltheunitsoftheorganization
Theunifieddatamodelwasappliedtotheservicesprovidedbytheapplications(implementation
services)andorchestratedservices(virtualservices)

http://www.servicetechmag.com/I84/0514-2

5/7

11/9/2016 SOA in Banking: A Review of Current Trends and Standards based on an Example of a Real-Life Integration Project Delivered to a Financial Services Cu

Figure8
SelectionofServiceOrchestrationTools
Theabilitytocreatefinetunedbusinessservicesfollowingdetailedspecificationspreparedtogetherwith
thebusinesswasoneofthefundamentalrequirementsthatjustifiedadoptingtheserviceoriented
approachfortheproject.
Theselectionoftheserviceorchestrationtoolwasbasedonthefollowingsetofgoals,highlighting
particularbusinessandtechnicalrequirementsoftheproject:
Goal1:DefinebusinessprocessesthatinteractwithexternalentitiesthroughWebserviceoperations
definedusingWSDL1.1.ThemessagepartoftheWSDLshouldreferonlytothecomplextypes(or
elements)definedintheschemaoftheunifieddatamodel.
Goal2:Usewellknownandwidelyadoptednotation.
Goal3:Avoidtightdependencybetweenthedesigntoolandtheworkflownotation,inordertomakeit
portablebetweendesigntools.
Goal4:Providedatamanipulationfunctionsforthemanipulationofdataneededtodefineprocessdata
andflowcontrol.
Goal5:Supportanidentificationmechanismforprocessinstancesthatallowsthedefinitionofinstance
identifiersattheapplicationmessagelevel.
Goal6:Supporttheimplicitcreationandterminationofprocessinstancesasthebasiclifecycle
mechanismandbuildflowcontrolmechanismtoenforcethesequenceoftheactions.
Goal7:Definealongrunningtransactionmodelthatisbasedonproventechniques.
Goal8:Implementazerocodingpatternwhendesigninganddeployingorchestratedservices
Thetoolthatwasselectedfortheprojectwasbasedontheproprietarysolution,andisduetobereplaced
byanofftheshelfsoftwarepackage.CurrentlyanumberofleadingESBclassapplicationsavailableon
themarketisfulfillingtherequirementsstatedabove.
Summary
Theprojectresultedintheidentificationofapproximately140businessservicesprovidedbyinternaland
externalserviceproviders.Theseserviceswerefurtherorchestratedinto500highlyspecialized,fine
grainedvirtualservicesinsupportofvariousserviceconsumersthatweremainlyfrontendapplications.

Figure9
Followingthetopdownandnotbottomupapproach,theservicesdeliveredforthefrontendapplications
almostperfectlymatchedrequirementsstatedbythebusinessstakeholders,whileonlyminor
modificationstothebackendsystemswererequired.
Allthedatatransformationsbetweeninternaldatastructuresofthebackendsystemsandunifieddata
modelwereimplementedinthespecificadapters,exposingservicesfromtheparticularsystems.Insome
cases,serviceswereimplementedusingnativecapabilitiesofthebackendapplications(e.g.internal

http://www.servicetechmag.com/I84/0514-2

6/7

11/9/2016 SOA in Banking: A Review of Current Trends and Standards based on an Example of a Real-Life Integration Project Delivered to a Financial Services Cu
scriptinglanguages),whileinothercases,adapterswereplacedontopofthelegacysystemsasa
separate,addonapplications.
Fromatechnicalperspective,serviceorchestrationwasimplementedontheESBclassplatformthatwas
selectedfortheproject.

Figure10
Sincemostoftheonlinecommunications,includingatimeoutsensitiveATMchannel,werebasedonthe
orchestratedservices,detailedperformancetestingwasperformedtomeasuretheactualoverheadofthe
orchestration:
testingwasperformedon2000concurrentusers
systemwasdeployedon8virtualservers
averageWebpageresponsetimewas~2s(65%<1s)
averageorchestratedserviceroundtriptimewas~500ms
overheadoforchestratedserviceprocessingwas~20ms

Figure11
Theseresultsprovedthatproperlydesignedserviceorchestrationthatfocusesonbusinessrequirements
andavoidsextensivedatatransformationsbringsonlyminimalperformanceoverhead.
Lateron,orchestrationcapabilitieswereusedseveraltimestodevelopnewcapabilitiesrequiredbythe
business.Inoneoftheexamples,thecreationofbrandnewlineof"saving"products,combiningterm
depositswithmutualfunds,wascompletedinonlythreeweeks,whileasimilartaskwouldhaverequired
threemonthsfollowingthetraditionalandnotserviceorientedapproach.

The Prentice Hall Service

Technology Series from
Thomas Erl

Home

About

Contributors

Past Issues

How to Contribute

Resources

The Book Series

The Editor

Arcitura Education

Contact Information
info@servicetechmag.com
Tel: 18005796582
Fax: 16049044465

Copyright Arcitura Education Inc. Arcitura is a trademark of Arcitura Education Inc.

http://www.servicetechmag.com/I84/0514-2

7/7