EA View Framework

A Framework to View an Enterprise’s Architecture

(EA View Framework)

Attachment to

Enterprise Architecture Management Guide

Chapter 5: EA Designs

(V 1.0. Last Updated on 10/29/2006, by Haiping Luo)

Table of Contents

1. Introduction of an EA View Framework2. The Basics3. Overall Structure4. Integrity Rules5. Viewing an Architecture from 5

Management Perspectives6. EA Continuums7. Other EA Views8. Architecture Optimization9. Summary

1. Introduction•This attachment introduces an EA View Framework to organize architectural designs and to implement architectural integrity.

• The key value of the EA View Framework is to link designs with the end result, i.e., using the designs to improve specific managements, throughout the designing process. •The EA View Framework extracts strengths from multiple frameworks, such as Zachman Framework, GERAM, TOGAF Framework, FEAF, DODAF, NGOSS, and EA Cube, to establish design integrity, to connect designs with their management purposes and outcomes, and to coordinate designs with EA information models.

2. EA View Framework: the Basics

• Architectural components:– Element: the unique unit of things, people,

phenomena, etc., that plays a role(s) in the enterprise. Example: an organization, a policy, a product, a process. The enterprise itself is also an element that plays a role(s) in a bigger context(s).

– Module: A set of related elements that forms a self-contained portion and serves a function(s) in the architecture. Example: an information model, a solution architecture.

– Segment: A combination of elements, modules, and other segments that forms a coordination structure and supports a management domain. Example: a line-of-business process architecture, a security architecture.

Representation in the EA Information Model

……………………Entity

.……………Model Entity

…………………Grouping

2. EA View Framework: the Basics (cont.)

• Structuring materials

– Relationship: A type of connection between components.

– Interface: The point of interaction or communication between components.

– Exchange flow: The content being exchanged between components. Example: information, control, physical material, influence.

Representation in the EA Information Model

………..Relationship Entity

.…………Model Interface

……Exchange Information

2. EA View Framework: the Basics (cont.)

• Component’s features:

– Has a lifecycle and a life history.

– Has properties.

– Has relationships.

– Has states and conditions over time.

• Views: A presentation of a selected set of components’ instances, with a selected portion of their properties and relationships, in a selected state and condition, to display the characteristics of the architecture in a specific context or for a specific purpose.

Representation in the EA Information Model

…………Life Phase Attribute, Life Event Entity

……………………………………………Attribute

…………………………….Relationship instance

………State Attribute, Instance Version, Saved Query Result / Snapshot

.…………………………………Grouping, Query

3. EA View Framework: the Overall Structure

External Environment/Context

Line

of B

usin

ess

Architectural Segments

Level of Decom

position

Contextual

Conceptual

Logical

Physical

Operational

Direction of Aggregation

Range of Summation

3. EA View Framework: the Overall Structure (cont.)

The architecture can be viewed from 5 management perspectives corresponding to 5 enterprise management domain groups:

1. Strategic management perspective

2. Business management perspective

3. Resource management perspective

4. Risk management perspective

5. Electronic management perspective

The architecture can also be viewed over time:

- Current state of the architecture

- Target state of the architecture

- Transition states of the architecture

The architecture can be viewed from more viewpoints:

- Technology View, Operations View, Communication View, Control View, …

3. EA View Framework: the Overall Structure (cont.)

The architecture can be decomposed into levels, segments, specialty architectures, and other components.

Level of decomposition:

1. Contextual Level: this level turns external mandates, environmental factors, and internal strengths into strategic goals and plans for the domain in focus.

2. Conceptual Level: this level decomposes strategic goals and plans into objectives and management plans.

3. Logical Level: this level translates management plans into project or implementation plans and processes.

4. Physical Level: this level implements plans and processes.

5. Operational Level: this level carries out detail tasks and activities.

4. EA View Framework: Integrity Rules (examples)

•Regardless how to view, segment, or decompose, the architecture is a whole for an enterprise.

•Architectural components should exist independent of any EA framework and can be viewed in multiple frameworks.

•All management domains and their corresponding architectural components run across all decomposition levels and involve all segments.

•Each Line-of-Business segment contains components from all management domains and covers all decomposition levels.

•Every component of the architecture is affected by the enterprise’s environment and context. The environmental impacts received by components need to be addressed in the context of the enterprise.

•Decomposition and segmenting must support aggregation to higher levels and summation to the enterprise whole.

•Designs should pursue enterprise optima, not local optima.

•Changes to designs have to address their enterprise impacts before implementing.

5. Viewing an Enterprise Architecture from Five Management Perspectives

The designs of architectures need to support 5 enterprise management domain groups and can be viewed/evaluated from 5 perspectives.

Enterprise Management

Strategic Management domain group

Business Management domain group

Resource Managementdomain group

Risk Managementdomain group

Electronic Managementdomain group

achieved through management domain groups

Enterprise Architecture Views

Strategic Management Perspective

Resource Management Perspective

Risk Management Perspective

Electronic Management Perspective

takes management perspectives

supports

determines

Business Management Perspectivesupports

