Σχόλια 0

Το κείμενο της παρουσίασης

The information provided in this document was collected and prepared by IBM Global Services duringengagement activities at Uscardxx Financial Services, Inc. from June 1999 through August 1999.



Copyright International Business Machines Corporation 1999. All rights reserved.

International Business Machines Corporation provides this document “as is,” without warranty of any kind either expressed orimplied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.

3

IT Architecture Contents

Business

Vision,

Objectives and

Strategies

IT Vision,

Objectives and

Strategies

Existing IT

Environment

New and

Emerging

Technologies

Systems

Systems Management

Data

Network

Applications

Data

Systems

Network

Systems Management

Realize Solution

(Member Svcs)

ITA Transition Plan

IT Principles

IT Architecture Model

Conceptual

Logical

Evaluation Criteria &

Process

IT Architecture Mgt Process

Information Technology

Architecture

Applications

IT Infrastructure

Realize Solution

(Merchant Svcs)

Realize Solution

(Marketing)

Architecture Management and Transition Processes

4

IT Architecture

Table of Contents

I. Overview-

10

Executive Summary

Part of the Planning Process

Purpose

Requirement

Description

Goals

Development Methodology

Development Phases

Development Activities

Relevancy and Linkages

II. Business Objectives-

25

IT Architecture Alignment with Business Strategy

USFI Business Objectives

5

IT Architecture

Table of Contents(continued)

III. Architecture Principles, Motivations, and Implications-

28

Description and Guidelines

Categories of Principles

Guiding

Organization and Management

Application/Application Development

Data

Network

Systems Management

IV. Architecture Model-

71

Introduction

Usage

Conceptual Model

Modeling Process

USFI Architecture Model

Logical User Views

User Group View Analysis

User Group Template

Network View

6

IT Architecture

Table of Contents(continued)

V. Architecture Building Blocks-

85

Categories and Template

Building Blocks

Application Enabling

Presentation Services

Application Development Tools

Application Services

Data Access Services

Distributed Systems Services

Communications Services

Object Management Services

Distribution Services

Network Services

Transport Services

Transport Protocols

Transmission Technology

Physical Equipment

Network Platform

Physical Computing Platform

Operating Systems

Systems Management

7

IT Architecture

Table of Contents(continued)

VI. Product Evaluation Methodology-

217

Evaluation Process

Methodology Objectives and Steps

Evaluation Scoring Example

Product Evaluation Toolkit

Evaluation Workbook Overview

Hints and Tips

Evaluation Criteria Definitions

VII. Evaluations and Recommendations-

259

Principles to Business Objectives Assessment

ABB Statistics and Analysis

Strategic, High ABBs

Legacy ABBs

ABBs Requiring Standards Definition

ABBs with Requirement for Further Study

ABBs for Future Consideration

High Impact ABB Recommendations

Matching the ITA with Implementation Plans

Application Category Matrix

8

IT Architecture

Table of Contents(continued)

VIII. Architecture Management Processes-

282

Benefits

Participants and Groups

ITA Interface with IT Planning

Simplified Process Views

Role and Responsibilities

Management Processes

Architecture Review and Approval Process

Architecture Exceptions and Appeals

Architecture Vitality Process

Architecture Communication Process

R & D Process

Position Paper

IT Architecture Staff

Management Initiatives

9

IT Architecture

Table of Contents(continued)

IX. IT Architecture Transition Planning-

313

IT Architecture Acceptance

Transition and Maintenance Calendar

IT Architecture Resources

X. Appendix-

319

Product Evaluation Worksheets

ABB Listing in Report Sequence

ABB Listing Sorted by Classification and Priority

ABB Action Item Matrix

IT Architecture Intranet Portal Design Concept

Interview Participant List

IT Architecture Workshop Attendance

10

The Information Technology (IT) Architecture project was completed to create and document anenterprise-wide Architecture for USFI. An Architecture is a set ofprinciples

andrules

for defining thetechnical platforms on which to build systems and services.

Principles are statements of fundamental guidelines that support the architecture and areassociated with key business requirements. (ex. Business Technology exists as a consultingpartner to the business units to define, design, and implement application systems.)

Rules specify the chosen application and data models, hardware, software, managementprocesses, and common system services that define your information systems.

The IT Architecture (ITA) project was accomplished using a combination of workshops andindependent activities by teams and individuals. The overall process and the team activities wereled by IBM IT Architecture Consultants.

The IT Architecture provides a high-level representation of the target information system environment for the long-term (Conceptual Model). This model establishes a common vocabulary and defines a set of services and standardinterfaces to USFI information systems. The reference model and standards profile define the target technicalenvironment.

Within the context of information systems, a reference model is defined to be a generally accepted representationthat permits agreement on definitions, builds common understanding, and identifies issues for resolution. An ITArchitecture is necessary to establish a context for understanding how the various technologies required toimplement information management are interrelated.

