SOA – The Future of Banking Technology
The reported increased profitability in the US and Europe suggests that banks are meeting the challenges of recent years. They appear to have avoided the worst effects of major corporate collapses and increased regulatory demands, as well as the challenges posed by a more demanding and cost aware consumer. Yet the on-going and repercussive effect of these and other issues is changing the nature of the competitive landscape for good. The result will be a banking industry that has to be quicker, smarter and far more cost efficient in order to survive.
Paper transactions are being replaced by low margin electronic traffic. Key initiatives favour real time or T+1 transfer and settlement, necessary to aid liquidity and meet consumer demand. Those who can afford the investment have become revenue-generating hubs for second and third tier banks. By achieving technological supremacy in transaction processing they have leveraged their financial strength and considerable scale to enhance their competitive standing.
Sarbanes-Oxley insists that all US organisations have visibility and control of key functions. To enable this, a major operator must maintain fast and efficient global connectivity, and re-align business reporting and approval processes to successfully monitor enterprise risk, ideally from a centralised point.
The challenge for all banks, large and small, is not only to create a centre of excellence with established international standards of communication, but also to reconstruct and automate their business processes to maximise efficiency. Monolithic business processes, each tied to a product line or particular service, require identification, dissemination and re-assembly.
The IT systems that currently support each service require review and extension. The technology used must be future-proofed to suit integration of existing and future development platforms. This doesn’t have to mean core system replacement. Within a bank’s legacy systems reside vital components of the organisation’s competitive edge, the mission-critical processes and systems that form the heart of the enterprise. They may require rationalisation, documentation and better understanding, for the benefit of extracting more value – but nevertheless they exist, and have been bought and paid for, and have proven reliability processing billions of transactions per day across the globe. Core services should be individually identifiable and re-usable, such that systems development is far easier and quicker. In this way construction and maintenance costs are significantly reduced. SOA (Service Oriented Architecture) is a key technology concept to achieve this level of re-use and avoids the extreme cost and risk of complete systems replacement.
Sceptics claim that SOA is just another acronym for the same old promises of more flexibility and greater agility through re-use of technology components. Object Oriented (OO) architectures and then Component Based Development (CBD) promised levels of re-use but neither were applicable to legacy applications because of assumptions about technology and interface paradigms that did not fit. In addition, competing standards reduced the opportunity for reuse between diverse organisations, teams and packages. SOA does not presuppose an OO or CBD model, and applies equally to procedural programming and other paradigms for application construction. SOA offers technology-agnostic re-use.
The appeal of SOA is that it embodies good practice, but it does not set out to standardise to a level sufficient for implementation. SOA is a concept not a technology, and allows the concept to be applied regardless of middleware. SOA is useful to formalise the conceptual bridge between legacy and contemporary technologies like J2EE and .NET. There is almost universal agreement that SOA is a good model for application composition and re-use and this is leading to adoption in many financial organisations.
SOA underpins one of the fastest growing technologies from the last couple of years: Web services. Web services provide a platform and vendor-neutral set of standards and implementations suitable to execute composite applications based on the SOA model of construction. Web services are standards for implementing both ‘service’ invocations across technology boundaries, and for transmitting documents regardless of end-point formats. Adoption continues to be slow in most organisations. This is largely due to slow standardisation and delivery of the necessary infrastructure to provide the quality of service required for business-critical applications.
This is essentially a two-stage process. First, the legacy applications must be converted into re-usable core business services. This means peeling away the original operator interface from the underlying ‘services’ in the applications that perform useful business functions. These core services are redeployed to their host platform in such a way that they can be invoked though some well chosen SOA-based middleware (for example Web services). SOA does not presuppose any processing paradigm or data formats. Legacy applications use a wide variety of both, and connections may be made through customised ‘adapters’ or third party tools. Also, SOA allows the construction of business-level entities, and is not constrained by existing technology boundaries – such as Online Transaction Processing (OLTP) units of work, job steps etc. These are physical boundaries that often bear no relationship to anything reusable in a business context.
Second, these services are ‘published’ to the development teams building new client offerings, real time or T+1 transfer and settlement systems, business reporting and approval processes, all using established international standards of communication. Published services appear as lists of fully production-hardened entities such as Web services, Enterprise Java Beans or similar within the new development platform.
Smart IT organisations are achieving the transition in several evolutionary steps, selecting the most suitable candidate legacy applications first for conversion into core services to enable key development initiatives.
An SOA must respect the ‘statefulness’ of the services that are invoked. Legacy applications are constructed with assumptions about how long transient data storage survives and how different ‘instances’ are identified. The simplest and most effective model is one where each interaction is indivisible and independent of any other. This is the model adopted by many OLTP systems on legacy platforms and thus supports straightforward conversion.
In general, core services should encapsulate single query or update transactions (indivisible units of work) to provide a sound basis for recovery in the event of service failures. Where a service is composed of several transactions, care is required to select sequences that cannot leave the underlying data in an inconsistent state.
It is sometimes thought necessary to extend transactions across the SOA-legacy divide. There are dangers and difficulties with this approach ensuring that the different platforms can guarantee safety and performance. Until Web services matures to the point where these provide a full service capability including infrastructure and management, many tasks (like service journaling and recovery) must be handled through complex system programming techniques which require deep platform-specific understanding.
The SOA model has not defined if transactions should flow across service boundaries. There are good arguments to suggest that they should, (to provide integrity) and arguments to suggest they should not (to provide isolation). The whole industry needs guidance and standards on this issue. Application designers must know when they are constructing tightly coupled or loosely coupled services, since the design constraints are quite different. The decision should take account of the organisational (physical as well as commercial) boundaries between interacting parties, since internal integration projects may allow different principles to be employed from true B2B interactions.
In summary, the financial sector competes and maintains profitability by consistently streamlining to reduce costs, modernising with agility, while preserving industry expertise and the need to avoid unnecessary risks. It makes business sense for an industry that recognizes the importance of exploiting competitive advantage through technology to consider an approach that allows them to identify, upgrade and re-use existing legacy assets, while also taking advantage of new technologies. A move to Service Oriented Architecture and Web services offers banks the option to do this.