determines

supports

determines

supports

determines

supports

determines

5.1 EA View Framework:the Strategic Management Perspective

Environment/Context

e.g. program goals & plan

e.g. project portfolio

e.g. project goals & plans

Strategic Management Domains & architectural components (examples):•Goal management

•Goal mgmt processes•Organization management

•Org structure•Quality & Performance mgmt

•Performance mgmt structure & processes

•Resources management•Investment portfolio*

•Risk management•Risk mgmt structure*

•Electronic management•Management information systems*

Business Mgmt

Resources Mgmt

Risk Mgmt

Electronic. Mgmt

Links to other perspectives

Note: Items marked by * indicate cross-group components.

e.g. enterprise strategic plan

e.g. team and individual goals & performance plans

5.2 EA View Framework: the Business Management Perspective

Environment/Context

e.g. processes architecture

e.g. process’ implementations

Business Management Domains & architectural components (examples):•Line of business management

•Business plans*•Business processes

•Resources management•Supply chains*•Accounting processes*•Assets & equipment supplies*

•Partner management•Partner channels

•Customer relationship mgmt•Customer relationship types•Customer service processes

•Quality &Performance mgmt•Performance plans & processes*

•Risk management•Business continuity plan & processes*

•Electronic management•Automation & productivity tools*•Information mgmt structure*•Communication patterns*

Strategic Mgmt

Resource Mgmt

Risk Mgmt

Electronic. Mgmt

Links to other perspectives

e.g. task allocation and achievements

e.g. LoB. business plan

e.g. product line goals & plan

5.3 EA View Framework: the Resource Management Perspective

Environment/Context

e.g. investment projects

e.g. project financing

Resource Management Domains & architectural components (examples):•Financial management

•Financing processes and controls•Accounting processes and controls

•Assets management•Assets portfolio•Assets allocations

•Materials management•Inventory allocations•Supply chains

•Human resources mgmt•HR reservoir •HR processes

•Quality &Performance mgmt•Performance plans & processes*

•Risk management•Business continuity plan*•Compliance structure & processes*

•Electronic management•Automation & productivity tools*•Information mgmt structure*•Communication patterns*

Strategic Mgmt

Business Mgmt

Risk Mgmt

Electronic. Mgmt

Links to other perspectives

e.g. activity spending controls

e.g. investment goals

e.g. investment portfolio

5.4 EA View Framework: the Risk Management Perspective

Environment/Context

e.g. risk mgmt goals

e.g. business continuity plan

e.g. emergency process coordination

e.g. process implementations

Risk Management Domains & architectural components (examples):•Compliance management

•Compliance structure & processes

•Business continuity management•Business continuity processes

•Resources management•Emergency HR processes*•Emergency inventory, assets, & supply chains*

•Electronic management•Security architecture*•Automation tools*•Information mgmt structure*•Communication patterns*

•Quality &Performance mgmt•Performance plans & processes*

Strategic Mgmt

Business Mgmt

Resource Mgmt

Electronic. Mgmt

Links to other perspectives

e.g. incidents response operations

5.5 EA View Framework: the Electronic Management Perspective

Environment/Context

e.g. application architecture

e.g. solution architecture

e.g. development coordination

Electronic Management Domains & architectural components (example):•Information management

•Information architecture•Automation & Productivity mgmt

•Application architecture•Infrastructure management

•Network architecture•Telecommunication architecture

•Cyber security management•Security architecture*

•Technology management•Technology profile•Investment portfolio*•Technical standards

•Quality &Performance mgmt•Performance plans & processes*

Strategic Mgmt

Business Mgmt

Resource Mgmt

Risk Mgmt

Links to other perspectives

e.g. operations and services

e.g. automation goals

6. Various EA Continuums

Enterprise’s architectures form, and can be viewed as, various continuums:

•EA Time Continuum •EA Implementation Continuum•EA Specification Continuum

Implications: •The continuum characteristics represents the changes and connections among states and phases of architectural designs.• The continuums require EA information models to capture continuum characteristics, allow views by state or phase, and display the connections.

6.1 EA Continuums: View Over Time

Environment/ ContextLi

ne o

f Bus

ines

s

Contextual

Conceptual

Logical

Physical

Operational

Environment/ Context

Line

of B

usin

ess

Contextual

Conceptual

Logical

Physical

Operational

EA Mgmt & Change Path

Current State Target State

• Strategic Mgmt Perspective• Business Mgmt Perspective• Resource Mgmt Perspective• Risk Mgmt Perspective• Electronic Mgmt Perspective

Transition States

Enterprise Architecture Time Continuum

6.2 EA Continuums: Decomposition of Implementation

Enterprise Overall Architecture

Segment Architecturee.g. Engine Manufacture,

Military Command

Module Architecturee.g. Accounting,

Logistics

Component Architecture

EA

Imp

lemen

tation

Co

ntin

uu

m

Lin

e o

f A

ssem

bli

ng

6.2 EA Continuums: Decomposition of Component

Component Lifecycle

Identification

Concept

Requirements

Preliminary Design