The model also provides a mechanism for identifying the key issues associated with applications portability,scalability, and interoperability. The IT Architecture will serve to facilitate interoperability between applications,portability across platforms, and cost reductions through the use of common services. The development andacceptance of the IT Architecture is critical to the successful implementation of USFI data processing initiatives.

As shown on the following diagram, the IT Architecture is part of the strategic planning process. Business strategyand objectives are used to define IT requirements. The IT Architecture guides the implementation of the technologyinfrastructure to meet business needs. The IT Architecture considers a three to five year planning horizon. It isrevised at least annually to reflect changes in the requirements, environment, and technology. Tactical system andapplication implementations are influenced by the IT Architecture.

12

The IT Architecture-

Part of the Planning Process

Business

Strategy

IT Requirements

(IT Strategic Plan)

IT Architecture

IT Infrastructure

Appl. A

Appl. B

Appl. C

Strategic

Tactical

3-5yr..

Target

1yr..

Revisions

13

Purpose of the IT Architecture

The purpose of the IT Architecture described in this document is:

To define a conceptual framework and associated common vocabulary so that the diverseorganizational areas within USFI can better coordinate the acquisition, development, andsupport of information systems.

To support technology decisions and plans that maintain alignment between businessobjectives and the deployment of IT resources.

To provide a repository of information that permits consistent and timely technologydecision-making and to promote resource sharing and reuse.

To improve the overall cost effectiveness of IT within USFI.

14

IT Architecture Requirement

The USFI is actively responding to changes brought about by:

business and market place conditions

regulatory agencies

the industry environment.

All of these changes are having at tremendous impact on the technology staff and resources of the organization.Business Technology projects are underway to:

implement new and revise existing applications

provide new levels of data sharing with merchants, cardmembers, and within USFI

expand and improve existing technology processes.

In support of the business requirements, the technology infrastructure is also participating in a period of growth andchange that includes:

upgrading various system and network components to maintain and improve service levels.

The Business Technology organization responded by creating an Information Technology Architecture (ITA) toimprove the use of information technology as an efficient and effective business enabler.

15

IT Architecture Description

The ITA consists of the following key components:

Architecture Principles

-

broad, enduring statements regarding the deployment of IT resources upon whichfuture IT decisions will be based.

Architecture Models

-

various views of the functionality of IT systems. These models provide a basis foranalyzing the potential impact of new technology or changes in business requirements.

Evaluation Criteria

-

a basis for technical decision making that allows independent technology decisions tobetter align with each other and with the business requirements.

IT Architecture Management Process

-

the process which allows the architecture to evaluate and incorporatenew technology and respond to new business requirements. It is also the process by which uniquerequirements can be met through the granting of exceptions to the standard architecture.

IT Architecture Transition Plan

-

evaluates the Architecture Building Blocks and their strategic significance tothe business and considers the migration to the target architecture.

Together, these components provide a framework for decision making in the deployment of IT resources. The ITArchitecture promotes a consistent approach to system development and implementation, improves the sharing ofcommon IT resources, and maintains the flexibility required to respond to changing business requirements. The ITArchitecture also accommodates an independent decision process for response to regional and local conditions.

16

Goals for the USFI IT Architecture

Business Value

A well-defined and implemented enterprise IT Architecture should help USFI:

Improve the quality and process for IT decision-making

Create an enterprise-level perspective of IT resources

Simplify the USFI technology infrastructure

Increase productivity and efficiency

Reduce delivery and maintenance times for new applications and technology

Improve the quality of IT applications, infrastructure, and services

17

IT Architecture Goals

These goals are achievable through the application of the IT Architecture presented in this document:

More Rapid and Consistent Technical Decisions

-

Adoption of technology principles and evaluation criteria shouldprovide an objective foundation for making technical decisions, reduce the time required for each decision, andimprove the quality and consistency of such decisions. As USFI begins to exercise the architecture, it is expectedthat more consistent technology decisions and practices will lead to better leveraging of investments in technology.

More Clear Communication of the IT Infrastructure

-

By formalizing the development and communication of theIT Strategy, Architecture Principles, and standards to the business units, the architecture can become an integralpart of the Business Technology management process. It will define an architecture model of the IT infrastructurewhich will improve understanding of installed and planned systems and how they interact with each other in supportof users. By providing a repository for architecture information, this document should improve the commonunderstanding of many IT issues among the various decision making entities and improve the buy-in of the manygroups involved in each IT investment decision.

Less Complex Infrastructure Design

-

With the increased interrelationship of components in distributed ITsolutions, the number of components from which solutions are created must be maintained at a manageable level.Selecting a set of common components to meet requirements can reduce implementation and ongoing supportcosts, decrease the time to implement solutions, and improve the overall effectiveness of IT deployment. Fewer,well-selected components may be needed to implement a given application.

