DOC

3_DATARC

By Ricky Gordon,2014-03-16 16:52
15 views 0
3_DATARC

Data Architecture

December 5, 1995

Title: Data Architecture Summary (English only) Describes Bank Xs future data architecture

    Doc ID :149899688.doc Prepared by :M.S Reviewed by : Ver.: 1.1 Date 2011-3-162011-3-16 Date :

    5.4 Data Architecture .................................................................................................................................................................................................................................... 1 5.4.1 Section Overview .................................................................................................................................................................................................................................. 3 5.4.2 Data Architecture Model ...................................................................................................................................................................................................................... 4 5.4.3 Data Architecture Alternatives ............................................................................................................................................................................................................. 7 5.4.3.1 Data Distribution ...................................................................................................................................................................................................................................................... 7

    5.4.3.2 Centralized Data ....................................................................................................................................................................................................................................................... 8

    5.4.4 Data Architecture Guidelines ............................................................................................................................................................................................................... 8 5.4.5 Proposed Data Architecture Strategy .................................................................................................................................................................................................... 9 5.4.5.1 Data Model...................................................................................................................................................................................................................................... 11 5.4.5.2 Data Capture ........................................................................................................................................................................................................................................................... 14

    5.4.5.3 Data storage ............................................................................................................................................................................................................................................................ 16

    5.4.5.4 Data access ............................................................................................................................................................................................................................................................. 17

    5.4.5.5 Data distribution ..................................................................................................................................................................................................................................................... 18

    5.4.5.6 Data manipulation ................................................................................................................................................................................................................................................... 19

    5.4.5.7 Information presentation.......................................................................................................................................................................................................................................... 19

    5.4.5.8 Data administration ................................................................................................................................................................................................................................................. 19

    Proprietary and Confidential Page i

    Title: Data Architecture Summary (English only) Describes Bank Xs future data architecture

    Doc ID :149899688.doc Prepared by :M.S Reviewed by : Ver.: 1.1 Date 2011-3-162011-3-16 Date :

5.4 Data Architecture

    This section describes Bank X’s future data architecture which manages Bank X’s banking transactions, customer data, product data, and information. The goal of

    the data architecture is to provide accurate information to business users when the y need it and in the form they need it. Better access to information will enable Bank X to be more tightly managed as well as enable new business opportunities to be identified earlier. Because of the nature of Bank X’s information it must be kept secure and confidential.

DATAINFORMATION

    Data Storage

    Data Access

    Data Distribution

    Data CaptureData Manipluation

    Data Modeling

    Data Adminstration

    ;Data Architecture identifies the sources, locations, and types of data that will be managed by the systems.Information PresentationThe data architecture is responsible for ensuring that information is available to applications.

    ;A well defined application architecture will:

    Ensure that data is properly captured by the system and stored in accessible locations

    Move data betweendata between applications and distritbute informaton to where it is needed in the

    bank

    Provide tools to summarize, extract, and manage data

    Keep HNB information investment safe and secure

    Authorize all access to information to prevent invalid or external users of HNB privileged or confidential

    information.

    Proprietary and Confidential Page 1

    Title: Data Architecture Summary (English only) Describes Bank Xs future data architecture

    Doc ID :149899688.doc Prepared by :M.S Reviewed by : Ver.: 1.1 Date 2011-3-162011-3-16 Date :

Key features

    ; Increased use of relation databases management systems particularly Informix to provide enhanced reporting capabilities

    ; Increased use of data extraction and summarization tools that enable users to build their own reports

    ; Development of a central data warehouse to store Bank X’s most important customer, product, and price information so that users across the bank have

    access to accurate information

    ; Use of advanced electronic methods to capture data including electronic banking, Optical Character recognition, and EDI to gather the data Bank X needs to

    process

    ; New tools and methods to distribute data from one location to another to better move information to and from branches. These tools will also be used to

    move information to international locations

    ; Enhanced use of the Enterprise data model for the future database designs to limit the growth of redundant databases

Potential risks

    ; Existing system architecture can not be converted to meet new data requirements

    ; Changes to the business environment--new products, new regulatory rules-- become too fast for the infrastructure to be built

    ; Bank X’s EDP department skills in new database technologies is not sufficient to build the data architecture

    ; Mergers in the Korean Banking environment require merging of Bank X information resources with other banks

    ; Bank X unable to keep up with even new types of data technologies such as object oriented database

Benefits of Data Architecture

    An effective data architecture will help Bank X better manage its information assets. With accurate data and reporting, Bank X executives can be assured that they are making business decisions based on the best available information. The data architecture should have the following benefits:

    Proprietary and Confidential Page 2

    Title: Data Architecture Summary (English only) Describes Bank Xs future data architecture

    Doc ID :149899688.doc Prepared by :M.S Reviewed by : Ver.: 1.1 Date 2011-3-162011-3-16 Date :

    ; Integrates data from many sources - Data will come from many different sources: branches, customers, news sources, external data providers and will be

    entered through multiple applications. It is critical that this information be merged to make it accessible to various information requesters--business managers,

    branch personnel, sales executives, senior executives, and administrators.

    ; Identifies strategic data locations- While data may be entered and moved between a number of applications, there must be a single data location to get the most

    recent and accurate product and customer information.

    ; Provides fast access to information - Information that requires days or weeks to gather is both inefficient and expensive. In some cases, banks have lost large

    sums of money while before they identified credit problems, unreconciled transaction errors, or fraudulent use of the banks resources.

    ; Effective use of advanced data management techniques. - Storing data in the right formats and right locations is critical for use of the information later. ; Reduces redundant storage of data and data storage costs - If information is stored in the proper location and with a limited number of locations, the bank can

    on its data storage and maintenance costs.