Detailed Design

Implementation

Operation

Decommission

Component Aspect Categories Link to EA*

User Functions

/output

DataPeople

Control

Timing

Location

Infrastructure

Sec

urity

Quality

Technology

Perform

ance

Interfaces

Resources

•A component can be singular (an element) or composite (a module, a segment, or an enterprise).•The aspect categories link the component’s characteristics to enterprise architecture requirements.•All aspect categories are considered at every phase of the component lifecycle but with different emphases and different level of details.•The ring structure reflects order of consideration from core to outer layers, with user required functions being the beginning point.

*

6.3 EA Continuums: Generic to Specific

World of Empiria World of Theory

Object: Enterprise architectures

InformativeDescriptive research

Descriptive Theory ofgeneric architectures

Context: People, their values, beliefs, preferences

Design Theory ofGoal-oriented architectures

NormativeGeneral Studies

Enterprise-specific architecture design

Living architecture

Implementation

Architecture development project

NormativeEnterprise-specific

studies

EASpecificationContinuum

Note: The knowledge movement between empiria and theory is a continuous circle that may start at any point.

7. EA View Framework:Other Possible Views

An enterprise’s architecture can be viewed in more ways: •Process view •Technology view•Communication view•Control view•Compliance view•…

Implications:• The needs from analytics, design, decision support and management will drive for many views of the architecture. These views reflect a wide range of considerations that shape EA designs.• EA information models need to have the capability, flexibility and extensibility to allow many different views.

7.1 View Example: Implementation Width and Depth

External Environment/Context

Architectural Segments

e.g. Comm. tech. direction

e.g. Comm. tech. plans

e.g. Comm. tech. projects

e.g. Comm. tech. Implemented in hardware

e.g. Comm. Tech in operations

Direction f Aggregation

Range of Summation

A View of Communication Technology Implementations** The stages of implementations at different lines of business are marked by the ovals.

7.2 View Example: Process Flows

External Environment/Context

Architectural Segments

A View of a Cross-Segment Operation

8. EA View Framework:Architectural Optimization

An enterprise’s architecture should be optimized and evaluated qualitatively and quantitatively:

Implications:• The goal of EA designs is to identify the most suitable and feasible architecture for the enterprise in focus.• EA information models need to provide the ability to measure the quality and performance of an architecture.

• A qualitative evaluating system: Architectural Soundness Checklist

• A quantitative measuring system: Architectural Optimization Triple

8.2 A qualitative evaluating system: Architectural Soundness Checklist

• Suitability– The pattern by which elements are interrelated or arranged fits the type and purpose of the enterprise in

focus.– The functionalities of the structure support the functions and activities of the enterprise effectively.

• Integrity– Elements have compatible interfaces and exchange media to coordinate and interact with each other.– Elements support and supplement each other so the enterprise whole is better than the sum of individual

elements.– The structure conforms to architectural principles.

• Strength– The architecture provides sufficient support to the pursuit of the enterprise’s mission.– The structure can endure a normal range of shocks and impacts from internal or external sources.– The architecture has self-discipline and self-adjustment ability to respond to changes.

• Economy– The architecture optimizes enterprise-wide resource use (including time and space use) that is affected by

the architecture.– The architecture optimizes the enterprise gain that can be obtained through the support of the architecture.– The architecture minimizes the cost to maintain and improve the architecture.

• Sustainability– The architecture remains vital and capable over the life of the enterprise.– The changes designed for and implemented in the architecture can persist as intended.

Enterprise Overall Architecture

Segment Architecture Module Architecture

Component Architecture

8.2 A qualitative evaluating system: Architectural Soundness Checklist (cont.)

Soundness Analyses should be enabled by an EA model and information base to identify:

• function gaps and duplications• Interface/exchange mismatches• architectural principle violations• structural instability or torpidity• resources disconnections• security loopholes• implementation gaps• operation gaps• change discordance• critical weaknesses• …

8.2 A Quantitative Measuring System: Architectural Optimization Triple

OpportuEnterpriseCapability

Optimization

Opp

ortu

nity

Opt

imiz

atio

n

Process O

ptimization

Resources Use Optimization

External Environment/

Context

Line

of B

usin

ess

Contextual

Conceptual

Logical

Physical

Operational

Direction of A

ggregation

Range of Summation

8.2 A Quantitative Measuring System: Architectural Optimization Triple (cont.)

OpportuEnterpriseCapability

Optimization

Opp

ortu

nity

Opt

imiz

atio

n

Process O

ptimization

Resources Use Optimization

Optimization Analyses should be enabled by an EA model and information base:

• goal achievement scorecard• bottleneck identification and quantification• total cost summation and decomposition• inventory summation and decomposition• capability maturity indicator allocation• opportunity identification and quantification• process performance statistics• …

9. SummaryThe EA View Framework serves these purposes:

• Organizes architectural designs;• Implements architectural integrity in designs; • Links designs with the end result of improving specific and overall managements; • Incorporates architectural and design principles into EA information models; and• Identifies means to evaluate and optimize designs and architectures.