18

IT Architecture Goals(continued)

Increased User Productivity

-

User productivity improvements can be realized through a consistent user interface,application integration, and data sharing. A consistent user interface helps ensure that all user accessible functionsand services appear and behave in a similar, predictable fashion regardless of application or site. Integratedapplications will behave in a logically consistent manner across user environments. Databases are shared acrossthe organization in the context of security and operational considerations.

Increased Development Productivity

-

While the architecture evolves to define common modules of functionalitywith common and well-defined solutions, new development efforts will be able to leverage this modularity and reusemore of the existing functionality than has been possible in the past. Also, adherence to the IT Architecture indeveloping systems and making platform decisions should lead to more homogeneous environments and make thewidespread sharing of application systems, data, management processes, and resources more achievable.

Reduced Deployment Times-

The efficiency of development efforts will be improved by using packagedapplications, sharing resources, and reducing the amount of development. A standards-based environment thataccommodates new standards and technologies will promote component reuse. Off-the-shelf, industry standardproducts can reduce dependence on custom development activities and reduce development and maintenancecosts. For those applications that must be custom developed, portable application design will reduce the amount ofsoftware to be created and add to the inventory of software suitable for reuse by other systems. Technologyresources (hardware, software, data, and skills) can be shared by across Business Technology departments.

Enhanced Business Technology Service Quality

-

As platforms, tools, and system environments migrate towarda common architecture, compatible skills will be developed across the organization which can be leveraged throughsharing and rapid redeployment. Transfers from one department to another will potentially require less retraining asthe systems and their user interfaces become more homogeneous. More time is spent honing existing skills thandeveloping new skills. Higher IT skill levels can lead to the delivery of higher quality IT services.

19

IT Architecture Development Methodology

Planning

Status

and

Requirements

Architecture

Principles

Architecture

Modeling

Architecture

Management

Management

Action

Plan

Planning

Sessions

Gather and

Summarize

Inputs

Document

Key

Requirements

Principles

Definition

Workshops

Develop

Conceptual

Model

Create

User

Views

Develop

Evaluation

Criteria

Define

Architecture

Management

Processes

Develop

Transition

Plan

Report

and Gain

Agreement

20

IT Architecture Development Phases

Phases of Development

The upper portion of the previous diagram shows the phases of the architecture development process:

Planning and Startup

Gather Current Status and Requirements

Analyze Requirements

Develop Architecture Principles

Build Architecture Model

Develop Evaluation Criteria and Process

Assess Architecture Transition

Define Architecture Management Process

The activities, analysis, and outputs in this IT Architecture development process were customized for the specificenvironment and needs of USFI.

Each phase includes one or more activities as shown on the lower portion of the previous diagram and described onthe following pages.

21

IT Architecture Development Activities

Planning and Startup

These tasks are aimed at clarifying the objectives, gathering the resources for the project, and planning. Thisactivity may have been completed during the engagement planning phase, but has been kept here forcompleteness.

Gather Current Status and Requirements

Collect and arrange all the relevant information already existing in your organization. This activity typicallyinvolves much individual or subgroup work by the team members. All known sources of information are listedalong with individuals or departments who are likely to have valuable input for the architecture definitionproject. Interviews are conducted with selected individuals. A list of USFI personnel interviewed during thisproject is included in the Appendix of this document.

Define a set of architecture principles which can be linked back to your business drivers.

22

IT Architecture Development Activities(continued)

Build Architecture Model

Produce a high level specification of the shape and form of the information technology architecture.

Develop Evaluation Criteria and Process

Define a set of evaluation criteria and an evaluation process that will be used to evaluate and selectcomponents for the information technology architecture.

Assess Architecture Transition Plan

Analyze and create an outline of the key elements of the information technology environment that mustchange to implement the target architecture.

Define Architecture Management Processes

Create an overall plan to communicate, control, manage, and implement the architecture you have defined.

Report and Gain Agreement

Create the Architecture Definition Report and present the findings.

23

IT Architecture Relevancy

The IT Architecture of USFI guides the future implementation of the information technology infrastructure. As shownon the following diagram, the major architecture components (principles, architecture building blocks, and evaluationcriteria) are developed to meet the specific environment and requirements of the business and Business Technologyorganizations. Starter sets of principles and building blocks are provided from the IBM architecture repositories.

Throughout the development of the architecture, linkages are established and evaluated to ensure alignment ofbusiness and technology strategies. Technology principles must support the business objectives. Building blocksmust be supported by the technology principles. The evaluation criteria are designed to facilitate rational productselection to implement one or more building blocks. Requirements and principles are input to the evaluationprocess. Requirements and building blocks drive the creation of a transition plan to move from the current to thefuture architecture state.

Relevancy of the architecture is ensured through communication of the current state and linkages between theindividual architecture components.

24

IT Architecture Linkages

Architecture Management Process