; Standardization. By standardizing the data architecture, Bank X can ensure data consistency across the bank’s different types of products and customers

; Increased Usability. Data that is stored in standardize uniform databases can be used across many different applications for many different purposes.

5.4.1 Section Overview

    The data architecture section is comprised of the following sections:

    5.4.2 Data Architecture Model - presents a conceptual model used to categorize and visualize the architecture components.

    5.4.3 Data architecture Approach - defines the benefits and risks that are likely to arise and the high level data distribution approach.

     - 5.4.3.1 Data Centralized

     - 5.4.3.1 Data Distribution

    5.4.4 Data Architecture Guidelines - presents guidelines that should be followed in order to implement a successful architecture.

    5.4.5 Proposed Data Architecture Strategy - this section illustrates the likely features of the new architecture. It contains the following sub-sections:

     - 5.4.5.1 Data Modeling

     - 5.4.5.2 Data Capture

     - 5.4.5.3 Data Storage

     - 5.4.5.4 Data Access

     - 5.4.5.5 Data Distribution

     - 5.4.5.6 Data Manipulation

     - 5.4.5.7 Information presentation

     - 5.4.5.8 Data Administration

Proprietary and Confidential Page 3

    Title: Data Architecture Summary (English only) Describes Bank Xs future data architecture

    Doc ID :149899688.doc Prepared by :M.S Reviewed by : Ver.: 1.1 Date 2011-3-162011-3-16 Date :

5.4.2 Data Architecture Model

    This section presents the vision data architecture model, and identifies the main areas to consider when designing individual components of the data architecture. This model is a conceptual model used for categorizing and visualizing the data components. The vision data architecture model consists of nine components reflecting the complexities and interdependencies that underlie the data architecture. The components include:

    ; Data modeling

    ; Data capture

    ; Data storage

    ; Data distribution

    ; Data manipulation

    ; Information presentation

    ; Data administration

Proprietary and Confidential Page 4

    Title: Data Architecture Summary (English only) Describes Bank Xs future data architecture

    Doc ID :149899688.doc Prepared by :M.S Reviewed by : Ver.: 1.1 Date 2011-3-162011-3-16 Date :

    InformationDataPDataIrStorageneC

    fsaDoeparnttData Accessmtuaaar

    tteData Distributionii

    oo

    nn

    Data Manipulation

    Data Modeling

    Data Administration

    PhysicalSupport ActivitiesLogical Figure 5,4,2

    Figure 5.4.2 shows the eight components of VISION Data Architecture which are described below:

    Proprietary and Confidential Page 5

    Title: Data Architecture Summary (English only) Describes Bank Xs future data architecture

    Doc ID :149899688.doc Prepared by :M.S Reviewed by : Ver.: 1.1 Date 2011-3-162011-3-16 Date :

Data Modeling

    Data Modeling describes information in terms of data entities, attributes and relationships between entities. A data model is not synonymous with a data architecture --it is one component of it. Data modeling is a technique used to describe the objects in the real world about which an organization wishes to hold information to support business operations. This information is expressed in the form of data entities, attributes and relationships between entities. Data modeling is the logical component of data architecture; by cataloguing data entities and the relationship between them, it plays a crucial role in ensuring that an organization's data architecture meets the needs of the business.

    Logical data models should be developed in a hierarchy: for the enterprise, for system groups and for individual projects. These models differ by the scope of business functions they support and the level of detail to which they are defined; each fulfills a specific purpose in the systems development life cycle and builds upon models higher up in the hierarchy:

    ; An Enterprise Data Model, developed at the planning stage, defines at a high level the 10 to 20 business entities and the relationships between them that

    are important to the institution. This model facilitates communication with senior management and helps resolve functional issues at the enterprise level. It

    should outlive the majority of application systems.

    ; Systems group data models define data entities and relationships for a group of systems within an enterprise. They are used to identify data interfaces and

    flows between key functional areas and application systems and thereby define the scope of individual projects. They highlight data constraints and

    dependencies between individual projects and enforce consistency across systems which supply group or enterprise-level data. They help communicate the

    purpose and scope of a group of systems to senior management.

    ; Project data models, developed in systems design, define data entities and relationships for an individual project. They are used to develop a physical

    database design for a system and to enforce consistency of design across the project. They enable a large range of users to understand the system being

    developed based upon the business data being processed. They increase the stability of the system over its life span by ensuring that the definition of data

    entities is unlikely to change.

