Uscardxx Financial Services, Incorporated

munchdrabΔίκτυα και Επικοινωνίες

30 Οκτ 2013 (πριν από 3 χρόνια και 10 μήνες)

199 εμφανίσεις


1

Uscardxx Financial Services,
Incorporated

Enterprise Information Technology
Architecture

The information provided in this document was collected and prepared by IBM Global Services during
engagement 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 or
implied, 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 an
enterprise
-
wide Architecture for USFI. An Architecture is a set of
principles

and
rules

for defining the
technical platforms on which to build systems and services.



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


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


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


I. Overview


11

Executive Summary

Future success requires a flexible and consistent Information Technology (IT) infrastructure planning process. The
infrastructure must accommodate rapidly changing business requirements and incorporate new technologies.


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 standard
interfaces to USFI information systems. The reference model and standards profile define the target technical
environment.


Within the context of information systems, a reference model is defined to be a generally accepted representation
that permits agreement on definitions, builds common understanding, and identifies issues for resolution. An IT
Architecture is necessary to establish a context for understanding how the various technologies required to
implement 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 and
acceptance 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 strategy
and objectives are used to define IT requirements. The IT Architecture guides the implementation of the technology
infrastructure to meet business needs. The IT Architecture considers a three to five year planning horizon. It is
revised at least annually to reflect changes in the requirements, environment, and technology. Tactical system and
application 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
-
5
yr..

Target

1
yr..

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 diverse
organizational areas within USFI can better coordinate the acquisition, development, and
support of information systems.



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



To provide a repository of information that permits consistent and timely technology
decision
-
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 and
change that includes:



implementing multi
-
tiered client
-
server systems


employing distributed application processing and communication techniques


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


The Business Technology organization responded by creating an Information Technology Architecture (ITA) to
improve 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 which
future IT decisions will be based.


Architecture Models

-

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


Evaluation Criteria

-

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


IT Architecture Management Process

-

the process which allows the architecture to evaluate and incorporate
new technology and respond to new business requirements. It is also the process by which unique
requirements 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 to
the 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 IT
Architecture promotes a consistent approach to system development and implementation, improves the sharing of
common IT resources, and maintains the flexibility required to respond to changing business requirements. The IT
Architecture 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 should
provide an objective foundation for making technical decisions, reduce the time required for each decision, and
improve the quality and consistency of such decisions. As USFI begins to exercise the architecture, it is expected
that 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 the
IT Strategy, Architecture Principles, and standards to the business units, the architecture can become an integral
part of the Business Technology management process. It will define an architecture model of the IT infrastructure
which will improve understanding of installed and planned systems and how they interact with each other in support
of users. By providing a repository for architecture information, this document should improve the common
understanding of many IT issues among the various decision making entities and improve the buy
-
in of the many
groups involved in each IT investment decision.


Less Complex Infrastructure Design

-

With the increased interrelationship of components in distributed IT
solutions, 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 support
costs, 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 functions
and services appear and behave in a similar, predictable fashion regardless of application or site. Integrated
applications will behave in a logically consistent manner across user environments. Databases are shared across
the organization in the context of security and operational considerations.


Increased Development Productivity

-

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


Reduced Deployment Times
-

