Technology for Finance
Summary : The ability of financial institutions to manage change can be hampered by their huge, yet disconnected, IT application landscape. Nilesh Bakhle and Shyam Sunder look at the factors accelerating enterprise application integration and how integration can be achieved.
Full Text
It is the stuff that CIOs dream of. Wipe the slate clean, build from scratch, and build it right. A clean sheet of paper, for the perfect technology architecture. Everything talks to everything else, uses a single source of information, and presents a seamless user experience across all channels. Change is easy to handle, just plug and play. A perfect world.
Yet this is destined to be just a dream. For large financial institutions have made, and will continue to make, substantial investments in technology. This means expensive legacy systems, which - for all their problems - work, and the next day�s business can be processed. Hence a business case for re-engineering or re-architecting these systems is hard to demonstrate. Business will give you no respite to stop, take stock, and rebuild.
Unless your business is new too. The e-commerce bubble of 2001 created a flurry of activity in large firms. There was a real or perceived threat from new, nimble and cost-efficient Web-based banks, projected to take away a large market share as customers moved in droves to use e-channels instead of physical channels such as tellers and ATMs. The response from large financial institutions was typical of their size - slow and shallow. Their pace was hampered by their huge, yet disconnected, IT application landscape. Large financial institutions were being outpaced by their smaller competition, whose new, homogenous IT landscape had the benefit of a clean start. Although most of the virtual banks either went bust or were bought by larger institutions, this was more a factor of flawed business models and less of inferior infrastructure.
The Challenge
Large financial institutions face greater challenges as they process a level of magnitude more data compared to organizations of a similar size in most other industries. Yes, there are still some pieces of paper floating around but, by and large, the financial product is a virtual product. Dematerialization of stock certificates, electronic payments and online banking are all indicators of how money will move from a commodity to a concept in the future, rather like electricity - you know it is there, you know it works, but you never see it.
Keeping track of money, and its equivalents, has therefore meant heavy investments in technology. Yet technology has been both the solution and the problem. For instance, the whole phenomenon of e-business is a technology driven shift. Yet, the rest of a large financial institution�s technology hasn�t kept pace with the online channels.
The e-business experience highlights the core problem that integration attempts to solve. How do companies, with a rich diversity of applications in age, efficiency and scalability, manage change? Business drivers, such as M&A activity, regulatory change or shifts in competitive intensity, could drive change. Change could equally be driven by technology, such as emergence of new protocols, new customer interaction channels or revolutionary killer apps. Firms need a superior level of nimbleness and flexibility in their technology environment if they are to rapidly respond to change and capture competitive advantage. Integration helps institutions to accommodate these waves of change and digest them in as painless a process as possible.
The Evolution of EAI
The push towards enterprise application integration (EAI) has been accelerated due to two developments. First, there is a strong and growing business need for combining various offerings in a seamless product or service. Second, from a technology perspective, standardization has meant faster deployment of services. Let us examine each of these dimensions in detail.
Enabling Seamless Business Services
Messaging: Initially, EAI products such as MQ Messaging and TIBCO offered a messaging backbone using a hub-and-spoke architecture, thus eliminating system silos. Implicit in this architecture was that applications would be integrated using a message interaction (request-response) mechanism. Thus application A connecting to application B did not call the APIs exposed by the latter, but sent it a message from among the set of request message formats that the latter supports. Application B on receiving the request message replied with a message using a predefined and documented response message format to the original application. An application that connected to the EAI's hub (as a spoke) using adapters, in effect connected to all other applications that were connected to the hub. The hub served as a heart in the new centralized but well-connected arterial system for the enterprise. The EAI products met other basic requirements for application integration such as message transformation, message workflow, guaranteed delivery and message routing. However, at this level there was no understanding of the business context, or semantics, of the message by the middleware.
Transactions: The next level in the evolution was the creation of a transaction integration layer that resided on top of the messaging layer. Products, such as MQSI, webMethods, BizTalk, SeeBeyond and WebLogic delivered the ability to define compound, multi-step transactions, thus enabling business functionality to be developed. Such products enabled the creation of business rules that govern transactions, incorporating logic to handle compound level functionality. For instance, the functionality might enable the payment of credit card dues from a checking account held at the same institution. For this, the middleware would access the credit card system and the checking account system, using messaging and business logic to debit the checking account and credit the credit card account. However, the process could fail if the entire transaction failed to go through. This could lead to the checking account being debited, without the corresponding credit to the card account.
Business Services: The next level of evolution incorporated higher levels of business functionality to form business services. The ability to deliver business services truly creates middle-tier value addition, thus overcoming the potential failings of the previous levels. Higher levels of business services often require complex business process flows within the enterprise, which touch different parts of the organization. Traditionally these were built as custom end-to-end applications. The trend today is to build them on the top of enterprise workflow products, which act as platforms or backbones. This is achieved by incorporating a workflow tool into the middleware, so that a complicated multi-step action, even including multiple sessions, can be managed as a comprehensive business service. The business services that are possible could include new account opening, where the service would interact with several internal systems as well as the systems of external partners such as credit rating agencies. The institution, its partner or a third-party could own these services. The new interest in business process modeling (BPM) and business activity monitoring (BAM) reside at this level. The products in the category include Tibcoworks, BEA WebLogic Integrator and MQSI.
Increase in Standardization
Increased standardization has played an equally important role in the evolution of EAI. This has been primarily in the area of reliable message delivery and formatting of messages. In message-oriented middleware, standardization has been achieved using products such as TIB/Rendezvous and MQSeries as reliable message delivery platforms. This is the �plumbing� that allows messages to flow in a uniform manner across an enterprise.
Banks have been using universal formats such as ISO 8583 (for ATM transactions) and SWIFT for many years. SWIFT, though primarily intended for inter-bank messages, is being used as a standard for internal messaging in almost every global bank. XML is the format of choice for e-business transactions and channels such as the Internet. This has led to the formation of FIX, a consortium that promotes the use of XML through a message framework that has been customized for financial institutions.
A new and exciting phase is being ushered in through the introduction of Web services-enabled technologies such as SOAP, WSDL and UDDI. Web services are currently being piloted in many large institutions as an internal integration standard before being rolled out as a mechanism of exposing services on the Internet to partners and customers.
How Integration is achieved
Implementation of an enterprise-wide application integration framework requires participation from all channels and product processors. This task usually takes a significant amount of elapsed time and resources, yet is balanced by the need to show results in terms of improved servicing capability and robustness of the implemented infrastructure.
Application integration is typically a federated issue. Some platforms, such as messaging backbones, get implemented at enterprise level, but most integration is achieved project by project. It is therefore prudent to approach the task in a phased manner, with measurable success criteria at defined intervals. The first phase is an infrastructure phase in which the messaging and transaction services are implemented. In the next phase, a unified customer view is provided across touch points. The final phase involves enabling all transaction flows through the transaction hub. We discuss specific aspects of EAI implementation below.
Infrastructure is formed by the base physical/network/transport layer on top of which application services can be layered. This is achieved by a 100 Mbps (or higher) TCP/IP network.
Message Oriented Middleware (MOM) ensures guaranteed message delivery between the sender and receiver. MOM can recover from connection failures as well as application crashes. MOM has evolved from OLTP monitors such as Tuxedo to TIBCO Rendezvous and IBM MQSeries.
Business Process Modeling and Workflow allows a process to be modeled using a graphical tool with defined integration points to channels and product processors. These may be purely �systemic� processes, which do not need manual intervention, or may model actual workflow, which will allow the process to transition between various states. An example of a systemic process could be the breaking up of a �Pay my Credit Card balance from my Savings Account� into a message to the Savings Account processor and a second message to the Credit Card processor, whereas a workflow would be needed to model a Loan Origination process that would have a step of Application Entry and Approval.
These were earlier handled by point-to-point integrations between participating systems with the workflow being hard-coded into the product processor. However, emergence of tools such as MQSI, TIBCO InConcert and more recently WebLogic Integrator enable these capabilities at a platform level, which can be leveraged by applications
Transaction Integrity means ensuring the correct result is achieved even when one or more transactions resulting out of a request fail. This is required when a request spans across multiple product processors. In the absence of XA compliant product processors, ensuring transaction integrity requires custom coding on top of the messaging platform.
Security means that all transactions are performed by systems and users who are authenticated and authorized. Most enterprises are very diligent in ensuring that user access is secured but take the approach that implemented systems are trusted and hence are subject to only basic authentication. As more aspects of the enterprise are opened up to integration, this simplistic model will need to be replaced with more sophisticated access control, ultimately leading to the same standard being applied to both users and systems. LDAP based authentication and authorization is increasingly gaining ground as the access control mechanism of choice. However system integration security is still to catch up within most large institutions.
What the future holds
Service oriented approaches for integration and service oriented architectures (SOA) are gaining popularity in enterprises that are driving build and reuse as well as consolidation of platforms, systems and services. Organizations are concerned with deploying, administering, managing and securing Web services and other services; products are now emerging to address this concern. XML is becoming the de-facto standard for data exchange between systems and services. Coexistence of Web services and custom service message formats (for high performance systems), business processes systems using workflow platforms, and BPM/BAM products are directions in which EAI will evolve.