Data Capture

    Data Capture involves the receipt of data into an institution's application systems. Data can be captured as characters, image, three dimensional graphics and voice. Many multi-media technologies use capture mechanisms that improve customer service, increase user acceptance and productivity, reduce learning curves and training costs and lower error rates.

Data Storage

    Data Storage defines how the data is physically stored. It defines file organization (sequential, indexed, etc.), physical medium (tape, optical disk etc.) and data representation (ASCII vs. EBCDIC, character string vs. record etc.).

Data Access

    Data Access enables applications to access and manipulate data stored locally or remotely in files or databases.

    Proprietary and Confidential Page 6

    Title: Data Architecture Summary (English only) Describes Bank Xs future data architecture

    Doc ID :149899688.doc Prepared by :M.S Reviewed by : Ver.: 1.1 Date 2011-3-162011-3-16 Date :

Data Distribution

    Data Distribution defines the number of copies of each data entity and the physical location of those copies including any segmentation. For any given retail

    financial institution, factors such as user location, required currency of data, the type of data operations to be performed and performance requirements determine how data should be distributed for optimal use across the organization.

Data Manipulation

    Data Manipulation takes captured data and manipulates it into a format for physical storage. It also takes stored data and manipulates it into a format for

    presentation.

Information Presentation

    Information Presentation defines the way information is presented to customers, employees and other institutions. The same multi-media technologies which are

    available for data capture also provide attractive vehicles for information presentation.

Data Administration

    Data Administration defines and maintains data standards and policies throughout the enterprise and creates and maintains data definitions of entities and their attributes and relationships. Data standards, of themselves, do not ensure that information gets to the right people in the right form. This functionality is ensured through the Application Architecture and Technical Architecture. Data administration activities need to be integrated into the development and execution environments.

    Decisions about Data Storage and Data Access tend to be constrained by other technical and application architecture decisions. For example, if imaging is to be used, then the appropriate hardware will be required for storage. Decisions about the other six components of Data Architecture are more complex.

    5.4.3 Data Architecture Alternatives

    One of the major decisions that Bank X must make is the degree of data distribution. Before the advent of PCs and client/server systems most data was managed centrally. However the trend in many IT organizations over the past five years has been to distribute data to various bank departments and branches. 5.4.3.1 Data Distribution

    The advantage to data distribution is that it brings information closer to the users usually in data bases specifically designed for their applications. At Bank X, the FOCUS program is an example of an application with distributed data. Each night, branch information is sent from the EDP center to the various branches.

    Because data is more available and easier to access, many client server systems were developed with this departmental model over the past 5 years at organizations in the US, Europe, Japan as well as Korea. Bank X’s three main client/server system are FOCUS, ALM, and EIS. Another major driver for distributing data is that

    EDP organizations found that working with smaller databases was easier and new RDBMS databases (e.g., Informix) much more intuitive than mainframe dbs (e.g., IMS and DB2). With an application specific database, it much easier to make minor adjustments without impacting other applications.

    Proprietary and Confidential Page 7

    Title: Data Architecture Summary (English only) Describes Bank Xs future data architecture

    Doc ID :149899688.doc Prepared by :M.S Reviewed by : Ver.: 1.1 Date 2011-3-162011-3-16 Date :

While distributed data has many advantages, there are also problems with distributing data :

    ; Higher maintenance costs: Database managers must monitor both central and distributed data. Multiple database tables must be maintained

    ; Data redundancy: data must be stored in two places and moved transferred periodically. This adds to system costs

    ; Data inconsistency: Data in one location may be different from data in other locations due to timing problems or errors. Often changes are made in one

    system, but not updated in the other.

    ; Less security: As data moves to multiple locations it can become increasingly less secure. More people have access to raw information that may contain

    client confidential information. While mainframe databases generally have strict access control, many distributed systems have fewer controls or

    administrators do not implement controls

Recommendation: Distribute data to branches particularly read-only information that is frequently accessed. By sending this data periodically (once/day),

    Bank X can reduce network traffic and improve branch system performance.

    5.4.3.2 Centralized Data

    While there are many temptations to distribute data, most database experts believe that data should be centralized whenever possible. The main advantage to

    centralization is that everyone in the bank has the same view of the bank’s data. In addition, more data can be stored on a large central computer thus applications can review all the bank’s data or review different types of data (e.g., match customers with products). Another advantage of centralization is that in the long-run it

    saves money, be requiring only a small team of data administrators rather than multiple experts.

    The disadvantages of centralized data have traditionally been due to the mainframe platform. Disadvantages include:

    ; Less flexibility: Because centralized data is shared, small table changes impact many programs , so it is difficult to change data formats.

    ; Fewer database options: Generally the choice has been to use either IMS or DB2 for mainframe databases

    ; Take longer to implement: A centralized data structure takes longer a time to implement because it must be designed for multiple purposes.

Recommendation: Distribute data to branches particularly read-only information that is frequently accessed. By sending this data periodically (once/day),

    Bank X can reduce network traffic and improve branch system performance.

    5.4.4 Data Architecture Guidelines

    This section presents guidelines that will be followed throughout the implementation of the data 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.

Proprietary and Confidential Page 8

Report this document

For any questions or suggestions please email
cust-service@docsford.com