Emerging Technology Architecture with System Integration

A financial institute with over 600 employees and has been operating in the consumer banking market in US for over 80 years. The client has been able to retain customers by building strong customer relationships and providing a high level of customer service.

PFITECH came into the bank and recognized that the existing technology architecture used at the bank was insufficient to meet the demands of e-Business. The major problem was the lack of integration between its core home loans IS applications:

1. A web portal with online forms for making mortgage applications developed using HTML and Java Server Pages running on UNIX-based Apache web-servers
2. A back-end mortgage application package (MAP) running on Windows NT provided by a specialist financial services technology solutions provider
3. An account management system based on a legacy ICL mainframe running the VME operating system
4. A customer relationship management (CRM) suite based on a packaged application running on Windows NT
5. A call-center application based around the Siebel package running on Windows NT

PFITECH formed a team of 12 business and IT professionals at the client’s site for a 24-month initiative to integrate all of the bank’s IS applications. The main focus for the first 12 months was the integration of the core IS applications in the home loans division. Eight members of the team worked on this project under a senior project manager, while the other team members began working with the other divisions.

A schedule was put forward by the PFITECH team and agreed by the bank’s senior management:

1. Months 1-2: Integration requirements gathering with stakeholders
2. Months 3-4: Solution architecture
3. Months 5-7: Design and implementation
4. Months 8-10: Testing
5. Months 11-12: Rollout and transition

The team spent over three months understanding and capturing business integration requirements in greater detail. As an integral part of this activity, the team mapped out the existing mortgage processing process and pinpoint weaknesses in the process. The team also had to be thorough in their investigation of where problems actually occurred.

Because different aspects of the mortgage processing process were captured in a variety of different documents, the team had to spend considerable effect piecing together a comprehensive end-to-end picture of the process. Some of the major integration undertakings are summarized as follows:

• A 50% reduction in the turnaround time to process a mortgage application and return a decision to the applicant
• Seamless integration and transfer of information between all core and the majority of non-core home loan applications
• Minimal disruption to the business and existing IS applications. There would be no significant period of time when customers would be unable to submit mortgage applications
• A reliable and robust solution that would scale up from the current 120 mortgage applications a week to over 300
• An acceptable level of security. The integration of IS applications should not weaken or compromise the existing level of security already in place

In parallel with the requirements activity, the team evaluated and developed other alternative approaches to integration. A traditional point-to-point architecture was quickly rejected for the following reasons:

1. A high level of custom development would be involved. A minimum of eight separate point-to-point interfaces would need to be written from scratch. For example, developers would need to write an interface between the MAP and the account management system
2. There was a high level of development risk. The account management system was based on old mainframe technology, and it was not certain that a robust integration interface could be built from scratch
3. There was a high level of business risk. It was envisioned that the existing applications would need to be taken offline for a significant period of time, and the significant outage period would affect the existing business beyond what was deemed acceptable
4. It would take too long to develop all the interfaces, exceeding the 12 month timeline given to the project

The team understood that a point-to-point integration approach had too many high-risk elements. Also, they recognized that the bank’s IT architecture was constantly in a state of evolution. While individual IS applications would be retired and replaced by better ones, they envisioned an integration “backbone” that was largely static where IS applications can be “plugged in and out.” An Enterprise Application Integration approach seemed well-aligned to the concept of an integration backbone.

The team also recommended replacing the existing CRM suite with a Siebel-based CRM solution which would work seamlessly with the existing Siebel call-center application. This was because a close degree of coupling was required between the CRM suite and call-center application, and the level of integration needed between the existing CRM suite and the call-center application was considered too complex. The proposed Siebel-based CRM system, however, was known to be tightly integrated with the Siebel-based call-center application so that cross-selling opportunities could be easily identified by the call-center operator.

A project schedule was put forward:

1. Months 6-7: Test environment preparation and readiness
2. Months 8-9: EAI installation and application connection in the test environment for the core applications
3. Months 10-11: Integration testing (core applications) in the test environment
4. Months 12-13: Phase 1 rollout (2 applications maximum) in the live environment; application connection for non-core applications in the test environment
5. Months 14-15: Phase 2 rollout (2 applications maximum) in the live environment; integration testing (core and non-core applications) in the test environment
6. Months 16-17: Phase 3 rollout (2 applications maximum) in the live environment

Although installation of the packaged Enterprise Application Integration tool in the test environment was relatively problem-free, the team spent considerable effort configuring the adapters that connected each IS application to the messaging middleware. Configuring the adapters properly required an intimate understanding of the enterprise data model of the bank in a number of areas:

1. The team had to understand the data model used in each IS application. For example, the data structure of the database in the account management system was visible from within the adapter, and the events or triggers that caused data to be updated in the database had to be configured within the adapter. However, no single individual had such an intimate knowledge of the data model in each application, so the team had to piece together the relevant information from a variety of individuals.
2. The team needed to know where data was duplicated across different applications. For example, if a customer changed their contact details, this would need to be reflected in several different applications. Hence, data-fields in each application needed to be cross-mapped
3. The business rules that governed the mortgage application process needed to be modeled into the Enterprise Application Integration tool so that relevant business events would trigger the appropriate messages to be sent to different applications.

Several forms of integration were conducted in order to ensure that different elements of the Enterprise Application Integration solution work correctly:

1. Event message production
   This ensured that business events triggered the right messages to be sent by the appropriate application
2. Message consumption
   This ensured that individual applications connected to the messaging infrastructure consumed the messages properly, i.e. performed the correct behavior and database update functions after receiving a message
3. End-to-end testing
   This simulated the end-to-end cycle of mortgage application processing from the point at which mortgage applications were made, ensuring that the relevant business events generated the right messages and that a mortgage application moved through the business process as intended
4. Performance and loading
   This loads 100, 200, 300, and 500 current mortgage applications within the system

As more and more organizations embark on major enterprise-wide business initiatives such as e-business, automated supply chain management (SCM), CRM, and ERP, they will need to think more strategically about how to integrate their diverse portfolio of IS applications. Enterprise Application Integration is one strategy to IS application integration. However, as the case shows, Enterprise Application Integration projects are non-trivial and differ considerably from typical IS development projects. Even when a packaged EAI tool is used, there are considerable architectural and management decisions still to be made.