The efficiency of development efforts will be improved by using packaged
applications, sharing resources, and reducing the amount of development. A standards
-
based environment that
accommodates new standards and technologies will promote component reuse. Off
-
the
-
shelf, industry standard
products can reduce dependence on custom development activities and reduce development and maintenance
costs. For those applications that must be custom developed, portable application design will reduce the amount of
software to be created and add to the inventory of software suitable for reuse by other systems. Technology
resources (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 toward
a common architecture, compatible skills will be developed across the organization which can be leveraged through
sharing and rapid redeployment. Transfers from one department to another will potentially require less retraining as
the systems and their user interfaces become more homogeneous. More time is spent honing existing skills than
developing 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 specific
environment and needs of USFI.


Each phase includes one or more activities as shown on the lower portion of the previous diagram and described on
the 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. This
activity may have been completed during the engagement planning phase, but has been kept here for
completeness.


Gather Current Status and Requirements


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


Analyze Requirements


Define clear architectural requirements. Create and document assumptions.


Develop Architecture Principles


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 select
components for the information technology architecture.


Assess Architecture Transition Plan


Analyze and create an outline of the key elements of the information technology environment that must
change 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 shown
on the following diagram, the major architecture components (principles, architecture building blocks, and evaluation
criteria) are developed to meet the specific environment and requirements of the business and Business Technology
organizations. 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 of
business and technology strategies. Technology principles must support the business objectives. Building blocks
must be supported by the technology principles. The evaluation criteria are designed to facilitate rational product
selection to implement one or more building blocks. Requirements and principles are input to the evaluation
process. Requirements and building blocks drive the creation of a transition plan to move from the current to the
future architecture state.


Relevancy of the architecture is ensured through communication of the current state and linkages between the
individual 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 the
functional business units. The IT Architecture, when properly aligned with the business objectives,
provides a framework for the deployment of technology resources that support the business
strategies 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 and
architecture.


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 and
architecture.


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 a
cross
-
section of the management staff. The objectives focus on organization strength, service
quality, 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 Information
Technology within USFI. Principles reflect a vision of improved ways to manage or use technology
to benefit the business. They describe preferred practices to be followed when implementing new or
upgraded 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 vision
of an improved Information Technology environment within which to develop and operate systems to
help 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 and
the 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 and
technology.


What will be controlled by the Business Technology organization, departments
or business units.


Use of proprietary and open architectures and standards.


Principles related to current conditions and future direction, not selection of
specific items.


The approach to decentralization of IT systems.


What part will be played by mainframes, mid
-
range systems, various servers
and client workstations. Where will they be located in relationship to one
another. How important is the WAN and LAN network in providing a unified
computing 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 written
sentences.


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 and
Business 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 were
considered.


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 a
technology.


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 organization
considerations affecting the implementation of Information Technology at USFI.


Organization and Management

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


Application/Application Development

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


Data

Questions of data management are addressed by the data principles.


Network

These principles describe factors affecting the network infrastructure.


Systems Management

The systems management disciplines are guided by these principles.


32

Principles by Categories

Guiding Principles (9)


IT Architecture Mandate


Architecture Characteristics


Planning for Obsolescence


IT Planning


Technology Risk


Technology Options


Selection Guidance


Technology Re
-
usability


Strategic Business Technology Partners


Organization and Management Principles (6)


Role of Technology


Role of Business Technology


Requirements Definition


Application/Technology Cost
-
Benefit Justification


Infrastructure Technology Justification


Research and Development


Application/Application Development
Principles (12)


Application Solutions Evaluation


Packaged Applications


Standard Development Methodologies


Standard Testing Methodologies


Buy vs. Build


Development Tool Selection Priority


Application Delivery Standard


Application Architecture


Design for Growth


Programming Style


Application/System Readiness


Training


Data Principles (2)





Data Ownership


Data Architecture



Network Principles (3)


Network Accessibility


Data Accessibility on the Network


Network Management


Systems Management Principles (6)


Systems Management Automation


Security Design


Service Level Objectives


Application Availability


Disaster Recovery


Systems Management Disciplines


33

Guiding Principle

1. IT Architecture Mandate

Deployment of IT components and processes by Business Technology departments and
business units will conform to the Enterprise IT Architecture.


Motivation


Provide consistency across the enterprise.


Facilitate change.


Reduce cost by re
-
using existing technologies.


Provide shared, common knowledge of USFI technology components.


Improve personnel resource utilization and flexibility of work assignments .


Impact


Must implement processes and procedures that minimize additional bureaucracy.


May limit flexibility in selecting IT solutions.


IT Architecture must be embraced by both Business Technology department and business
units .


Business Technology and the business units must formalize the communication processes
based on the importance of the information to be communicated.


34

Guiding Principle

2. Architecture Characteristics

The IT Architecture will be developed to provide consistency of solutions, service, and
support across all business units.


Motivation


Need consistent and cost
-
efficient solutions that are integrated across business units.


Desire a framework to design and deploy technology solutions.


Impact


Must define the IT Architecture and communicate it across the enterprise.


The IT Architecture provides a starting point for technology solution design or selection but
must provide some flexibility of choice.


35

Guiding Principle

3. Planning for Obsolescence

Business Technology will assess and plan for technology obsolescence considering
technology life cycles when selecting solutions to meet business requirements.


Motivation


Save costs by implementing solutions with a useful life span that closely matches the needs
of the business function.


Impact


Need to define “useful life” for hardware and software.


Must be aware of the USFI financial goals and business needs.


Must consider both the complete application system and its components.


Need to establish methods, guidelines, and checklists to ensure technology solutions are
current.



36

Guiding Principle

4. IT Planning

The strategic direction for IT is consistent with the corporate strategic plan.


Motivation


Align IT with corporate planning.


Impact


Business Technology must know and understand corporate goals and strategic plan.


Business Technology planning cycle must be coordinated with corporate plan.




37

Guiding Principle

5. Technology Risk


Application development/implementation techniques and product selection will be guided
by the objective to use proven technologies.


Motivation


Minimize risk associated with application deployment.


Impact


Must be prepared to use “leading edge” technologies to maintain competitive advantage.


Need for quick application turnaround may increase risk.


Exception processes must be defined and implemented.


Must define “proven” and “leading edge” technologies.



38

Guiding Principle

6. Technology Options

The IT Architecture may identify multiple alternative solutions, products, or methodologies
for any technology component with guidelines for the selection of each alternative


Motivation


Use multiple, competing technologies to offer alternatives to application/system designers.


Impact


Must define selection guidelines for each component.


Supporting multiple alternative technologies is more difficult and may require additional
resources.



39

Guiding Principle

7. Selection Guidance

In order of general importance, USFI will seek to select technology solutions that 1) provide
the 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 they
satisfy 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 including
documentation of component function and design.


