34
Enterprise Architecture Planning (EAP) Administrative Computing Services 12/17/2002

Departmental Report 12/2002

  • Upload
    aamir97

  • View
    184

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Departmental Report 12/2002

Enterprise ArchitecturePlanning

(EAP)

Administrative Computing Services12/17/2002

Page 2: Departmental Report 12/2002

Dec 17, 2002 2

Topics

• What is Enterprise Architecture Planning (EAP)?

• What is an EA used for?

• Why should we do it?

Page 3: Departmental Report 12/2002

Dec 17, 2002 3

A comprehensive blueprint of an organization by which we analyze and plan changes and make additions.

The structure of (Enterprise) components and their relationships, as well as principles and guidelines governing their evolution over time.

A common understanding, of the names and definitions of our organization’s entities.

MOST IMPORTANTLY: THE MODELS

... We need to build a new application…What do we have already in place? Impact?

What is an Enterprise Architecture?

Page 4: Departmental Report 12/2002

Dec 17, 2002 4

The EA is a strategic asset repository which defines the current and target architecture environments, including:

•the business (processes),

•the information (data or entities),

•the technology, and

•the transitional processes that keeps all aligned.

Emphasis on Logical, not Technological…Technology will always change

Beware of Protocol Gas!

What is an Enterprise Architecture?

Source: Federal Conceptual Architecture model

Page 5: Departmental Report 12/2002

Dec 17, 2002 5

Example: Technical Blueprint

Page 6: Departmental Report 12/2002

Dec 17, 2002 6

Example: Organizational Data/Entities

Page 7: Departmental Report 12/2002

Dec 17, 2002 7

Example: Organizational Data Attributes

Page 8: Departmental Report 12/2002

Dec 17, 2002 8

EAP Consists of...

•A standard methodology

•A standard framework

•A standard set of templates

•A repository

•A change management process

Page 9: Departmental Report 12/2002

Dec 17, 2002 9

Methodology adopted: “Guiding Principles”

•Conceptual Guiding Principles for all Architecture Domains •Specific Domain Architecture Guiding Principles

Commercial-Off-The-Shelf SolutionsDeveloped ApplicationsMiddlewareNetworkPlatformsSecurityDatabasesOperations Management

Page 10: Departmental Report 12/2002

Dec 17, 2002 10

Adopted “Sliding Window” Technology Change Management Methodology

•Matrix for a 4-year, 16-quarter sliding window within which the various recommendations for the Specific Domain Architectures are documented.

•Document which components should be researched, piloted, invested in, maintained but not upgraded, disinvested, obsoleted, and rejected.

•Planning Architecture Governance and Change Management Procedures

Page 11: Departmental Report 12/2002

Dec 17, 2002 11

Adopted Baseline Reference Technology

•J2EE

•XML

•LDAP Directory

•Business Portal (uPortal) as application development and integration framework

Page 12: Departmental Report 12/2002

Dec 17, 2002 12

Adopted Zachman’s Framework for Information Systems Architecture

Page 13: Departmental Report 12/2002

Dec 17, 2002 13

Topics

What is Enterprise Architecture Planning (EAP)?

• What is an EA used for?

• Why should we do it?

Page 14: Departmental Report 12/2002

Dec 17, 2002 14

•Investment decisions, vendor selection

•Modeling

•Analysis

•Requirements definition

•Planning

•Describing, understanding, and communicating

What is an EA used for?

Page 15: Departmental Report 12/2002

Dec 17, 2002 15

What is an EA used for?

• Promote interoperable and cost-effective systems

• Provide the rules, guidance and governance for buying or developing systems and managing change

• Ensure a common denominator for understanding, describing, comparing, and integrating systems

• Provide a mechanism for managing complexity.

Page 16: Departmental Report 12/2002

Dec 17, 2002 16

Architecture Defines the Transitional Roadmap

Source: Federal Conceptual Architecture model

Page 17: Departmental Report 12/2002

Dec 17, 2002 17

Topics

What is Enterprise Architecture Planning (EAP)?

What is an EA used for?

• Why should we do it?

•Too much work!

•Too difficult!

•Too many deadlines!

