Get documents about "EA Alignment Framework 2009 6 28
Document Sample
An Integrated Approach to Align
an Enterprise’s Architecture:
EA Alignment Framework
Attachment to
Enterprise Architecture Management Guide
Chapter 6: EA Designs
(Created on 8/12/2006
Last Updated on 3/14/2010)
Table of Contents
Slide #. Outline #
#3. 1. Introduction
#4. 2. A Generic Enterprise Management Architecture
#5. 3. EA Alignment Framework: the Basics
#8. 4. EA Alignment Framework: the Overall Structure
#11. 5. EA Alignment Framework: Alignment Rules (examples)
#12. 6. Integrity Matrix for Management Areas
#18. 7. Viewing an Enterprise Architecture from Five Management
Perspectives
#24. 8. Various EA Continuums
#29. 9. EA Alignment Framework: Other Possible Views
#32. 10. EA Alignment Framework: Architectural Optimization
#33. 10.1 Architectural Quality Standards - 1
#36. 10.3 Architectural Optimization Triple
#38. 11.1 Summary of Alignment Dimensions for Architecture Op...
#40. 12. Summary
2
1. Introduction
•This attachment introduces a multi-dimensional, dynamic
framework to align architectural components and achieve
architectural quality and optimization.
• The key value of the EA Alignment Framework is to link
designs with the end result, i.e., using the designs to
improve specific managements, throughout the designing
process.
•The EA Alignment Framework extracts and implements
strengths from multiple frameworks, such as Zachman
Framework, GERAM, TOGAF, 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.
3
2. A Generic Enterprise Management Architecture
Management Enterprise Management
Areas
Strategic Business Resource Risk Electronic Execution and Operation
Management Management Management Management Management Management
Goal & Line of Financial Security Digital Process Communication
Management
Strategy Business Mgmt Mgmt Asset Mgmt Mgmt
Domains
Mgmt Mgmt Mgmt
Human Logistic Change
Resource Business
Organization Partner Digital Mgmt Mgmt
Mgmt Continuity
Mgmt Relationship Mgmt Processing Project Knowledge
Mgmt Mgmt Mgmt Mgmt
Result Asset Mgmt
Customer Legality and
Mgmt Electronic Service Rule Mgmt
Relationship Information Compliance Infrastructure Mgmt
Mgmt Mgmt Mgmt Coordination
Opportunity Mgmt
& Innovation Technology Mgmt
Mgmt Mgmt Fluctuation & Cyber
Uncertainty Security
Infrastructure
Mgmt Mgmt
Mgmt
Cross-area/domain Interoperation*
* Each area/domain obtains inputs from all other areas/domains and outputs to all other 4
areas/domains. See the Integrity Matrix in later slides for how to achieve interoperations. Last updated: 2/9/2010
3. EA Alignment Framework: the Basics
Representation in the EA
• Architectural components: Information Model
– Element: the unique unit of things, people, ……………………Entity
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 .……………Model Entity
self-contained portion and serves a function(s)
in the architecture. Example: an information
model, a solution architecture.
– Segment: A combination of elements, …………………Grouping
modules, and other segments that forms a
coordination structure and supports a
management domain. Example: a line-of-
business architecture, a security architecture.
5
3. EA Alignment Framework: the Basics (cont.)
Representation in the EA
• Structuring materials Information Model
– Relationship: A type of connection ………..Relationship Entity
between components.
– Interface: The point of interaction or .…………Model Interface,
communication between components. Interface Entity
– Exchange package: The content being
exchanged between components. ……Exchange Entity
Examples: information, control, physical
material, influence.
6
3. EA Alignment Framework: the Basics (cont.)
Representation in the EA Information
• Component’s features: Model
– Has properties. ……………………………Descriptive Attribute
– Has levels …………………………………….Level Attribute
…………………………….Relationship instance
– Has relationships.
– Has states and conditions over ………State Attribute, Instance Version, Saved
time. Query Result / Snapshot
– Has a lifecycle and a life history. …………Life Phase Attribute, Life Event Entity
• Views: A presentation of a selected .…………………Grouping, Query, Formatting,
Calculating, Diagramming, Visualizing
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.
7
4. EA Alignment Framework: the Overall Structure
External Environment/
Context
Contextual
Conceptual
Logical
Physical
Operational
Transactional*
•The Transactional Level is not in the scope of EA management. But transactional
statistics comprise an important portion in an enterprise’s documentation and alignment. 8
4. EA Alignment Framework: the Overall Structure (cont.)
Perspectives and Views
The architecture can be viewed from endless perspectives. Below is
viewing from 6 management perspectives corresponding to the 6
enterprise management areas:
1. Strategic management perspective
2. Business management perspective
3. Resource management perspective
4. Risk management perspective
5. Electronic management perspective
6. Execution and Operation 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, … 9
4. EA Alignment Framework: the Overall Structure (cont.)
Level of Abstraction / Line of Implementation
The architecture can be decomposed into levels, segments,
Roles and specialty architectures, and other components.
Viewpoints Level of Abstraction/Decomposition (Implementation):
1. External 1. Contextual Level: this level turns external mandates,
Stakeholders /
environmental factors, and internal strengths into strategic goals
Owner
and plans for the domain in focus.
2. Planner 2. Conceptual Level: this level decomposes strategic goals and plans
into objectives and management plans.
3. Designer 3. Logical Level: this level translates management plans into project
or implementation plans and processes.
4. Developer 4. Physical Level: this level implements plans and processes.
5. Implementer / 5. Operational Level: this level contains versions of configurations
Administrator and manages tasks and activities.
6. Transaction 6. Transactional Level: this level conducts individual tasks and
Operator activities.
10
5. EA Alignment Framework:
Integrity Rules for Architecture Designs (examples)
•One enterprise: Regardless how to view, segment, or decompose, the architecture is
a whole for an enterprise.
•Framework independency: Architectural components should exist independent of
any EA framework and can be viewed in multiple frameworks.
•Vertical and horizontal penetration and coherence:
• Every management group and its corresponding architectural components
penetrate to all decomposition levels and involve all segments.
• Each Line-of-Business segment contains components from all management
groups and covers all decomposition levels.
•Environment dynamics: Every component of the architecture needs to monitor the
enterprise’s environment. Environmental impacts received by every component need to
be addressed in the context of the enterprise.
•Synergization: Decomposition and segmenting must support synergization /
aggregation to higher levels and summation to the enterprise whole.
•Enterprise optimization: Designs should motivate component owners to pursue
those local optima that support enterprise optima.
•Change management: Changes to designs have to address their enterprise impacts
11
before implementing.
6. An Integrity Matrix to Align among
Management Areas
A Mechanism for Cross-sectional Alignment
The cross-sectional integrity matrix applies the
IDEF0 concept and model to align dynamic
exchanges between management areas, domains,
and line of business segments, as well as each
group’s exchanges with external stakeholders.
The cross-sectional integrity model implements bi-
directional alignment for a cell in the Architectural
Integrity Matrix. The Matrix provides a mechanism
to implement the cross-sectional alignment to the
entire enterprise.
12
6.1 Integrity Matrix for Management Areas
Pattern 1: Alignment with External Stakeholders and Self
4 Guidance
/Requirements
1
5 Inputs External 2
/Participating
Services Stakeholders 3
6 Enabling
2&8 Inputs
Products 1&7 Guidance
/Participating
/Services /Requirements
Services
7 4
3&9.
Enabling Management
Group 5
Products
/Services 6
9 8
Explanation: Based on IDEF0, a management group (either a management area or a domain)
incorporates external stakeholders’ inputs as well as the outputs from the group itself into its
alignment process. Each line in the diagram represents a “line of alignment” for EA 13
management.
Figure ??.
6.2 Integrity Matrix for Management Areas
Pattern 2: Alignment between Two Management Groups
4 Guidance
/Requirements
1
5 Inputs Row Mgmt 2
/Participating
Services Group 3
6 Enabling
2 Inputs
Products 1 Guidance
/Participating
/Services /Requirements
Services
4
Column Mgmt
Group 5
3 Enabling 6
Products
/Services
Explanation: A management group in the integrity matrix’ row (either a management
area or a domain) incorporates the outputs from the management group in the
matrix column into its alignment process.
Figure ??. 14
6.3 Integrity Matrix for Management Areas
All Things and Every Thing should be and can be Considered
Strategic Business Resource Risk Mgmt Electronic Execution
Mgmt Mgmt Mgmt Mgmt Mgmt
Strategic Row 1 Row 1 Row 1
External 2 2 Row 1
2
Row 1
2 2
Mgmt 3 3 3 3 3
Row Column 4 Column 4 Column 4 Column 4 Column 4
5 5 5 5 5
6 6 6 6 6
Business Row 1 Row 1 Row 1 Row 1 Row 1
2 External 2 2 2 2
Mgmt 3 3 3 3 3
Column 4 Row Column 4 Column 4 Column 4 Column 4
5 5 5 5 5
6 6 6 6 6
Resource External Row 1
2
3
Mgmt Column 4
Row 5
6
Risk
Mgmt
Electronic
Mgmt
Operation 15
Mgmt
6.4 Integrity Matrix for Management Areas
Explanations
• Among management area alignment: Each cell takes into
account of all inputs and outputs between the row
management area and the column management area.
• Area alignment with all other management areas: an entire
row takes into account of all inputs and outputs from all
management areas to a particular management area.
• Enterprise management alignment: The entire matrix takes
into account of all inputs and outputs from all management
areas to every management area.
• Domain level and segment level alignment: The matrix can be
decomposed to allow drilling down. Every level can achieve
alignment through this same way of taking every and all
things into account for every domain and segment.
• alignment with external requirements: Each management
group takes into account of inputs from external stakeholders
and needs to deliver output to satisfy external stakeholders . 16
6.5 Integrity Matrix for Management Areas
Management Alignment Dimensions
Strategic Business Resource Risk Mgmt Electronic Execution
Mgmt Mgmt Mgmt Mgmt Mgmt
Strategic External Row 1
23
Row 1
2
Row 1
2
Row 1
23
Row 1
23
Column 4 3 3 Column 4 Column 4
Row Column 4 Column 4
Mgmt 5
6
5 5 5
6
5
6 6 6
Business Row 1
2
External Row 1
2
Row 1
2
Row 1
2
Row 1
2
3 Row 3 3 3 3
Mgmt Column 4 Column 4 Column 4 Column 4 Column 4
5 5 5 5 5
6 6 6 6 6
Resource Row 1
2
Row 1
2
External Row 1
2
Row 1
2
Row 1
2
3 3 Row 3 3 3
Mgmt Column 4 Column 4 Column 4 Column 4 Column 4
5 5 5 5 5
6 6 6 6 6
Risk Mgmt Row 1
23
Row 1
23
Row 1
23
External Row 1
23
Row 1
23
Column 4 Column 4
5
Column 4
5 Row Column 4
5
Column 4
5 5
6 6 6 6 6
Electronic Row 1
2
Row 1
2 Row 1
2
Row 1
2 External External
3 3 3 3
Column 4 Column 4 Column 4 Column 4 Row Row
Mgmt 5
6
5
6
5
6
5
6
Operation Row 1
2
Row 1
2 Row 1
2
Row 1
2 Row 1 External
3 3 3 3 2
3
Column 4 Column 4 Column 4 Column 4 4 Column 4 Row
Mgmt 5
6
5
6
5
6
5 5
66
5
6
2. Cross Management Alignments
1. External Alignments: First of all, each management group aligns with its external stakeholders (the diagonal cells).
2. Cross Management Alignments: Each management group aligns with itself and every other management group. 17
7. Viewing an Enterprise Architecture from
Six Management Perspectives
The designs of architectures need to support 6 enterprise
management areas and can be viewed/evaluated from 6
perspectives.
Enterprise Management Enterprise Architecture Views in EA Information Base
achieved through takes management
management areas perspectives
supports
Strategic Management
Strategic Management Perspective
area determines
Business Management supports
Business Management Perspective
area determines
Resource Management supports
Resource Management Perspective
area determines
Risk Management supports
Risk Management Perspective
area determines
Electronic Management supports
Electronic Management Perspective
area determines
Execution and Operation supports
Execution/Operation Mgmt Perspective
Management area determines 18
7.1 EA Alignment Framework:
the Strategic Management Perspective
Environment/ Strategic Management
Context Domains & architectural
components (examples):
•Goal management
Business Mgmt •Goal mgmt processes
•Organization management
Links to other
•Org structure
perspectives
Resources Mgmt e.g. enterprise strategic plan •Result management
•Quality mgmt
e.g. program goals & plan •Performance mgmt
structure & processes
Risk Mgmt e.g. project portfolio •Opportunity management
•Resources management
e.g. project goals & plans •Investment portfolio*
•Risk management
Electronic. Mgmt •Risk mgmt structure*
e.g. team and individual goals & performance plans •Electronic management
•Management information
systems*
Operation Mgmt
Note: Items marked by * indicate cross-group components.
19
7.2 EA Alignment Framework:
the Business Management Perspective
Environment/ Business Management Domains &
Context architectural components (examples):
Strategic Mgmt •Line of business management
•Business plans*
•Business processes
•Resources management
Links to other •Supply chains*
Resource Mgmt perspectives e.g. LoB. business plan •Accounting processes*
•Assets & equipment supplies*
e.g. product line goals & plan •Partner management
•Partner channels
Risk Mgmt e.g. processes architecture •Customer relationship mgmt
•Customer relationship types
e.g. process’ implementations •Customer service processes
•Quality &Performance mgmt
Electronic. Mgmt •Performance plans & processes*
e.g. task allocation and achievements •Risk management
•Business continuity plan &
processes*
Operation Mgmt •Electronic management
•Automation & productivity tools*
•Information mgmt structure*
20
•Communication patterns*
7.3 EA Alignment Framework:
the Resource Management Perspective
Resource Management Domains &
architectural components (examples):
Environment/ •Financial management
Context
Strategic Mgmt •Financing processes and controls
•Accounting processes and controls
•Assets management
•Assets portfolio
Business Mgmt •Assets allocations
Links to other •Materials management
perspectives e.g. investment goals •Inventory allocations
•Supply chains
e.g. investment portfolio •Human resources mgmt
•HR reservoir
Risk Mgmt e.g. investment projects •HR processes
•Technology Advancement mgmt
e.g. project financing •Research
•Development
Electronic. Mgmt
e.g. activity spending controls
•Quality &Performance mgmt
•Performance plans & processes*
•Risk management
Operation Mgmt
•Business continuity plan*
•Compliance structure & processes*
•Electronic management
•Automation & productivity tools* 21
•Information mgmt structure*
•Communication patterns*
7.4 EA Alignment Framework:
the Risk Management Perspective
Environment/ Risk Management Domains &
Context architectural components
Strategic Mgmt (examples):
•Security management
•Legality& Compliance mgmt
•Compliance structure &
Business Mgmt
Links to other processes
perspectives e.g. risk mgmt goals •Business continuity management
•Business continuity processes
Resource Mgmt e.g. business continuity plan •Resources management
•Emergency HR processes*
e.g. emergency process coordination •Emergency inventory, assets, &
supply chains*
e.g. process implementations •Electronic management
•Security architecture*
Electronic. Mgmt •Automation tools*
e.g. incidents response operations •Information mgmt structure*
•Communication patterns*
•Quality &Performance mgmt
Operation Mgmt •Performance plans &
processes*
•Fluctuation & Uncertainty mgmt
22
7.5 EA Alignment Framework:
the Electronic Management Perspective
Environment/ Electronic Management Domains &
Context architectural components
Strategic Mgmt
(example):
•Digitalization management
•Digitalization landscape
Business Mgmt •Automation & Productivity mgmt
Links to other •Application architecture
perspectives e.g. automation goals •Infrastructure management
•Network architecture
Resource Mgmt
e.g. application architecture •Telecommunication architecture
•Cyber security management
e.g. solution architecture •Security architecture*
•Technology management
Risk Mgmt
e.g. development coordination •Technology profile
•Investment portfolio*
•Technical standards
e.g. operations and services •Quality &Performance mgmt
•Performance plans &
processes*
•Service management
Operation Mgmt
•Line of Service processes
23
7.6 EA Alignment Framework:
the Execution & Operation Management Perspective
Environment/ Execution Management Domains &
Context architectural components
Strategic Mgmt (example):
•Process management
•Process mgmt methodology
Business Mgmt
•Service mgmt
•Service mgmt methodology
Links to other e.g. Management •Logistic management
perspectives excellence goals •Transportation plan
Resource Mgmt •Project management
e.g. project mgmt lifecycle
•Project portfolio
e.g. project portfolio •Material management
•Material requirements
Risk Mgmt •Line of Business management
e.g. project plans
•Production architecture
•Result mgmt
e.g. project work breakdown schedules •Quality standards
Electronic Mgmt •Performance plans &
processes*
24
8. Various EA Continuums
An Enterprise’s architecture forms, 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.
25
8.1 EA Continuums: View Over Time
Environment/ Context Environment/ Context
Contextual Contextual
Conceptual Conceptual
EA Mgmt &
Logical Change Path Logical
Physical Physical
Operational Operational
• Strategic Mgmt Perspective
• Business Mgmt Perspective
• Resource Mgmt Perspective
• Risk Mgmt Perspective
• Electronic Mgmt Perspective
• Operation Mgmt Perspective
Transition States
Current State Target State
Enterprise Architecture Time Continuum
26
8.2 EA Continuums: Decomposition of Implementation
EA Implementation Continuum
Enterprise Overall Architecture
Line of Assembling
Segment Architecture Module Architecture
e.g. Engine Manufacture, e.g. Accounting,
Military Command Logistics
Component Architecture
27
8.3 EA Continuums:
Decomposition of Component
Component Lifecycle Component Aspect Categories Link to EA Requirement*
Interfaces
Identification
Infrastructure
Concept
Requirements Resources
Preliminary Design
Detailed Design People Data
User
Implementation Functions
/output
Operation
Control
Decommission Location
Timing
* •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, 28
with user required functions being the core, beginning point. “start with the
end in mind”.
8.4 EA Continuums: Generic to Specific
World of Empiria World of Theory
EA
Object: Informative Descriptive Theory of Specification
Enterprise architectures Descriptive research generic architectures Continuum
Context:
People, their values, Normative Design Theory of
beliefs, preferences General Studies Goal-oriented architectures
Architecture development
project
Normative Enterprise-specific
Enterprise-specific architecture design
studies
Implementation
Living architecture
Note: The knowledge movement between empiria and theory is a continuous circle that may start at any point. 29
9. EA Alignment 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 an 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 of architecture
documentations.
30
9.1 View Example: Implementation Width and Depth
External Environment/
Context
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
A View of Communication Technology Implementations*
* The stages of implementations at different lines of business are marked by the ovals.
31
9.2 View Example: Process Flows
External Environment/
Context
A View of a Cross-Segment Operation
32
10. EA Alignment Framework:
Architectural Optimization
An enterprise’s architecture should be optimized and evaluated
qualitatively and quantitatively:
• A qualitative evaluating system:
Architectural Quality Checklist
• A quantitative measuring system:
Architectural Optimization Triple
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.
33
A Qualitative Evaluating System:
10.1 Architectural Quality Standards - 1
• 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.
• Fosterage
– The architecture enables and supports the growth and continuous improvements of the enterprise
and its elements.
– The architecture encourages and utilizes opportunity seeking and innovations.
• 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.
34
10.1 Architectural Quality Standards - 2
• 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.
• Homeostasis
– The architecture has embedded-adjustment mechanisms to return to balance, equilibrium, or homeostasis timely,
efficiently, and with minimal loss and pain.
• Harmony
– The architecture is acceptable by its elements.
35
10.2 Architectural Quality Analyses
Quality Analyses should be enabled
Enterprise Overall Architecture by an EA model and information
base to identify:
• function gaps and duplications
• Interface/exchange mismatches
• architectural principle violations
Segment Architecture Module Architecture
• structural instability or torpidity
• resources mismatches
• security loopholes
• implementation gaps
• operation gaps
• change discordance
• critical weaknesses
Component Architecture •…
36
A Quantitative Measuring System:
10.3 Architectural Optimization Triple
External
Environment/
Context
Contextual
Conceptual
Opportu
Enterprise
Logical
Capability
Physical Optimization
Operational
Resources Use Optimization
37
10.3 Architectural Optimization Triple (cont.)
Optimization Analyses should be
enabled by an EA model and
information base:
• goal achievement scorecard
• bottleneck identification and
quantification
Opportu
Enterprise • total cost summation and
Capability decomposition
Optimization • inventory summation and
decomposition
• capability maturity indicator
Resources Use Optimization
allocation
• opportunity identification and
quantification
• process performance statistics
•…
38
11.1 Summary of Alignment Dimensions for
Architecture Optimization
Multi-dimensional* Dynamic Alignments to Pursue
Total Architecture Optimization
Align with the Environment (Signals, Stimulants, Constraints and Changes)
Continuum of
Architecture
Enterprise Optimization
Management Group
Alignment
Execution mgmt
Electronic mgmt
Decommission
Risk mgmt Operation
Implementation
Resource mgmt Detailed Design
Business mgmt Requirements
Concept Legend
Strategic mgmt
Identification
Arrowed line
Start Plate** Indicates alignment
Logical
Operational
Transactional
Conceptual
Contextual
Physical
Enterprise directions
Decomposition Level
Alignment
Element Attributes Alignment:
what, why, who, how, when, where * Each dimension has sub-dimensions to align.
** Start can happen anywhere in the cube, ideally in the 2-dimension Start Plate. For example,
a business transaction problem may trigger an architectural alignment process.
39
11.2 Summary of Alignment Dimensions
Explanation - 1
• The need for EA alignment may be triggered or recognized anywhere in the cube. Ideally, the need
should be identified first somewhere on the “Start Plate”. Delaying the identification and alignment will
cause more discords and cost higher for either fixing or not fixing discords.
• There are 5 dimensions of EA alignments to reach total architecture optimization.
1. Attribute dimension: Align an element with its purpose.
2. Object dimension: Align among components and management areas.
3. Decomposition dimension: Align along decision-to-implementation hierarchy.
4. Time dimension: Align along lifecycles and timelines.
5. Dynamic dimension: Align with the changing environment.
• Below is a preferred initial order of alignment. Note that all dimensions require continuous realigning
within and across:
1. Element attribute designation: Identify and designate the attributes and relationships regarding
“why, what, who, when, where, and how” aspects of the element.
2. Enterprise Management alignment: Identify and align all aspects across management groups.
3. Enterprise Decomposition level alignment: Identify and align all aspects down the
decomposition / implementation levels.
4. Element Lifecycle alignment: Maintain and update alignments when the element moves through
its lifecycle.
5. Environment interaction: Monitor and align with environmental opportunities, requirements and
constraints. 40
11.2 Summary of Alignment Dimensions
Explanation - 2
• Each dimension has its sub-dimensions to further align.
• The EA information base should support all these alignment types.
• Total Architectural optimization is only achieved when all aspects are aligned with all dimensions - the
green, upper-right line indicates the continuum of total optimization.
• Due to psychological, managerial, financial, technical barriers as well as the constant changing
environment, few element can reach and maintain the Total Optimization State. Nevertheless, reducing
gaps to the Total Optimization State indicates architectural improvement. Also the gap between the
actual alignment state and the total optimization state presents opportunities to improve the architecture
and obtain gain.
41
12. Summary
The EA Alignment 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.
42