Change management techniques must be applied to reusable components to ensure future
reusability.


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 our
vendors.


We expect to maintain an extended commitment with our strategic partners.


USFI should leverage the investment in skills to manage an extended vendor workforce.


The effectiveness of a vendor relationship depends on adoption of our architecture, culture, and
goals by each strategic partner.


Complacency in strategic partner relationships must be avoided.


We should consider outsourcing to vendors when it permits us to increase management and
resource focus on USFI core competencies.


Impact


Inventory our partner relationships to identify and evaluate the core competencies of each.


Define the list of strategic partners that are best able to serve our needs through their
competencies


Identify a select subset of providers for each technology requirement.


Communicate our architecture, culture, and goals to every strategic Business Technology
partner.


Periodically review our strategic partner relationships to refresh and update the list.


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 adaptation
to 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 technology
solution.


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 provide
the most business benefit.


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


Impact



A planning methodology must be created that integrates business and technology processes
and 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 with
assistance from Business Technology; Business Technology will implement the new
applications 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 the
business.


Impact


The IT Architecture must be communicated throughout the Business Technology and
business 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, justifying
and gaining approval for IT costs, and managing the benefits. Business and Business
Technology will collaborate to complete a cost/benefit analysis.


Motivation


Business Technology should be viewed as a consultative development partner to the
business units.


Business units are in the best position to justify new application expenditures and quantify
expected benefits.


Impact


Business units must communicate expected benefits and attainment objectives to Business
Technology.


Business units must not dictate technology direction.


46

Organization and Management Principle

14. Infrastructure Technology Justification

Information Systems is responsible for justification analysis of technology components
considering the corporate
-
wide cost to implement and support each component over the
expected 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 by
an "R & D" function that coordinates and communicates evaluation activities across the
enterprise.



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 or
Business 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 Technology
has the responsibility to provide the criteria used to make the evaluation, the evaluation
results, and the trade
-
offs that may result for each alternative solution.


Motivation


Protect the integrity of existing application/systems when making changes to accommodate
a new application.


Maintain and improve the flexibility of application systems.


Ensure that the business unit can make an informed decision concerning an application
solution alternative.


Impact


Business Technology must develop a list of evaluation criteria (ex. cost, time to implement,
function attainment, integrity, etc).


Business Technology must use the criteria to evaluate application solution alternatives,
document the results, and provide the evaluation results to the business unit.


Impacts for each potential trade
-
off must be identified and documented by Business
Technology and provided to the business unit decision
-
maker.


