The future of banking technology?

Service oriented architectures and web services can provide real benefits to the finance industry says Julian Dobbins, senior marketing development manager at Micro Focus.

The reported increased profitability in the US and Europe suggests that retail 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 ongoing 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 organizations 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 centralized 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 maximize 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 organization's competitive edge, the mission-critical processes and systems that form the heart of the enterprise.

They may require rationalization, 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 organizations, 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 standardize 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 formalize 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 organizations.
 
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 organizations, largely due to slow standardization and delivery of the necessary infrastructure to provide the quality of service required for business-critical applications.
 
So how can SOA enable integration of core legacy services with future development platforms?

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 customized 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 and so on. 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 organizations 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.
 
There are some important technology considerations to bear in mind.
 
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 mature 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 organizational (physical as well as commercial) boundaries between interacting parties, since internal integration projects may allow different principles to be employed from true business to business interactions.
 
In summary, the financial sector competes and maintains profitability by consistently streamlining to reduce costs, modernizing 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.

www.microfocus.com

This article first appeared in July 2006 ITNOWextra.