Interviews

USFI

Architecture

Principles

USFI

Arch. Building

Blocks

Linkage

Linkages

Available

Solutions

Selected

Solutions

Linkage

USFI

Documents

Business

Status and

Requirements

Requirements

to Principles

Evaluation

Matrix

Principles

Repository

USFI

Technology &

Requirements

ABB Starter

Repository

Transition

Plan

USFI

Evaluation

Criteria and

Process

25

The business objectives of USFI are the high-level drivers for the strategies and plans of thefunctional business units. The IT Architecture, when properly aligned with the business objectives,provides a framework for the deployment of technology resources that support the businessstrategies and plans.

As shown on the following diagram:

Business objectives influence business strategy and plans.

Technology availability influences the Business Technology strategy and plans.

Business strategy is linked to technology strategy.

Business strategies create requirements for the business organization and procedures.

Technology strategies create requirements for the Business Technology organization andarchitecture.

Business procedures are linked with the technology architecture.

The operating environment is established by the business organization and procedures.

The technology infrastructure is established for the technology organization andarchitecture.

II. Business Objectives

26

IT Architecture Alignment with Business Strategy

Business Strategy

and Plans

Business Technology

Strategy

and Plans

Business

Organization

and Procedures

Business Technology

Organization

and Architecture

Strategic

Linkage

Tactical

Linkage

Business

Requirements

Technology

Requirements

Business

Objectives

Available

Technology

Influences

Technology Infrastructure

Operating Environment

27

USFI Business Objectives

These USFI business objectives were derived from company documents and interviews with across-section of the management staff. The objectives focus on organization strength, servicequality, new opportunities, business management, flexibility, and profitability.

Achieve market share objectives

Increase annual profits

Meet Return on Equity objective

Maintain focus on risk management

Expand credit card business in a major foreign market

Increase number of merchants and ATM’s accepting Uscardxx card

Continue to monitor cost

Apply new technology and innovation to meet financial challenges

1999 Financial Objectives:

Increase number of accounts by 5 million

Increase transaction volume by $8 billion

Increase profit by 25% compared to 1998

Decrease consumer loan losses to $2.05 billion

28

III. Architecture Principles, Motivations, and Implications

IT Principles are statements of intent or purpose related to the management of InformationTechnology within USFI. Principles reflect a vision of improved ways to manage or use technologyto benefit the business. They describe preferred practices to be followed when implementing new orupgraded systems. They provide the foundation upon which the models (architecture, management,process, design) are built. Principles should be based on the needs of the business and on a visionof an improved Information Technology environment within which to develop and operate systems tohelp meet those needs.

Principles relate business and Information Technology in language all managers can understand.Each Principle is supported by documentation of the reason (Motivation) for it being included andthe effect (Implications) it will have on future technology decisions.

29

Principles of this type will discuss:

The autonomy of business units over IT decisions about applications, data andtechnology.

What will be controlled by the Business Technology organization, departmentsor business units.

Use of proprietary and open architectures and standards.

Principles related to current conditions and future direction, not selection ofspecific items.

The approach to decentralization of IT systems.

What part will be played by mainframes, mid-range systems, various serversand client workstations. Where will they be located in relationship to oneanother. How important is the WAN and LAN network in providing a unifiedcomputing environment.

The distribution of applications and data.

Which will be centralized and which will be kept nearer the users.

The IT Principles may be used to describe the philosophy

or style of computing that the enterprise will follow

30

Guidelines for developing good principles

A good principle:

States a fundamental belief of the enterprise in one or two clearly writtensentences.

Recommends an action against which some arguments could be made.

Has relevance to a technical architecture.

Is worded directly and simply in terms understandable by both business andBusiness Technology managers.

Has business wide applicability.

Is durable; will not be outdated quickly by advancing technology.

Has objective reasons for advancing it instead of the alternatives which wereconsidered.

Has impacts which need to be documented.

A poor principle:

Makes a statement which no one would dispute.

Is a general business or financial statement.

Has little or no general applicability. It may actually select a standard or atechnology.

Is stated at too low a level of detail and may not endure.

May be included "because I say so".

31

USFI Principles Categories

Guiding

These principles describe management philosophies and an overall view of organizationconsiderations affecting the implementation of Information Technology at USFI.

Organization and Management

These principles define goals and objectives for the architecture that apply the organization andmanagement of processes to deploy and support information technology.

Application/Application Development

Factors affecting the development and delivery of business applications to the end user aredescribed by these principles.

Supporting multiple alternative technologies is more difficult and may require additionalresources.

39

Guiding Principle

7. Selection Guidance

In order of general importance, USFI will seek to select technology solutions that 1) providethe best functional fit, 2) are cost effective, 3) generally accepted in the industry, 4) non-proprietary, and 5) are defined industry standards.

Motivation

Provide the most advanced and appropriate function.