49

Application/Application Development Principle

17. Packaged Applications

Business Technology will actively lead the selection, implementation, and support of packaged
business application solutions to meet specific business requirements.



Motivation


Business Technology and the business units should work together to identify the package
application solution that balances both technology and functional requirements.


Impact


Business Technology has the responsibility to find workable solutions to meet business
requirements.


Business Technology must completely understand business requirements.


50

Application/Application Development Principle

18. Standard Development Methodologies

All new systems being purchased or developed will employ USFI standard methodologies
and products to achieve the desired business function.


Motivation


Standardize on a proven set of technology methods and components.


Impact


The IT Architecture must identify the USFI standard methodologies and preferred products to
be used for system solutions.



51

Application/Application Development Principle

19. Standard Testing Methodologies

Defined industry
-
standard test methodologies will be used to validate the function of all
new systems being purchased or developed.


Motivation



Ensure error
-
free code is installed into production to minimize the cost of production
problems.


Standardize the methods for testing all new applications to avoid rework, errors, and
dissatisfaction after implementation.


Separate test and production activities to avoid unplanned production impacts.


Impact


Application installation must use the structured testing processes that have been selected.


Appropriate testing tools must be selected and implemented.


Must deploy a network and computing platform infrastructure that permits isolation of
development, testing, and production.


52

Application/Application Development Principle

20. Buy vs. Build

All new application/systems will be first evaluated for purchase. Applications that provide
competitive advantage should be considered for development.


Motivation


Maximize competitive position.


Reduce cost and delivery time of new application/systems.


Impact


Need to define a methodology that can be used to validate what constitutes competitive
advantage.


Need evaluation criteria and consistent process that can be used to evaluate vendor
application packages.


Must consider the adherence of the vendor application package to the USFI IT Architecture.


53

Application/Application Development Principle

21. Development Tool Selection Priority

Development tool selection will give priority to products that meet functional requirements
and improve programmer productivity.


Motivation


Reduce application development/maintenance costs.


Impact


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 their
desktop 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 hardware
inventory.


A standard desktop configuration must be identified.


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


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 USFI
developed 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 the
customization 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 and
technologies 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 the
planning 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 to
maximize potential re
-
use.


Motivation


Maximize re
-
use potential of code modules.


Impact


Must create and maintain an inventory and catalog of re
-
usable components including
component documentation.


New components must be designed for potential re
-
use.


A well
-
defined application architecture and standard development tools are a pre
-
requisite for
an effective re
-
use strategy.


The current owner of each re
-
usable component must be identified.


58

Application/Application Development Principle

26. Application/System Readiness

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



Motivation


Business unit is responsible for completing acceptance testing.


Business Technology is responsible for correcting acceptance testing anomalies.


Impact


Business Technology will make the application/system available to the business partner for
testing when Business Technology determines that the application/system is ready.


Business and Business Technology will collaborate to evaluate the risk of implementing the
application/system.


Integration testing of the application/system by Business Technology is a pre
-
requisite to the
readiness designation.


Business Technology initiated projects must be communicated to the affected business
units and conform to the readiness process.


59

Application/Application Development Principle

27. Training

Business units are responsible for providing end user training.


Motivation


End
-
user training for a new application is the responsibility of the business unit sponsoring
the application.


Impact


Business Technology must provide train
-
the
-
trainer sessions for the business unit.


System documentation must be completed prior to training deployment.


Business Technology and business units must define the requirements and implement a
consistent environment for application end
-
user education that supports both classroom and
desktop delivery.


60

Data Principle

28. Data Ownership

All primary data will be owned by the business unit and managed by Business Technology.


Motivation


Access to data is controlled from a central site with ownership distributed to the business
unit.


Impact


Data accuracy is a business unit responsibility.


Data integrity is a Business Technology responsibility.


Business unit must communicate security and access level assignments to Business
Technology.


Business Technology creates the data model and maintains the security control
mechanisms.


61

Data Principle

29. Data Architecture

The Data Architecture will determine the appropriate placement, storage medium, usage
rules, protection, and accessibility of operational and analytical/query data.


Motivation


Maximize access to corporate data across the enterprise.


