(新)APPARC韩国银行咨询报告_

Application Architecture
December 7, 1995
5.3A PPLICATION A RCHITECTURE (3)
5.3.1 Section Overview (5)
5.3.2 Application Architecture Model (5)
5.3.3 Current Application Architecture (8)
5.3.4 Application Architecture Guidelines (10)
5.3.5 Proposed Application Architecture Strategy (11)
5.3 Application Architecture
This section describes Bank X‟s current and future application archi tectures--the systems and applications used by customers, branch personnel, business users, executives, and external agency to support Bank X‟s business environment. The application architecture is built based on use r requirements, new technical solutions, and banking best practices. Where possible, we have identified potential technical and business supported changes that could help Bank X‟s systems. The Application and Data plan describes the actual planned improvements or new applications to be built over the next five years.
Key features
The focus of the new application architecture is to enhance market-driven processes--processes that improve Bank X‟s position in the Korean banking environment by providing better customer service, products, increased market coverage, and competitive prices. Many of the new applications focus on improving management information to help Bank X manage a larger bank and to more precisely evaluate customer needs. Highlights of the new application architecture include: ∙New sales and marketing systems
⇒Needs analysis (customer, product, and market)
⇒Campaign planning (new channels, sales, promotion activities)
⇒Branch opening support (global information system)
⇒Sales support (sales schedule, customer consulting activities)
∙Enhanced customer management systems
⇒Corporate data information management (financial, personnel, news)
⇒Retail customer information management (name, address, family relationships)
∙Advanced credit systems
⇒Corporate credit analysis
⇒Customer credit scoring
∙New management information systems
⇒Business unit profitability (customer, product, branch)
⇒Regulatory and Compliance
⇒Treasury management
⇒Market risk
⇒Product management
Potential risks
To achieve the application architecture, Bank X will need to carefully coordinate technical infrastructure improvement, database development, and EDP resources. This requires managing the following risks:
∙Customer applications (e.g., ATM, credit card, phone banking, electronic banking) are not competitive with other Korean banks or non-Korean banks (e.g., Citibank)
∙Changing customer preferences may require changed application focus, new products, or new services
∙Bank X EDP department lack the resources to both support existing applications and build new technical infrastructure
∙Bank X tries to build to many new applications
∙Existing applications are do not meet future needs or can not integrate well with new applications
∙Technical infrastructure and databases can not support new applications
Benefits of Application Architecture
As application architecture is a high level model shared by both business and EDP personnel to identify the types of systems Bank X requires. It is a tool similar to a building architecture that provides a model to be used to plan projects, design new systems and databases, and prioritize EDP activities.
∙Business and Technology department cooperation The application architecture should be shared document between business units and technology areas.
Business units, operations personnel, branch personnel, and executives should be able to identify the applications that support their areas. Changes to those applications should be clearly distinguished as should new applications
∙Increased Usability The architecture should provide users with the applications they need to support their tasks and to meet their type of work.
∙Flexibility and Isolation By separating applications based on business functions, the application should be allowed to grow in sophistication with the business. Secondly a change to one business areas applications should not impact other business areas.
∙Identification of Packaged Solutions The application architecture and the application plans should describe applications to a detailed enough to identify whether packaged solutions can meet business requirements.
∙Standardization The architecture should identify opportunities to share program components and data across applications. It should also help indicate the proper platforms for applications.
5.3.1 Section Overview
The application architecture section is comprised of the following sections:
5.3.2 Application Architecture Model - presents a conceptual model used to categorize and visualize the architecture components.
5.3.3 Architectural Transformation - Describes the process of building Bank X‟s new application architecture
5.3.4 Application Architecture Guidelines - presents guidelines that should be followed in order to implement a successful architecture.
5.3.5 Proposed Technical Architecture Strategy - this section illustrates the likely features of the new architecture. It contains the following sub-sections:
- 5.3.5.1 Service Delivery
- 5.3.5.2 Central Processing
- 5.3.5.3 Relationship Management
- 5.3.5.4 Management and Control
- 5.3.5.5 Information Delivery
5.3.2 Application Architecture Model
The goal of the architecture strategy is to define an application architecture that will support Bank X's future business requirements. To assist in the development process, Andersen Consulting's Vision Application Architecture Model was chosen as a design tool. This section shows how the proposed application architecture was designed using the Vision Application Architecture Model as a starting point. The components of the Vision Application architecture are:
1.Service Delivery
2.Central Processing
3.Relationship Management
4.Management and Control
rmation Delivery
6.Gateways.
Figure 5.3.1 - Components of the Vision Architecture
1. Service Delivery
Service Delivery supports all banking functions provided to benefit Bank X‟s customers. These include the branch network, internal department s, customers, correspondent banks and clearing and funds transfer service providers. They may use a variety of techniques to access the organization's information, such as terminals in branches, executive workstations, telemarketing workstations, ATMs, home and telephone banking and corporate workstations.
The objective for Service Delivery is to provide an integrated and seamless interface to all users. Traditionally, screens and menus were developed as part of a specific system such as branch sales, credit scoring or account processing. However, to reduce costs and improve customer service organizations are trying to streamline their business processes. For instance, they might want not only to sell a loan to a customer, but also get credit authorization and set up an account on the spot.
The range of functions provided by the system must match the range of activities the user performs. If front office staff in a branch are supposed to provide customer service and to sell, then they need a platform which will allow them to do both, irrespective of whether they are accessing a product processing system or a sales support system.
2. Central Processing
Central processing includes the transaction processing traditionally supported by central systems. This processing ensures that the bank‟s transactions are properly executed and that the bank‟s various accounts are properly managed. Central processing consists of four components:
Operations Processing
In order to process transactions a number of common functions need to be performed before they are applied to a particular system. The user's authority to carry out the transaction needs to be authenticated - for instance, ATM PIN validation. The source and nature of the transaction need to be recorded for use in activity measurement and for productivity monitoring. Security requires that transactions are properly audited and in some instances business rules dictate that a second person must authorize the transaction. Journal entries must be generated. If transactions are not applied to the underlying product processing system, these exceptions must be captured and reprocessed efficiently.
Closing and Settlement
Closing and settlement functions ensure that all accounts are properly updated, reconciled, and accurate. It requires transferring information between various entities including other banks, clearing agencies, and across branches. The system should process business transactions rather than a series of more
physical transactions dictated by the limitations of product administration systems. For instance, transferring money from one account to another is a single business transaction. This remains true even when the accounts are in different currencies, processed on different systems, and require several journal entries.
Product Administration
Product administration functions perform all product specific processing for deposits, loans, foreign exchange, credit cards, bill payment, trade finance, and other types of products.
Product Factory
A product factory is a system that supports common product functions such as interest calculation and payment, pricing, product reporting, product
accounting, and other product calculations. Many banking institutions are using object-oriented techniques to manage their many product types.
3. Relationship Management
Relationship Management supports sales and marketing, customer management and credit control. These are business functions which relate principally to customers and households as opposed to individual accounts. Marketing campaigns are managed across the various distribution channels available. Then, by drawing on information about individual customers, other members of their households, their products, product usage patterns, demographics and behavioral psychographics, needs are identified. Campaign execution can be in the form of direct mail, telemarketing or the passing of leads to branches. Sales support provides facilities for demonstrating product benefits to customers, managing leads in progress and closing the sale.
Customer service histories are maintained recording the quality of the individual relationship. For business customers and high net worth individuals, information on customer profitability and the relationship as a whole may be used to determine how to structure and price product offerings. Institutions also need to report on the individual customer relationship for regulatory purposes such as to the Bank of Korea.
Credit management includes not only the initial scoring of applications but the subsequent monitoring and resetting of limits. By understanding a customer's complete relationship different decisions can be made. For instance, a customer with an unauthorized overdraft on a checking account but a large balance on deposit should be treated differently from a customer with a similar unauthorized overdraft who has also exceeded the limit on his credit card. Part of the process is likely to involve credit scoring and using third party information for credit decisions.
4. Management and Control
The Management and Control component of our architecture is divided between management information functions and administrative functions. Administrative functions, which are generally not specific to the financial services industry, form the basis of effective organization and office management.
The Management Information component supports the activities of planning, analysis, monitoring and reporting. It is divided into three broad categories: ∙Financial: Information on costs, profits and positions for use in producing financial position and regulatory reports (including BIS reports), budgeting and forecasting, and assessing risk.
∙Operations: Information on productivity and service quality.
∙Sales: Information on current sales performance and that required to assess the actual profit and potential for profit from different products and sectors of the market.
Executive information is provided from all three categories in a more summarized form.
5. Information Delivery
Information Delivery manages the external delivery of information whether on paper or by electronic means. Information Delivery may involve additional processing such as that required for Electronic Data Interchange (EDI). It allows financial institutions to be a service provider for information exchange between clients and third parties. Indeed the financial institution may choose to position itself as the provider of the value-added EDI network itself.
The physical printing of reports, statements and mailings are also Information Delivery activities. It can often be more cost effective to subcontract some of these activities to third parties. Through Information Delivery it is also possible to consolidate orders for physical media such as checkbooks and plastic cards, realizing greater bulk discounts.
6. Gateways
The gateways are the components generally systems software or middleware that enable information to be distributed between applications as well as shield the applications from changes in the underlying technical or data architectures. The four main gateways are:
∙Driver: Manages the process of getting valid business transactions to the appropriate application, including translating single business transactions into one or many systems transactions. For example, when a central customer master file is updated, the driver process will ensure that this transaction is passed to the relevant applications.∙
∙Integrator: These processes will be responsible for integrating information from the various applications. An example would be the summarization of data from the customer or product information to evaluate branch profitability.
∙Navigator: Establishes and maintains the bank‟s view of its relationships and systems. It maintains information about clients, intermediaries, other third parties and their interrelationships.
∙Distributor: These processes consolidate information for use both within Bank X and also for external organizations such as clearing and settlement organizations or for SWIFT.
Gateway functionality is further discussed in the technology plan.
5.3.3 Architectural Transformation
Transforming from a centralized mainframe architecture to a new distributed architecture is a difficult task, and one that many organizations have failed in. Nevertheless the realities of today‟s banking and technology environments have made architectural transformation a necessity.More and more the banks with best technologies and information systems have a competitive edge. Banks with advanced technology can:
∙Deliver advanced services to customers
∙Spot market trends quicker
∙Bring products quickly to market that truly meet customer needs
∙Capture new market segments
∙Discriminate between profitable and unprofitable customers
∙Discriminate between high risk and low risk products and customers
∙Mitigate their risks through diversification or hedging
To develop Bank X‟s new application architecture we have taken the following steps which we hope will lead to successful arch itectural transformation.
Step 1 - Recognize the changing environment
Before the project started Bank X had recognized that both technology and Korean banking were evolving at increasingly rapid rates. It is no longer possible to plan technology on a one year basis, nor can one use the technology developed for banks 10 years ago. In the first step, we reviewed the current Transaction System - Reporting system architecture which is based on IBM Japan‟s model for banks 10-15 years ago.
With the changing technology, this model has become outdated and for the most part, Japanese banks are searching for new methods. Unfortunately for the larger banks, changing is difficult after 15 years of investment in mainframe systems. Sometimes being the largest bank in the world can be a liability.
Step 2 - Identify new methods for grouping applications
The second step was to find new methods of grouping Bank X‟s applications (rather than simply grouping by on-line or reporting). Our method was to choose six data and processing characteristics (see section 5.1) and classify the applications by these characteristics.
Step 3 - Regroup system supported functions into new applications
In step 3, we regrouped the business functions based primarily on the user type, processing type, and data summarization level. This lead to a preliminary application architecture
Step 4 - Validate against other application architectures
Step 4 was the process of validating Bank X‟s architecture against Andersen Consulting Vision architecture (described in Sect ion 5.3.2) as well as against other bank‟s architectures. This validation lead to a few adjustments. This architecture is shown in figure 5.4.
Figure 5.3.3.2 - Current Applications
Step 5 - Map in new business requirements
The fifth step was to map in new business requirements by identify potential applications based on the user requirements developed by the management assessment team.
Step 6- Revalidate against the vision architecture
The final step was to revalidate the future architecture against the Vision application architecture. This lead to the final architecture picture.
It should be noted that the final architecture should represent Bank X‟s requirements. A simple implementation of the Vision architecture, IBM‟s architecture, or any other architecture would in the end fail as these architecture are generic based on many banks.
5.3.4 Application Architecture Guidelines
This section presents guidelines that will be followed throughout the implementation of the application architecture. These guidelines will be used as a starting point for Bank X in their decision making process. Each guideline will be assigned a relative importance which will be used in the selection of architecture components. They are based on Andersen Consulting's experience in implementing similar architectures in the retail financial services industries.
The guidelines are as follows:
Architecture driven by the business The selecting and building of architectural components should be driven by the needs of the business and not by technology. Bank X‟s EDP department must understand the business requirements and the business lines must understand new applications such as risk management, smart cards, and virtual banking.
Unify Applications Users should be supported by a small number of applications in such a way that each business functions require only a single application to operate.
User Driven The user interface, application logic, information availability should be based on the users requirements. Knowledge workers (product specialists, business managers, loan officers) require advanced functions and reporting. Executives require summarized
information from the entire bank. Tellers and operations clerks require easy to operate systems that allow them to process
transactions quickly. Customer systems should have quick response times and attractive user interfaces.
Consistent, Easy to Use In all cases, the user interface should be intuitive . Application screens and windows should follow interface standards so that different applications have the same “look and feel”. On-line help screens should be available for all functions.
Flexible The architecture should be able to support the introduction of new products and changes in functionality that are inherent in Bank X's business. The architecture should also be able to utilize the latest developments from third party vendors to support new products and
allow productive custom development and enhancements.
Well documented All applications should be clearly documented so that application developers, maintainers, and users can clearly understand the relevant functional and technical components.
Package Driven Where practical, the application architecture should use commercial software packages rather than be custom developed. Packages are less expensive than building software at Bank X and can provide full functionality quickly
Integrated Information should be shared across applications. Where possible the same databases should be used across applications. Applications should share software components where possible including validation routines, product calculations, data access routines, logging,
and other common functions.
Phased Approach for Software Roll out A phased approach should be used for the software roll out. Implementing all applications at one time would likely result in a number of partially or unfinished projects.
Secure To protect the confidentiality of the bank‟s customers and to secure the funds dep osited at Bank X, the architecture must provide robust security at the network, system, application, data. While ensuring that no unauthorized access is possible, the security must not
inhibit efficient use of the system by authorized users.
5.3.5 Proposed Application Architecture Strategy
This section 5.3.5 outlines the proposed application architecture strategy to support Bank X's business requirements. This architecture is based on the user
requirements identified in section 5.1. This section propo ses a application architecture that will better enable Bank X‟s growth and profitability goals. The new architecture focuses on developing systems to evaluate product and customer needs, costs, profitability, and requirements. Detailed application strategies are described
in appendix 1.
5.3.5.1 Service Delivery
The service delivery approach is shown in figure 5.3.5.1 The major strategies in the service delivery are as follows: Customer Systems
Customer systems will become increasingly important in the Korean Banking environment over the next five years. Competition from non-Korean banks such as Citibank using advanced technologies, electronic payment, Internet access will raise the technology and application stakes.
ATM/CD
At present, there are no plans to upgrade the ATM and CD network with the exception of building ATMs in the new branches. This decision is based on the strategic focus on Middle/Upper income customers who prefer face to face contact.
This strategy is contrary to the trends seen in the US, Japan, and Europe where banks have significantly upgraded their ATMs. Already Citibank has implemented advanced 24-hr ATMs in Korea that provide a wide range of functions. As we have seen in the US, Europe, and Japan, customer systems can be a key differentiator for the future. In the US, for example, most people choose their bank based on the proximity of the ATMs to their work or home (rather than branch proximity). Similarly, most customers in the US ever enter the branch. Banks in Switzerland provide full function ATMs that let customers perform FX transactions, buy/sell stock, review interest rates, and other advanced banking functions.
Many Western banks are considering adding multimedia features(sound, graphics, and video) to their ATMs which requires both hardware and software upgrades. Nationwide bank in England has bu ilt virtual branches that provide the bank‟s customers with a graphic image of a bank.
In the application plan Bank X must decide whether they believe these trends will occur in Korea and decide how to react.
Electronic Banking (Home/Firm)
At present there are few plans to upgrade Electronic banking, this text-based system was built recently and is similar to other Home/Firm banking applications in Korea. One strategy that Bank X is exploring is the use of the Internet Web server to distribute information about Bank X to current and potential customers.
In the US, Citibank also has an easy to use electronic banking software package which it distributes for free. The other new trend is to use the Internet Web to make payments and provide banking services. Bank of America is piloting Internet based banking in the US.
Credit Card
At present there are few plans to upgrade the Credit Card functions, The main functions currently supported are cash retrieval and payment functions.
In the US, credit cards have become a major force in banking. Most large purchases, entertainment, and travel expenses are paid by credit card. In
addition, credit cards are used for mail order purchases. While credit cards are not as popular in Japan and Europe, usage is increasing. The major trend in the US is to offer credit cards with affinity relationships with Airlines, Hotels, and other leisure companies. This cross-marketing has enabled smaller or regional banks to become major credit card providers. The goal is to find customers who hold balances on their cards, but tend to pay off the loans
eventually.
A new type of credit card is gaining popularity in France: the smart/integrated circuit card, which stores account and transaction information on the card.
This is the first phase of electronic cash.
Phone Banking
Telephone banking will be upgraded to provide full automated (touch-tone) service that will enable customers to check balances and transfer money by phone. This service will replace the use of human operators and will make phone banking available for 24hrs.
Branch Systems
Branch systems refer to the systems used by female tellers, branch clerks, and branch male associates to perform banking functions such as deposit taking, bill payment, lending, foreign exchange, and account management. Systems for tellers and branch clerks will remain stable for the next few years. The major change is to replace the old teller terminals with PCs which has already occurred in the majority of the branches. Banks in the US are limiting their spending on bank teller systems as fewer transactions are through the old teller system and more through ATMs.
Lending systems will be upgraded to improve credit checking and better identify customers who have failed to make loan payments. Barclays Bank in London has a system that automatically performs credit scoring of customers (i.e., evaluates their credit risk and enables tellers to make small loans in 10 minutes)
External Processing
External processing supports functions which are used to communicate with external agencies such as the Bank of Korea, other banks, and credit card companies. These applications are updated as necessary to meet the needs of the external companies.
Transaction Processing
Transaction processing systems support bill and check clearing functions including GIRO.
Information Feeds
Information feeds systems support interaction with external clearing and credit card agencies. This includes wire transfer (SWIFT) and credit card payment Point of Sale (POS) , and electronic funds transfer (EFT).
BOK Wire
BOK Wire from the BOK are used to make government sponsored loans to entrepreneurs and middle-sized companies. It also supports taking deposits from the BOK.
5.3.5.2 Central Processing
Central processing supports bank operations--deposits, lending, account closing, clearing and settlement, product management, and product processing. The majority of these applications were built in the first five years. Because these systems originated in a different banking environment (before interest rate changes, complex products, deregulation), they must be constantly maintained and upgraded. Over the next five years, most effort will be to standardize and document these applications. Secondly thes e application‟s databases will be made more uniform to enable transfer to the enterprise data server.
Where possible, shared processing such as validation, logging, journal processing, authorization handling, work measurement, financial audit trailing, transaction handling should be identified and separated into common modules.。