Minimize the cost of IT.

Use proven solutions with known track-record.

Avoid lock-in to particular vendor solution.

Use solutions that adhere to standards organization definitions when possible.

Impact

Must provide these criteria as input to the product evaluation and selection process.

40

Guiding Principle

8. Technology Re-usability

Business Technology strategies will first consider existing USFI technologies where theysatisfy business needs and fit within the IT Architecture.

Motivation

Reduce costs by re-using existing USFI technologies.

Support the buy vs. build decision process.

Reduce development cycle time.

Impact

Must create a catalog of components which are candidates for re-use includingdocumentation of component function and design.

Change management techniques must be applied to reusable components to ensure futurereusability.

Ensure that quality is not sacrificed for speed.

41

Guiding Principle

9. Strategic Business Technology Partners

USFI will identify and formalize relationships with our strategic Business Technology partners.

Motivation

Maximize the efficiency and effectiveness of the solutions and resources provided by ourvendors.

Create a set of selection criteria that guides our outsourcing evaluation and selection.

42

Organization and Management Principle

10. Role of Technology

Technology will be used to gain and maintain a competitive advantage, enabling adaptationto changing business needs.

Motivation

Leverage IT to gain competitive advantage.

Impact

The initial costs may be higher to maintain flexibility over the useful life of the technologysolution.

43

Organization and Management Principle

11. Role of Business Technology

Business Technology exists as a consulting partner to the business units to define, design,and implement application systems.

Motivation

Business Technology management must focus on designing technology projects that providethe most business benefit.

Business Technology must be involved in business plans and strategies and be viewed as abusiness partner for both externally provided and internally developed technology solutions.

Impact

A planning methodology must be created that integrates business and technology processesand procedures.

Business Technology must accept and perform the consultative role.

44

Organization and Management Principle

12. Requirements Definition

The business units will create specifications and requirements for new applications withassistance from Business Technology; Business Technology will implement the newapplications with adherence to the IT Architecture.

Motivation

Application specifications should focus on business requirements and objectives.

Business Technology should provide what is needed and not simply what is requested by thebusiness.

Impact

The IT Architecture must be communicated throughout the Business Technology andbusiness organizations.

The business units must buy-in to and accept the IT Architecture.

45

Organization and Management Principle

13. Application/Technology Cost-Benefit Justification

Business units are the application owners responsible for defining requirements, justifyingand gaining approval for IT costs, and managing the benefits. Business and BusinessTechnology will collaborate to complete a cost/benefit analysis.

Motivation

Business Technology should be viewed as a consultative development partner to thebusiness units.

Business units are in the best position to justify new application expenditures and quantifyexpected benefits.

Information Systems is responsible for justification analysis of technology componentsconsidering the corporate-wide cost to implement and support each component over theexpected useful life.

Motivation

Cost evaluation should not ignore ongoing support costs.

Business Technology is in the best position to evaluate new technology components.

Impact

Business units must not dictate the design of specific elements of the application system.

47

Organization and Management Principle

15. Research and Development

Evaluation of new technology solutions will be driven by business needs and supported byan "R & D" function that coordinates and communicates evaluation activities across theenterprise.

Motivation

Coordinate the evaluation of new products and technologies.

Business drivers mean finding solutions to business problems.

Impact

The R & D function must be funded.

Requires a business process for registration of an R & D effort sponsored by business orBusiness Technology.

Must create a method for communicating R & D efforts and results.

48

Application/Application Development Principle

16. Application Solutions Evaluation

When proposing application solution alternatives to a business unit, Business Technologyhas the responsibility to provide the criteria used to make the evaluation, the evaluationresults, and the trade-offs that may result for each alternative solution.

Motivation

Protect the integrity of existing application/systems when making changes to accommodatea new application.

Maintain and improve the flexibility of application systems.

Ensure that the business unit can make an informed decision concerning an applicationsolution alternative.

The development tool selection process must also consider current knowledge, execution,efficiency, and availability of developer resources.

Development tool criteria must be identified and used in the selection process.

54

Application/Application Development Principle

22. Application Delivery Standard

Application systems will be delivered to users through a single workstation on theirdesktop using the most cost-effective technology.

Motivation

Provide consistent application delivery platform and interface.

Reduce cost of application delivery to the end user.

Impact

Desktop configurations must be managed to maintain a consistent software and hardwareinventory.

A standard desktop configuration must be identified.

Must develop a migration plan to move non-standard desktop configurations to the standardconfiguration.

Alternative configurations must be available to handle exception conditions.

55

Application/Application Development Principle

23. Application Architecture

The application architecture will determine the appropriate placement of application logic,stored data, presentation services, and business rules and will guide the design of USFIdeveloped and purchased application systems.

Motivation

Provide consistent direction for application design.

Impact

Must create and deploy a USFI Application Architecture.