Page 18: Departmental Report 12/2002

Dec 17, 2002 18

Non-optimum HRIS Situation

DATA

ApplicantTracking

DATA

Staffing Management( Job Description

, , Builder QuickRec)FastClass

Employee Evaluation

DATA

Training.Mgmt

DATA

Payroll

DATA

Budgeting

DATA

Page 19: Departmental Report 12/2002

Dec 17, 2002 19

CompetencyModeling

Staffing Management( Job Description

, , Builder QuickRec)FastClass

Optimum Situation

EmployeeEvaluation

TrainingMgmt.

Payroll

ApplicantTracking

Budgeting

DATA

Integrated Systems and Data

Page 20: Departmental Report 12/2002

Dec 17, 2002 20

Non-optimum Payquest

Billing Agency

Info

AdComPayquest

Billing Agency

Info

Gastroenterology

Pediatrics

Billing

Agency Info

Page 21: Departmental Report 12/2002

Dec 17, 2002 21

CompetencyModeling

Gastroenterology

Optimum Payquest Situation

TrainingMgmt.

Pediatrics

AdCom Payquest

Any department

Billing Agency Info in LDAP Directory

Integrated Data and Access Control

Eudora

Any LDAP compliant software( , , DralaWorkflow uPortal

)Expresso

Page 22: Departmental Report 12/2002

Dec 17, 2002 22

Present “Stovepipes”

Source: Federal Conceptual Architecture model

Page 23: Departmental Report 12/2002

Dec 17, 2002 23

Desired State

Source: Federal Conceptual Architecture model

Page 24: Departmental Report 12/2002

Dec 17, 2002 24

Target

Source: Federal Conceptual Architecture model

Page 25: Departmental Report 12/2002

Dec 17, 2002 25

How do we get to the Target?

• Understand our challenges, goals and “Guiding Principles”.

• Apply and maintain “16-quarter Sliding Window” technology management Matrix for Domain Architectures (Security, COTS, etc).

• Build in Reference Technology (J2EE, XML, LDAP, Portal)

• Populate Zachman Framework Row 1 - the Planner’s perspective.

• Work with our business units to populate Zachman Framework Row 2 - the “Stakeholder’s” perspective (business models).

• Understand where we take “shortcuts”, why, and for how long.

• Plan, organize and commit.

• Communicate.

Page 26: Departmental Report 12/2002

Dec 17, 2002 26

•Applications in different technologies•Redundant code, redundant data with multiple uses•Redundant security, user/group management •30 year old systems•Alignment with business needs not timely•Data quality issues•Costly integration•Customized development of application instead of

assembly from “parts” •Funding (State Budgets depend on explicit EAP ) •Projects done without architecture planning cost

significantly more in long term (John Zachman)•Without it, we can’t understand impact of change.

Why? Too much work! Impossible!

Page 27: Departmental Report 12/2002

Dec 17, 2002 27

Benefits to the Business of planned systems

• More responsive to customer’s needs

• Reduced data-entry costs

• Efficient systems maintenance means improved service.

• Architectures eliminate complex costly interfaces between incongruent systems

• Management decisions in all functional areas will be based on more accurate and timely data, leading to various improvements and cost-saving measures

• New systems are developed faster and at less cost due to common data, common code, and a shortened requirements phase

• Easier to evaluate and select vendor SW packages

Source: Enterprise Architecture PlanningSteven Spewak

Page 28: Departmental Report 12/2002

Dec 17, 2002 28

Conclusion

What is Enterprise Architecture Planning?

What is an EA used for?

Why should we do it?

MOST IMPORTANTLY: THE MODELS

... We need to build a new application…What do we have already in place? Impact?

Page 29: Departmental Report 12/2002

Dec 17, 2002 29

"You may think this is too much work…Or, it takes too long

And it costs too muchOr is too theoretical

Or too high riskOr too whatever.

However, if that’s your assessment…You can’t complain that

the systems aren’t “aligned” with the enterprise,orare inflexible,

or cost too much,or that vital information is not available,

or that the data you get isn’t any good, or too late,or you can’t change anything,

or that I/S is slow and unresponsive…and, I am here to tell you