Facilitate an appropriate level of data sharing across the enterprise.


Ensure data security.


Impact


The USFI Data Architecture must be created and deployed.


The Data Architecture must consider data usage, service level requirements, and data
security.



62

Network Principle

30. Network Accessibility

The network infrastructure will be used to provide secure access for authorized internal and
external users.


Motivation


Provide access to corporate information by both internal and external users.


Provide access to employees and non
-
employees.


Impact


Business Technology must be provided the identity of authorized users.


Appropriate security methods must be deployed.


The security process must support data release for direct access by authorized users.


The network design must support access with sufficient capacity for external users.


63

Network Principle

31. Data Accessibility on the Network

The network will enable access to computer
-
based information without limitation by the
location of the resource.


Motivation


Increase accessibility to corporate data.


Extend data access to remote users.


Impact


The physical network design must accommodate any
-
to
-
any resource connectivity.


Additional network redundancy is required.


Centralized network management must be implemented.


64

Network Principle

32. Network Management

The network resources will be consistently managed end
-
to
-
end using standard protocols.


Motivation


Improve network service levels.


Impact


The network must be constructed from a consistent, reliable, manageable set of
components.


Network hardware and management software must be carefully matched.


End
-
to
-
end network standards must be identified.


Standardization may limit the selection of components.


65

Systems Management Principle

33. Systems Management Automation

System management functions will be automated where practical across the infrastructure.


Motivation


Reduce support costs by automating systems management activities when feasible.


Impact


Product selection must consider automation capabilities.


Initial costs for an automation
-
capable component may be higher.


66

Systems Management Principle

34. Security Design

Security facilities must be comprehensive, comply with corporate security guidelines, and
enable the enterprise to protect its assets from deliberate or accidental misuse.


Motivation


Security measures are integral to all applications.


Consistent security methods must be implemented.


Impact


USFI Architectures must include security methods.


The office of the DSFI security officer must define and communicate security policies, practices,
and standards.


67

Systems Management Principle

35. Service Level Objectives

Service level objectives and agreements will be defined and established for each
application/system.


Motivation


Establishing objectives based on value of business function.


Impact


A realistic and rational service level objective must be defined for each application system.


System and application monitoring facilities must be implemented at an appropriate level of
capability.


Individual service level agreements must be negotiated with each business unit.


Measurement methods must be created to report service level attainment by
application/system.


68

Systems Management Principle

36. Application Availability

Application systems will be available to the end
-
user on a “near” 24 by 7 schedule.


Motivation


Provide a balance between operating complexity and application availability.


True 24 by 7 is costly to achieve.


Impact


Availability may vary by the usage category of the application.


Application availability must be coordinated across systems.



69

Systems Management Principle

37. Disaster Recovery

Hardware, software, and network configurations of each regional computing site will be
designed to provide disaster backup for other regional sites.


Motivation


Use existing resources to provide backup capabilities.


Impact


Backup/recovery plans must be centrally coordinated across the enterprise.


Recovery speed may be negatively impacted.


Site design, network configuration, and capacity plans must consider backup/recovery
requirements.


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 for
each 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 a
necessity to maintain the effectiveness and availability of the IT infrastructure

Impact


Appropriate systems management processes and techniques must be selected and
deployed.


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 the
IT Architecture and provide a framework within which it can be implemented. The architecture model
provides 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 blocks
required to meet the defined IT business requirements.


The
Conceptual Model

consists of four primary focus areas. The
Applications and Applications
Enabling Services

components define the disciplines and processes required to develop and deliver
business systems to the end user. The
Distributed Systems Services

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

defines the communication capabilities required to meet business needs. Finally,
Physical Equipment

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


The
Logical User Views

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


The
Network View

offers a high level view of the components of the network needed to connect the
many 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 may
include adding, deleting, or changing building blocks. Changes are reviewed and approved through the Architecture
Management Process described in this document.


74

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


Defines common functional building blocks
and interfaces for distributed computing


Depicts functions and shows relationship
to other components


Functions are grouped into logical entities


Leads to modular, scalable systems that
are easy to grow and enhance


Provides a vocabulary and context in
which to discuss and organize technology
issues


Presents a pictorial representation to help
make the architecture visible and tangible