Adherence to application architecture may constrain the choices and increase thecustomization requirements for purchased applications.

The Application Architecture must include a definition for re-usable components.

56

Application/Application Development Principle

24. Design for Growth

Systems will be designed and implemented to take advantage of available techniques andtechnologies to extend the useful life over the strategic planning horizon of the business.

Motivation

Provides strategy to scale applications for large growth potential.

Impact

Must gain an understanding of the expected workload characteristics and requirements over theplanning horizon.

A predefined upgrade strategy may be required.

57

Application/Application Development Principle

25. Programming Style

Application systems will be designed and assembled from structural components tomaximize potential re-use.

Motivation

Maximize re-use potential of code modules.

Impact

Must create and maintain an inventory and catalog of re-usable components includingcomponent documentation.

An application/system is ready for implementation into production after the businesspartner successfully validates the usability of function and the attainment of projectrequirement and the project sponsor approves the application/system for production.

Application recovery procedures must be defined to match the application class of service.

70

Systems Management Principle

38. Systems Management Disciplines

The USFI IT Architecture will include methods and technology component requirements foreach of the major systems management disciplines.

Problem Management

Change Management

Operations Management

Performance Management and Capacity Planning

Configuration Management

Event Monitoring

Software Distribution

End User Support

Security

Motivation

The implementation of the systems management disciplines across the enterprise is anecessity to maintain the effectiveness and availability of the IT infrastructure

Impact

Appropriate systems management processes and techniques must be selected anddeployed.

Systems management roles must be identified and responsibilities assigned.

Systems management disciplines must be an integral part of all application systems.

71

IV. IT Architecture Model

The objective of modeling is to visually and logically represent the main features and functions of theIT Architecture and provide a framework within which it can be implemented. The architecture modelprovides various views of the architecture, defined in terms of architecture building blocks.

This section includes:

The USFI Conceptual Model

The User Group View Analysis

The Network View of the Conceptual Model

The detailed building blocks are described in the section “Architecture Building Blocks.”

72

Introduction to the Architecture Models

The conceptual model provides an overall view of the USFI IT environment. It shows the building blocksrequired to meet the defined IT business requirements.

TheConceptual Model

consists of four primary focus areas. TheApplications and ApplicationsEnabling Services

components define the disciplines and processes required to develop and deliverbusiness systems to the end user. TheDistributed Systems Services

focus area defines the disciplinesand processes required to maintain a highly effective and available group of systems.Network Services

identifies the hardware components needed to support the network and computing functions.

TheLogical User Views

represent various working environments of the USFI enterprise. A LogicalUser View illustrates the appropriate building blocks required to meet the needs of each of a specificUSFI user group. The section “User Group View Analysis” provides a detailed discussion of theactivities necessary to accomplish the user group analysis and the potential benefits of completing theprocess.

TheNetwork View

offers a high level view of the components of the network needed to connect themany systems involved in the distributed systems environment.

73

Using the Architecture Models

The architecture models are used by implementers of technology systems and applications to:

understand the context in which applications operate

know what services are available for their use

identify which applications will be running concurrently

recognize required but missing services.

The system architect uses the architecture models to:

IT architect can assess the impact of adding new functions

IT architect can assess the impact of architecture changes

IT architect can assess the impact of architecture changes

Periodic review and update of the architecture models ensures that the value of the architecture is retained. Updates mayinclude adding, deleting, or changing building blocks. Changes are reviewed and approved through the ArchitectureManagement Process described in this document.

74

USFI Conceptual Model: An architecture that integratesdifferent forms of computing on a common base.

Defines common functional building blocksand interfaces for distributed computing

Depicts functions and shows relationshipto other components

Functions are grouped into logical entities

Leads to modular, scalable systems thatare easy to grow and enhance

Provides a vocabulary and context inwhich to discuss and organize technologyissues

Presents a pictorial representation to helpmake the architecture visible and tangible

75

Architecture Modeling Process

Progressively developed models that represent the main features andfunctions of the ITA and provide a framework for the ITA implementation.

Level One Architecture Building Blocks are described in the section “Architecture Building Blocks.”

76

USFI Architecture Model

Composed of Architecture

Building Blocks needed to

meet Business Technologybusiness requirements:

Presentation Services

Data Access Services

Applications

Application Services

Distributed System Services

Transport Services

Transport Protocols

Transmission Technology

Physical Equipment

Local Operating Systems

Systems Management

Conceptual Model

Overall view of the

target IT environment

Logical User Views

Building blocks required to

meet the needs of aspecific user group

Applications

and

Application

Enabling

Services

Distributed

Systems

Services

Network

Services

77

Architecture Conceptual Model-

Overall view of the target ITenvironment

Defines disciplines and

processes needed to

develop and deliver

business systems to

the end user

Defines disciplines and

processes needed to

maintain an effective

and available group

of systems

Defines communication