Outsourcing isn’t going to fix the problem.Packages (in themselves) won’t fix the problem.

Decentralization won’t fix the problem.And, the Internet isn’t going to fix the problem.

No amount of money, Ortechnology is going to fix the problem!

It is NOT a technical problem, it is an ENTERPRISE problem.

Only ACTUAL WORK is going to fix the problem, and“Someday, you are going to wish you had all those models,

Enterprise wide,horizontally and vertically integrated,

at excruciating level of detail.”You might as well start working on them TODAY!!!

John Zachman

Zachman reflections on EA Planning

Page 30: Departmental Report 12/2002

Dec 17, 2002 30

Benefits

Facilitates information services that provide:

flexibilityinteroperabilityreliabilitysurvivabilityaffordabilitysustainabilityportability reusabilityadaptabilitycompatibility

Page 31: Departmental Report 12/2002

Dec 17, 2002 31

Business Benefits of EAP

• Focus on strategic use of technology for managing data as an asset

• Standard vocabulary facilitates communication and reduces inconsistency and data redundancy

• Documentation increases understanding of the business

• Models can be used to explain the business and assess the impact of business changes

• Decision making policies can be reviewed

• It allows for a comprehensive, objective and impartial approach

• The long range systems plan compliments the business plan

• It involves a feasible migration strategy with short term achievements

• It is easier to assess the benefits and impact of new systems and software

• It allows easier accommodation of dynamic business changes

• Management participation provides a business prospective, credibility, confidence

Source: Enterprise Architecture PlanningSteven Spewak

Page 32: Departmental Report 12/2002

Dec 17, 2002 32

PERSON PLACE THING EVENT CONCEPTCG MEMBER CG ORGANIZATION COAST GUARD ASSET MARITIME ACCIDENT REGULATIONAUXILIARIST NAVIGABLE WATERS ATON COASTAL INTRUSION LAWMARINER GOVERNMENT FACILITIES COMMERCIAL VESSEL RESPONSE ACTIVITIES STANDARDSRECREATIONAL BOATERS AIR RECREATIONAL BOAT ATON DISCREPENCY DIRECTIVECONTRACTORS BRIDGES PORT FACILITY PREVENTION ACTIVITIES PLANGOVERNMENT CONTACTS REGULATED MANUFACTURERS ICEBERG DEFENSE OPERATIONS MISSIONREGULATED MANUFACTURERS HAZARDOUS MATERIAL ACQUISITION LEGAL REQUIREMENTCASUALTY CUSTOMER ASSET SUPPORT OPERATIONS INTERNATIONAL AGREEMENT

BUDGET BUDGET BUILD POLITICSRADIO FREQUENCY SPECTRUM CASESUPPORT ASSETSTRAINING/EDUCATION PROGRAMSCASEMETA DATAFUNDS

Examples - Entities

Source: U.S. Coast Guard Information Architecture

A distinguishable - person - about which information is kept. place, thing, event, concept

Page 33: Departmental Report 12/2002

Dec 17, 2002 33

Work involved...

• Refine goals, objective, principles

• Establish membership

• Identify a methodology

• Identify a framework

• Identify resources

• Define deliverables

• Refine timeline

Page 34: Departmental Report 12/2002

Dec 17, 2002 34

Technical Reference Model - A common framework, probably conceptual, todefine a common vocabulary so as to better develop and aquire some level ofsupport. It would provide you with a representation of the domain showingcommonality and integration and interoperability.

Common Operating Environment - The set of capabilities that would allow youto address the suite of integration products that you need to ensure acohesive framework of systems for development. Like the DII COE addressarchitecture, standards, software reuse, shared data, interoperability,portability, configuration management and integration.

Standards Roadmap - It would start with a common set of mandatory standardsand guidelines. It would then be tailored to the development that wasbeing implemented. So it would be the "building codes" that would bereviewed and selected to facilitate the development of the system orsystems needed to be built. (A Technical Architecture View for aparticular area (Defense Transportation System) starting from the DOD JointTechnical Architecture.)

Dick Webb, ASD(C3I)

Definitions - Miscellaneous