75

Architecture Modeling Process

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

Conceptual

Model

Level Zero

Conceptual

Model

Level One

Level One

User Views

Logical

Models

Distribution of ABBs based on
business characteristics and
need to share function, data,
and technology

An image constructed of
application building blocks

to represent all functions in
the architecture


Level Zero ABBs: Unique building blocks;
reusable modular function; ignores users,
locations, platforms


Level One ABBs: Specific functions; may vary
by location, topology, user


Level One User Views: Subset of Level One
ABBs by user group; ensures ABBs are
complete


Logical Models: ABB collections based on
sharing rules, functional similarity,intended
usage

Note:

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 Technology
business 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 a
specific user group



Applications

and

Application

Enabling

Services

Distributed

Systems

Services

Network

Services


77

Architecture Conceptual Model
-

Overall view of the target IT
environment

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 to
their 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 agreement
with the USFI Architecture management department.

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


79

Logical User View
-

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



All USFI
Architecture Building
Blocks are
represented



One logical view for
each user group



Provides a
comparative view of
resources needed
by each user group



Does not imply a
specific physical
implementation



ABBs required by
the user group can
be highlighted



ABBs
not

required
by the user group
are 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 of
similar users. The linkage between ABB set and user group permits identification of user groups that may be
affected 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, or
application sets may be driven to any level of detail.


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


1.

Define relevant groupings of IT users (approximately 10 to 15).

2.

Create a list of significant USFI application systems (approximately 15 to 35).

3.

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 between
users 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. Also
included is a user view template that may be used to represent the results of future ABB usage analysis at the
application and user level.


82

Potential User Groups and Application Categories

User Groups (potential)



Cardmember Operations


Cardmember Telesales


Merchant Operations


Marketing


Risk Management


Sales Representatives


Information Systems

Application Categories (potential)



Finance and Accounting


Cardmember Acquisition


Embossing


Cardmember Products


Risk Analysis


CPB


Statements


Customer Services


Collections


Authorizations


Merchant Acquisition


Merchant Services


Sales and Marketing


83

User Group View Template


84

Network View

The Network View presents a
long
-
term (3
-
5 year) vision of
components that will are
expected to provide USFI with
the required communication
network infrastructure. Some
building blocks, although not
strategic, may remain in use to
provide required functions.


85

V. Architecture Building Blocks

Architecture Building Blocks are modular components with which the architecture conceptual and
logical views are developed. Each building block represents a discrete functional requirement
needed to meet business IT requirements. Many building blocks will map one
-
to
-
one with a
product solution. Others will be implemented in different ways depending on the platform (e.g., on
one 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 by
classification 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 Capacity
Planning


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 current
environment

Gap/Transition:
Describes the differences between the current and target architectures. Identify the
implications 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

Applications
and
Application
Enabling
Services

Distributed

Systems

Services

Network
Services


90

Presentation Services define the mechanisms for interaction between applications and users
including 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:
Application
Category:
Presentation Services

Description:
The Human Computer Interaction (HCI) resource manager, with its associated technologies, supports
the presentation of application and operating system information to end users. The term human computer interaction
describes the front
-
of
-
screen appearance and function of an application or system, along with the mechanisms for
the 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, X
Window 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 end
users: OS/2 PM, Sun Swing, 3270 text mode in an emulator session, HTML, Windows 95/98 for purchased
applications, Win NT, Remote Management Distribution Services (RMDS), and Macintosh.


Future Direction:
Will replace OS/2 PM interface with Sun Swing, NT, or HTML depending on application platform.

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:
Application
Category:
Presentation Services

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

Current Implementation:
LAN attached printers are configured to dynamically accept both HPPCL and PostScript
data 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 defined
preference.

Gap/Transition:
No transition activity is identified.

Classification:
Strategic



Transition Priority:
Low


93

Desktop Printing

Class:
Application
Category:
Presentation Services

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


Current Implementation:

Locally attached desktop printers are configured to support both HPPCL and PostScript
data 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 defined
preference.

Gap/Transition:
No transition activity is identified.

Classification:
Strategic



Transition Priority:
Low


94

High Speed Printing

Class:
Application
Category:
Presentation Services

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