capabilities needed

to meet the business

requirements

Applications

and

Application

Enabling

Services

Distributed

Systems

Services

Network

Services

78

User Group View Analysis

User groups define subsets of the USFI organization that depend on Business Technology services.User group view analysis requires identifying relevant groups of users and linking each group totheir required ABBs.

Output from the user group analysis process can help:

ensure that all relevant ABBs have been defined

provide an understanding of ABB impact across user groups.

This section outlines the process to perform user group view analysis.

User group view analysis was not completed at the time of this report by mutual agreementwith the USFI Architecture management department.

However, user group view analysis maybe useful in the future to assist in managing and updating the IT Architecture definitions.

79

Logical User View-

Identifies Architecture Building Blocksrequired to meet the business needs of a specific user group



All USFIArchitecture BuildingBlocks arerepresented



One logical view foreach user group



Provides acomparative view ofresources neededby each user group



Does not imply aspecific physicalimplementation



ABBs required bythe user group canbe highlighted



ABBsnot

requiredby the user groupare not highlighted

80

User Group View Analysis Process

USFI User

Communities

Application

Inventory

Application Systems

User Groups

USFI

ABBs

Applications by User Groups

ABBs by Application

ABBs by User Groups











81

User Group View Analysis

Relevancy:

User group view analysis identifies unique collections of ABBs that may be linked to specific groups ofsimilar users. The linkage between ABB set and user group permits identification of user groups that may beaffected by an ABB change.

Analysis:ABB dependencies may be identified for specific USFI user group views.

Recommendations:

The relationship between ABB usage and individual users, user groups, applications, orapplication sets may be driven to any level of detail.

We recommend that the following activities are considered to catalog ABB usage:

Identify which application systems are used by each of the user groups.

4.

Identify which of the ABBs are used for each application system.

5.

Associate each user group with a set of ABBs.

This level of analysis will link users to applications and applications to ABBs, and provide an indirect link betweenusers and ABB usage. Sensitivity to ABB changes can be determined for both the application and user sets.

Resources:

Suggested user groupings and application system categories are shown on the following page. Alsoincluded is a user view template that may be used to represent the results of future ABB usage analysis at theapplication and user level.

Architecture Building Blocks are modular components with which the architecture conceptual andlogical views are developed. Each building block represents a discrete functional requirementneeded to meet business IT requirements. Many building blocks will map one-to-one with aproduct solution. Others will be implemented in different ways depending on the platform (e.g., onone platform it may be a part of the operating system and on another, part of an add-on product).The Architecture Building Blocks are specified in accordance with the IT Architecture principles.

Please refer to the Appendix for the ABB listings presented in report sequence and sorted byclassification and priority.

86

Application Enabling Services

Presentation Services

Human Computer Interaction

Network Printing

Desktop Printing

High Speed Printing

View Document

Multimedia

Web Browser

Application Development Tools

S/390 Server Tools

AIX Server Tools

Sequent Server Tools

Sun Server Tools

OS/2 Server Tools

NT Server Tools

Personal Productivity Tools

Application Services

Transaction Monitor

Event Services

Intelligent Agent Management

Workflow

Mail

Collaboration

Telephony

Digital Library

Electronic Data Interchange

Application Server Middleware

USFI Middleware Components

Utilities

Data Access Services

Relational Database

Data Access Services(continued)

Hierarchical Database

Object-Oriented Database

Persistence Services

File (non-database)

Storage Management

Meta-data Repository

Distributed Systems Services

Communication Services

Conversation Communication Model

Remote Procedure Call Model

Message Queuing Model

HTTP

Object Management Services

Object Request Broker

Life Cycle

Externalization

Collections

Enterprise Object Repository

Distribution Services

Directory

Transaction Manager

Time

Network Services

Transport Services

TCP/IP

SNA

NetBIOS

IPX

APPN

Binary Synchronous

Asynchronous Communication

Uscardxx Financial Services Architecture Building Blocks

87

Network Services(continued)

Transport Protocol

ATM

Ethernet

Token Ring

Fiber Connection

Frame Relay

SONET

ESCON

Fiber Channel Extension

Transmission Technology

LAN

WAN

Wireless Network

Physical Equipment

Network Platform

Gateway Server

Intelligent Hub/Switching Hub

Multiplexer

Remote LAN Access Server

Router

Network Interface Card

Firewall

Cryptographic Devices

Front End Processor (FEP)

Proxy Server

Computing Platform

Enterprise Server

Mid-tier Server

Distributed Server

Computing Platform(continued)

Individual Desktop

Laptop/Portable Computer

Network Computer

Non-programmable Terminal

DASD

FAX

Optical Storage

CDROM

High/Low Speed Printer

Plotter and Scanner

Tape

Portable Hand-held Computer

Voice Response Unit

Automatic Dialer

Operating Systems

Enterprise Server

