Chapter 2. Case Study Examples
2.1 How Case Study Examples Are Used
2.2 Case Study Background: NovoBank
2.3 Case Study Background: SmartCredit Co.
2.1 How Case Study Examples Are Used
Case study examples effectively provide consistent, real-world context to the abstract concepts discussed. This book incorporates examples related to the background on the two financial institutions established in this chapter. Appendix A concludes this book by ending the storylines of both case study examples and explores the results of the organizations’ respective transitions to SOA.
Style Characteristics
In order to more easily identify these sections, a light gray background has been applied to case study examples subsequent to this chapter.
Relationship to Abstract Content
For those of you not interested in learning with case study examples, consider these parts of the book as voluntary reading. None of the abstract descriptions reference or rely on the examples as they are provided only to further assist in communicating the purpose and meaning behind the concepts, technologies, and processes covered. Feel free to bypass shaded areas or perhaps only reference them when needing further elaboration on a given subject.
Code Samples
Many of the following chapters contain numerous case study examples with Java code. Some of the samples shown are code listings while others have code fragments that illustrate the key concepts covered in previous sections. These code samples are used to demonstrate many of the technologies discussed.
2.2 Case Study Background: NovoBank
NovoBank is a well-known, large-scale retail bank in North America that offers a variety of products, such as deposit accounts, loans, mortgages, and lines of credit. It has a strong presence on the east coast and is now planning to expand aggressively on the west coast, introducing new product lines to attract new customers. As part of the expansion plans, NovoBank management is also considering acquiring local banks or credit institutions with a strong presence in the local market.
NovoBank was established in the early nineties as a retail bank offering deposit account products. It acquired a number of smaller banks over the years and expanded its product offering to include loans, mortgage portfolios, and lines of credit to become one of the top-tier retail banks in North America.
Technical Infrastructure
In the early nineties, the NovoBank IT division started with ten people. Over the last decade, rapid technology changes resulted in the introduction of new delivery channels to serve a growing number of customers of different demographic and financial backgrounds. Different groups of customers preferred different self-serve channels that ranged from Internet banking and interactive phone banking to kiosks. The advent of these new channels led to the creation of different types of user-interface applications intended for different user groups, such as customers and call center employees.
At the same time, acquisition of smaller banks meant a steady increase in the number of systems. The IT environment became more complex and heterogeneous as the number of applications grew, with tens of applications and hundreds of interfaces implemented in a variety of platforms and technologies. As a consequence, the IT division has now evolved to an organization with over a hundred staff members working on different systems across different groups. IT development is outsourced to a large system integration firm, but updates and maintenance releases are handled by the in-house IT staff.
Automation Solutions
The current application landscape at NovoBank is a combination of a variety of in-house and acquired systems that provide deposit account, loans, mortgage, and lines of credit functionality. The back-end applications include the following:
• a Deposit Account application implemented in CICS, COBOL, and DB2 operating on a mainframe system (z/OS)
• a Loans and Mortgage application implemented on an AS/400 system
• a Line of Credit application based on COBOL and VSAM also operating on a mainframe system (z/OS)
In addition, many customer or staff-facing applications, such as channel applications, allow customers to perform self-serve or assisted banking. The channel applications include:
• a Java EE-based Internet banking application using proprietary technology to integrate with the CICS/COBOL-based back-end applications and WebSphere MQ-based messaging to communicate with the AS/400-based back-end system
• an internal branch-based banking system used only by the bank tellers to assist customers with their banking needs made up of a combination of 3270 and 5250 emulator applications that allow access to the mainframe and AS/400 systems
• ATM applications that use proprietary financial messaging standards (ISO-based) over TCP/IP to communicate with the back-end systems
• call center applications that use 3270 and 5250 emulation to access the mainframe and AS/400 systems
Business Obstacles and Goals
The IT budget has dramatically increased over the years with a large portion spent on system integration efforts. Nearly 70% of the overall IT budget is spent on maintenance overheads. Over the years, new product development efforts are hampered by the complexity of legacy system integration and an accidental architecture accumulating a large number of stove-pipe applications. Many of these systems were never meant to operate with each other and have ended up creating their own islands of customer views and data with inevitable duplication and inconsistencies. The main problems can be summarized as follows:
• Each channel application is a silo using complex custom coding to integrate with the back-end systems. Much of the back-end system integration logic is duplicated across the channels in different technologies and platforms.
• Each channel application is tightly coupled with the back-end systems, and the simplest modifications often result in ripple effects that cascade out to the channel applications.
• With no consolidated customer view that offers a summary of the customer’s account holdings, the customer information is fragmented and often duplicated across the channels. The NovoBank IT executives have now been tasked by upper management to reduce on-going maintenance costs by at least 30% and improve time-to-market for new product launches. Faced with such critical challenges, IT management has decided to overhaul the current architecture.
Future IT Roadmap
After a careful assessment of the existing infrastructure and available technologies, NovoBank decides to re-engineer the IT system to a componentized, service-oriented architecture that will preserve legacy assets, simplify integration, facilitate rapid business process changes, and improve channel experience for branch tellers to meet the demands of reduced operational cost as well as rapid business turnaround. The architects at NovoBank have proposed a phased adoption of a service-oriented architecture in the following incremental steps:
1. Build Reusable Business Services
A layer of reusable Web services will be built to encapsulate and hide the implementation details of business logic located in the back-end systems. Services will be described via industry standards-based service interface contracts. The access details of any business logic on a mainframe or midrange system will be completely hidden from the service consumer applications.
There was considerable debate around using SOAP-based Web services or REST Web APIs. After evaluating the capabilities of the legacy systems and packaged integration middleware, it was decided SOAP-based Web services will be leveraged to build the business service layer. The services will be built on the Java EE platform, and service implementations will use appropriate legacy integration technologies, such as Java Connector Architecture (JCA) and Java Messaging Service (JMS), to communicate with the legacy systems.
In the future, when the back-end systems are ready to move on to more modern technologies, the channel applications will not be impacted by these changes because the service interfaces will remain the same. In addition, any channel should be able to consume core business services, such as the Balance Enquiry service or a Balance Transfer service. Such channel-independent business services will enable the delivery of information from the back-end systems in a consistent and technology-neutral way to both current and future channel applications.
2. Consolidate Information
A consolidated customer information system will be built to centralize all customer-related data and maintain the relationships between customers and their accounts. As part of the re-engineering effort, the customer information system will be stored in a relational database, and a set of business services will be built to facilitate access to the customer information from any channel. As an example, a Customer Summary service can be used by any channel to retrieve all the deposit, loan, mortgage, and line of credit information for a customer. The consolidated customer information system will be built from the ground up using Java EE as the implementation platform.
3. Improve Channel Experience
New Java EE-based branch and call center applications will be built to interface with the back-end systems via the business service interfaces. The direct data access on the mainframe and AS/400 systems from the green screen terminals will be eliminated as these Web applications will consume a set of business services without any knowledge of where and how they are implemented. The Balance Enquiry service or Balance Transfer service can be leveraged from the Internet banking application, branch application, ATMs, and call centers.
4. Build Services Infrastructure
SOA infrastructure software, such as an enterprise service bus (ESB), will be introduced to help mediate the interaction between the service providers and service consumers. An ESB will act as a service hosting platform that fulfills the role of an intermediary between the service providers and service consumers to perform message routing, data structure transformation, format translation, and enforcement of policies. In addition, an ESB will also help facilitate monitoring and management of the service-level agreements (SLAs).
2.3 Case Study Background: SmartCredit Co.
SmartCredit was established in the late nineties. Its presence has traditionally been limited to major cities on the west coast, but its low interest rate credit cards have become increasingly very popular among new immigrants and students. The company has gradually grown from a staff of fifteen to thirty-five with on-going steady revenue growth. It is now ready to enter into a new era of expansion.
Technical Infrastructure
The company has a small IT division of ten full time employees and one manager. IT development is managed in-house. The development team follows a process that allows them to quickly build, test, and release new features.
Automation Solutions
The company’s Credit Application Processing System (CAPS) is a typical multi-tier application that consists of the following components:
• Internally, the Web application uses Java APIs (RMI/IIOP) to communicate with the component hosting the business logic.
• An in-house Java EE component accepts customer information and leverages a COTS engine to determine what offers can be made to the customer.
A COTS credit and risk engine carries out the following steps:
1. Accept a credit application.
2. Create an applicant profile.
3. Interface with one or more credit bureaus to retrieve credit reports.
4. Assign a score to the applicant by evaluating a set of rules.
5. Perform risk assessment.
6. Determine credit-worthiness of an applicant.
7. Reject or approve application and assign credit limit based on score.
8. Generate reports.
9. Create a database tier to store persistent customer and product data.
Business Goals
As part of its expansion plans, SmartCredit is entering into a reseller business arrangement with a large local retail store that will offer re-branded credit cards to customers. The retail store offers different levels of membership programs for its customers to enjoy bonuses like special discounts and cash-back programs. With the new business partnership in place, the retail store customers who sign up for the premium membership will be offered an opportunity to apply for a credit card.
Retail store clerks signing up premium members will use iOS or Android mobile applications on tablets or mobile phones to submit credit card applications to the SmartCredit CAPS. The majority of applications will be adjudicated at point of sale within minutes. A small number of applications may require evaluation by credit and loan department staff at SmartCredit. Once a decision is made, the results will be communicated to the customer by mail. The retail store would also like the ability to check the status of pending credit applications using the SmartCredit CAPS.
Future IT Roadmap
The new partnership poses a challenge for the SmartCredit IT department, as the current Web-based user-interface is a staff-only application inaccessible outside the SmartCredit network. Credit application business services must be exposed to external applications, such as the retail store mobile applications as well as other internal applications. Given the diverse and rapidly changing nature of the mobile applications, selecting a universally accessible and efficient integration mechanism is important.
REST APIs offer the functionality SmartCredit requires. A quick evaluation of the CAPS application identifies that, with some effort, services with REST-based uniform interfaces can be leveraged to offer core credit application functionality to both internal and external applications. The team also determines it would be simpler for onboard partners to use and scale out future operations with a REST-based CAPS architecture.