Mid-tier Server

Distributed Server

Desktop/Laptop Workstation

Systems Management

Problem Management

Change Management

Operations Management

Performance Management and CapacityPlanning

Configuration Management

Event Monitoring

Software Distribution

End User Support

Security

Uscardxx Financial Services Architecture Building Blocks(continued)

88

Architecture Building Blocks Template

Class:

Category:

Description:Description of the Architecture Building Block (ABB)

Future Direction:Planned technology for the next 3 to 5 years

Current Implementation:Installed technology in use today. Used to evaluate the currentenvironment

Gap/Transition:Describes the differences between the current and target architectures. Identify theimplications of the gap and factors affecting the transition from the current to the future environment.Describe those activities which must be completed to provide a smooth and effective transition.

Classification:

Strategic-

ITA industry standard, preferred, recommended and should be used

Tactical-

Point solution requiring variance (E.G. project driven)

Legacy-

Future investment, sunset target

Non-Strategic-

Industry standard but not strategic

Non-Standard-

Not in the architecture

Transition Priority:

High

Needed within one year

Medium

Needed within one to three years

Low

Needed within three to five years

89

Application Enabling Building Blocks

ApplicationsandApplicationEnablingServices

Distributed

Systems

Services

NetworkServices

90

Presentation Services define the mechanisms for interaction between applications and usersincluding the following components:

Human Computer Interaction

Network Printing

Desktop Printing

High Speed Printing

View Document

Multimedia

Web Browser

Presentation Services Building Blocks

91

Human Computer Interaction

Class:ApplicationCategory:Presentation Services

Description:The Human Computer Interaction (HCI) resource manager, with its associated technologies, supportsthe presentation of application and operating system information to end users. The term human computer interactiondescribes the front-of-screen appearance and function of an application or system, along with the mechanisms forthe interaction between the person and the computer system. This does not imply uniformity between applications,which must be established by separate standards. Examples include Windows, OS/2 PM, Motif, OpenGL, XWindow Xlib, X Window Xt intrinsics, and X Window System Protocols.

Current Implementation:The following standards and API interfaces are used to present information to the endusers: OS/2 PM, Sun Swing, 3270 text mode in an emulator session, HTML, Windows 95/98 for purchasedapplications, Win NT, Remote Management Distribution Services (RMDS), and Macintosh.

Swing will be the standard interface for Java-based applications on Sun and NT platforms.

Will replace 3270 text with Java or GUI depending on the application and platform.

HTML will be considered when application flexibility and accessibility is required.

Win NT will be a standard platform for Java-based applications.

Win 95/98 will be used to support purchased applications and but is not a USFI development platform.

Macintosh interface will continue to be used for niche application areas.

Gap/Transition:Need to complete the assessment of requirements and activities necessary to eliminate OS/2 PM.

Sun Swing, HTML, Win NT

Classification:Strategic

Transition Priority:Medium

Win 95/98

Classification:Tactical

Transition Priority:Medium

3270 Text, Macintosh

Classification:Tactical

Transition Priority:Low

OS/2 PM

Classification:Legacy

Transition Priority:Medium

92

Network Printing

Class:ApplicationCategory:Presentation Services

Description:The Print resource manager supports an extensive set of end user functions to submit and control printjobs. An end user or application can locate and query printers based on attribute values. The end user can viewqueues, track the progress of print jobs, and receive notification when jobs have completed or failed. Standardsinclude data streams such as PostScript and HPPCL.

Current Implementation:LAN attached printers are configured to dynamically accept both HPPCL and PostScriptdata streams. Approximately 75% of the print data streams are HPPCL and 25% PostScript.

PostScript is required to support document interchange within USFI and with external trading partners.

Future Direction:Both printing standards, HPPCL and PostScript, will continue to be supported with no definedpreference.

Gap/Transition:No transition activity is identified.

Classification:Strategic

Transition Priority:Low

93

Desktop Printing

Class:ApplicationCategory:Presentation Services

Description:Desktop printing provides facilities to print from the user’s workstation to a printer directly attached to theworkstation by a cable. Although locally attached printers may be shared by other users on the network, theworkstation to which it is attached controls access to the printer. The print standards include data streams such asPostScript and HPPCL.

Current Implementation:

Locally attached desktop printers are configured to support both HPPCL and PostScriptdata streams. Approximately 75% of the print data streams are HPPCL and 25% PostScript.

PostScript is required to support document interchange within USFI and with external trading partners.

Future Direction:Both printing standards, HPPCL and PostScript, will continue to be supported with no definedpreference.

Gap/Transition:No transition activity is identified.

Classification:Strategic

Transition Priority:Low

94

High Speed Printing

Class:ApplicationCategory:Presentation Services

Description:High speed printing is the means of printing a high volume of output within a short amount of time. Anend user or application can control printer functions based on selected attribute values. End users have the ability to