EA View Framework

739 views
678 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
739
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Version History: Version Date Person Description V 0.1 8/12/2006 Haiping Luo Created the framework to organize the Design chapter in EA Management Guide. V 0.4 9/16/2006 Haiping Luo Updated to be posted along with EAMG draft 1.1. Added EA Continuums. V 1.0 10/29/2006 Haiping Luo Updated to be posted with EAMG draft 1.3. Added relationship between enterprise management and EA views.
  • Add quotations: Zachman Framework GERAM TOGAF FEAF DODAF NGOSS EA Cube
  • Example implications: Strategic management does not stay in the high level only. It needs to be carried out by the lowest level to deliver the outcomes.
  • Implication: An enterprise’s architecture exists and evolves as long as the enterprise lasts. A planned and managed EA evolution will yield more desirable outcomes than an unplanned one.
  • Zachman’s primitivity requirement for an element can be implemented in the core aspect category. That is, at the lowest level of the decomposition, all element should satisfy a single user function/output. The primitivity will enable reuse and precise mapping of elements to the maximal extent and maintain element value’s uniqueness. Lifecycle adapted from GERAM.
  • Adapted from “How to Create Theory of Design”, http://www2.uiah.fi/projects/metodi/, Pentti Routio, 2005.
  • Source: Haiping Luo, “What Does That Mean? Muddling Through Confusing EA Concepts and FAQs”, unpublished paper, February 2006.
  • 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. 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 planned.
  • Optimization triple adapted from US Dept. of Defense Business Transformation Agency, presentation at the 6 th EA Conference, Washington, DC, 2006. Throughput: the rate at which the system produces "goal units." Each organization has a goal. Better decisions increase its achievement of that value. When the goal units are money (in for-profit businesses), throughput is sales revenues less the cost of the raw materials (T = S - RM). Note that T only exists when there is a sale of the product or service. Producing materials that sit in a warehouse does not count. ("Throughput" is sometimes referred to as "Throughput Contribution" and has similarities to the concept of "Contribution" in Marginal Costing which is sales revenues less "variable" costs - "variable" being defined according to the Marginal Costing philosophy.) Throughput accounting applies to not-for-profit organizations too, but they have to develop a goal that makes sense in their individual cases. Eliyahu M. Goldratt, Jeff Cox. The Goal: Process of Ongoing Improvement. Theory of Constraints.
  • EA View Framework

    1. 1. 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)
    2. 2. Table of Contents <ul><li>Introduction of an EA View Framework </li></ul><ul><li>The Basics </li></ul><ul><li>Overall Structure </li></ul><ul><li>Integrity Rules </li></ul><ul><li>Viewing an Architecture from 5 Management Perspectives </li></ul><ul><li>EA Continuums </li></ul><ul><li>Other EA Views </li></ul><ul><li>Architecture Optimization </li></ul><ul><li>Summary </li></ul>
    3. 3. 1. Introduction <ul><li>This attachment introduces an EA View Framework to organize architectural designs and to implement architectural integrity. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
    4. 4. 2. EA View Framework: the Basics <ul><li>Architectural components : </li></ul><ul><ul><li>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). </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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. </li></ul></ul>Representation in the EA Information Model …………………… Entity .……………Model Entity ………………… Grouping
    5. 5. 2. EA View Framework: the Basics (cont.) <ul><li>Structuring materials </li></ul><ul><ul><li>Relationship : A type of connection between components. </li></ul></ul><ul><ul><li>Interface : The point of interaction or communication between components. </li></ul></ul><ul><ul><li>Exchange flow : The content being exchanged between components. Example: information, control, physical material, influence. </li></ul></ul>Representation in the EA Information Model ……… ..Relationship Entity .…………Model Interface …… Exchange Information
    6. 6. 2. EA View Framework: the Basics (cont.) <ul><li>Component’s features : </li></ul><ul><ul><li>Has a lifecycle and a life history. </li></ul></ul><ul><ul><li>Has properties. </li></ul></ul><ul><ul><li>Has relationships. </li></ul></ul><ul><ul><li>Has states and conditions over time. </li></ul></ul><ul><li>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. </li></ul>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
    7. 7. 3. EA View Framework: the Overall Structure External Environment/ Context Line of Business Architectural Segments Level of Decomposition Contextual Conceptual Logical Physical Operational Direction of Aggregation Range of Summation
    8. 8. 3. EA View Framework: the Overall Structure (cont.) <ul><li>The architecture can be viewed from 5 management perspectives corresponding to 5 enterprise management domain groups : </li></ul><ul><li>Strategic management perspective </li></ul><ul><li>Business management perspective </li></ul><ul><li>Resource management perspective </li></ul><ul><li>Risk management perspective </li></ul><ul><li>Electronic management perspective </li></ul><ul><li>The architecture can also be viewed over time: </li></ul><ul><li>Current state of the architecture </li></ul><ul><li>Target state of the architecture </li></ul><ul><li>Transition states of the architecture </li></ul><ul><li>The architecture can be viewed from more viewpoints: </li></ul><ul><li>Technology View, Operations View, Communication View, Control View, … </li></ul>
    9. 9. 3. EA View Framework: the Overall Structure (cont.) <ul><li>The architecture can be decomposed into levels, segments, specialty architectures, and other components. </li></ul><ul><li>Level of decomposition: </li></ul><ul><li>Contextual Level: this level turns external mandates, environmental factors, and internal strengths into strategic goals and plans for the domain in focus. </li></ul><ul><li>Conceptual Level: this level decomposes strategic goals and plans into objectives and management plans. </li></ul><ul><li>Logical Level: this level translates management plans into project or implementation plans and processes. </li></ul><ul><li>Physical Level: this level implements plans and processes. </li></ul><ul><li>Operational Level: this level carries out detail tasks and activities. </li></ul>
    10. 10. 4. EA View Framework: Integrity Rules (examples) <ul><li>Regardless how to view, segment, or decompose, the architecture is a whole for an enterprise. </li></ul><ul><li>Architectural components should exist independent of any EA framework and can be viewed in multiple frameworks. </li></ul><ul><li>All management domains and their corresponding architectural components run across all decomposition levels and involve all segments. </li></ul><ul><li>Each Line-of-Business segment contains components from all management domains and covers all decomposition levels. </li></ul><ul><li>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. </li></ul><ul><li>Decomposition and segmenting must support aggregation to higher levels and summation to the enterprise whole. </li></ul><ul><li>Designs should pursue enterprise optima, not local optima. </li></ul><ul><li>Changes to designs have to address their enterprise impacts before implementing. </li></ul>
    11. 11. 5. Viewing an Enterprise Architecture from Five Management Perspectives <ul><li>The designs of architectures need to support 5 enterprise management domain groups and can be viewed/evaluated from 5 perspectives. </li></ul>Enterprise Management Strategic Management domain group Business Management domain group Resource Management domain group Risk Management domain group Electronic Management domain 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 Perspective supports determines supports determines supports determines supports determines
    12. 12. 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 <ul><li>Strategic Management Domains & architectural components (examples): </li></ul><ul><li>Goal management </li></ul><ul><ul><li>Goal mgmt processes </li></ul></ul><ul><li>Organization management </li></ul><ul><ul><li>Org structure </li></ul></ul><ul><li>Quality & Performance mgmt </li></ul><ul><ul><li>Performance mgmt structure & processes </li></ul></ul><ul><li>Resources management </li></ul><ul><ul><li>Investment portfolio* </li></ul></ul><ul><li>Risk management </li></ul><ul><ul><li>Risk mgmt structure* </li></ul></ul><ul><li>Electronic management </li></ul><ul><ul><li>Management information systems* </li></ul></ul>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
    13. 13. 5.2 EA View Framework: the Business Management Perspective Environment/ Context e.g. processes architecture e.g. process’ implementations <ul><li>Business Management Domains & architectural components (examples): </li></ul><ul><li>Line of business management </li></ul><ul><ul><li>Business plans* </li></ul></ul><ul><ul><li>Business processes </li></ul></ul><ul><li>Resources management </li></ul><ul><ul><li>Supply chains* </li></ul></ul><ul><ul><li>Accounting processes* </li></ul></ul><ul><ul><li>Assets & equipment supplies* </li></ul></ul><ul><li>Partner management </li></ul><ul><ul><li>Partner channels </li></ul></ul><ul><li>Customer relationship mgmt </li></ul><ul><ul><li>Customer relationship types </li></ul></ul><ul><ul><li>Customer service processes </li></ul></ul><ul><li>Quality &Performance mgmt </li></ul><ul><ul><li>Performance plans & processes* </li></ul></ul><ul><li>Risk management </li></ul><ul><ul><li>Business continuity plan & processes* </li></ul></ul><ul><li>Electronic management </li></ul><ul><ul><li>Automation & productivity tools* </li></ul></ul><ul><ul><li>Information mgmt structure* </li></ul></ul><ul><ul><li>Communication patterns* </li></ul></ul>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
    14. 14. 5.3 EA View Framework: the Resource Management Perspective Environment/ Context e.g. investment projects e.g. project financing <ul><li>Resource Management Domains & architectural components (examples): </li></ul><ul><li>Financial management </li></ul><ul><ul><li>Financing processes and controls </li></ul></ul><ul><ul><li>Accounting processes and controls </li></ul></ul><ul><li>Assets management </li></ul><ul><ul><li>Assets portfolio </li></ul></ul><ul><ul><li>Assets allocations </li></ul></ul><ul><li>Materials management </li></ul><ul><ul><li>Inventory allocations </li></ul></ul><ul><ul><li>Supply chains </li></ul></ul><ul><li>Human resources mgmt </li></ul><ul><ul><li>HR reservoir </li></ul></ul><ul><ul><li>HR processes </li></ul></ul><ul><li>Quality &Performance mgmt </li></ul><ul><ul><li>Performance plans & processes* </li></ul></ul><ul><li>Risk management </li></ul><ul><ul><li>Business continuity plan* </li></ul></ul><ul><ul><li>Compliance structure & processes* </li></ul></ul><ul><li>Electronic management </li></ul><ul><ul><li>Automation & productivity tools* </li></ul></ul><ul><ul><li>Information mgmt structure* </li></ul></ul><ul><ul><li>Communication patterns* </li></ul></ul>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
    15. 15. 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 <ul><li>Risk Management Domains & architectural components (examples): </li></ul><ul><li>Compliance management </li></ul><ul><ul><li>Compliance structure & processes </li></ul></ul><ul><li>Business continuity management </li></ul><ul><ul><li>Business continuity processes </li></ul></ul><ul><li>Resources management </li></ul><ul><ul><li>Emergency HR processes* </li></ul></ul><ul><ul><li>Emergency inventory, assets, & supply chains* </li></ul></ul><ul><li>Electronic management </li></ul><ul><ul><li>Security architecture* </li></ul></ul><ul><ul><li>Automation tools* </li></ul></ul><ul><ul><li>Information mgmt structure* </li></ul></ul><ul><ul><li>Communication patterns* </li></ul></ul><ul><li>Quality &Performance mgmt </li></ul><ul><ul><li>Performance plans & processes* </li></ul></ul>Strategic Mgmt Business Mgmt Resource Mgmt Electronic. Mgmt Links to other perspectives e.g. incidents response operations
    16. 16. 5.5 EA View Framework: the Electronic Management Perspective Environment/ Context e.g. application architecture e.g. solution architecture e.g. development coordination <ul><li>Electronic Management Domains & architectural components (example): </li></ul><ul><li>Information management </li></ul><ul><ul><li>Information architecture </li></ul></ul><ul><li>Automation & Productivity mgmt </li></ul><ul><ul><li>Application architecture </li></ul></ul><ul><li>Infrastructure management </li></ul><ul><ul><li>Network architecture </li></ul></ul><ul><ul><li>Telecommunication architecture </li></ul></ul><ul><li>Cyber security management </li></ul><ul><ul><li>Security architecture* </li></ul></ul><ul><li>Technology management </li></ul><ul><ul><li>Technology profile </li></ul></ul><ul><ul><li>Investment portfolio* </li></ul></ul><ul><ul><li>Technical standards </li></ul></ul><ul><li>Quality &Performance mgmt </li></ul><ul><ul><li>Performance plans & processes* </li></ul></ul>Strategic Mgmt Business Mgmt Resource Mgmt Risk Mgmt Links to other perspectives e.g. operations and services e.g. automation goals
    17. 17. 6. Various EA Continuums Enterprise’s architectures form, and can be viewed as, various continuums: <ul><li>EA Time Continuum </li></ul><ul><li>EA Implementation Continuum </li></ul><ul><li>EA Specification Continuum </li></ul><ul><li>Implications: </li></ul><ul><li>The continuum characteristics represents the changes and connections among states and phases of architectural designs. </li></ul><ul><li>The continuums require EA information models to capture continuum characteristics, allow views by state or phase, and display the connections. </li></ul>
    18. 18. 6.1 EA Continuums: View Over Time Environment/ Context Line of Business Contextual Conceptual Logical Physical Operational Environment/ Context Line of Business Contextual Conceptual Logical Physical Operational EA Mgmt & Change Path Current State Target State <ul><li>Strategic Mgmt Perspective </li></ul><ul><li>Business Mgmt Perspective </li></ul><ul><li>Resource Mgmt Perspective </li></ul><ul><li>Risk Mgmt Perspective </li></ul><ul><li>Electronic Mgmt Perspective </li></ul>Transition States Enterprise Architecture Time Continuum
    19. 19. 6.2 EA Continuums: Decomposition of Implementation Segment Architecture e.g. Engine Manufacture, Military Command Module Architecture e.g. Accounting, Logistics Component Architecture EA Implementation Continuum Line of Assembling Enterprise Overall Architecture
    20. 20. 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* <ul><li>A component can be singular (an element) or composite (a module, a segment, or an enterprise). </li></ul><ul><li>The aspect categories link the component’s characteristics to enterprise architecture requirements. </li></ul><ul><li>All aspect categories are considered at every phase of the component lifecycle but with different emphases and different level of details. </li></ul><ul><li>The ring structure reflects order of consideration from core to outer layers, with user required functions being the beginning point. </li></ul>* User Functions /output Data People Control Timing Location Infrastructure Security Quality Technology Performance Interfaces Resources
    21. 21. 6.3 EA Continuums: Generic to Specific EA Specification Continuum Note: The knowledge movement between empiria and theory is a continuous circle that may start at any point. World of Empiria World of Theory Object : Enterprise architectures Informative Descriptive research Descriptive Theory of generic architectures Context : People, their values, beliefs, preferences Design Theory of Goal-oriented architectures Normative General Studies Enterprise-specific architecture design Living architecture Implementation Architecture development project Normative Enterprise-specific studies
    22. 22. 7. EA View Framework: Other Possible Views An enterprise’s architecture can be viewed in more ways: <ul><li>Process view </li></ul><ul><li>Technology view </li></ul><ul><li>Communication view </li></ul><ul><li>Control view </li></ul><ul><li>Compliance view </li></ul><ul><li>… </li></ul><ul><li>Implications: </li></ul><ul><li>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. </li></ul><ul><li>EA information models need to have the capability, flexibility and extensibility to allow many different views. </li></ul>
    23. 23. 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.
    24. 24. 7.2 View Example: Process Flows External Environment/ Context Architectural Segments A View of a Cross-Segment Operation
    25. 25. 8. EA View Framework: Architectural Optimization An enterprise’s architecture should be optimized and evaluated qualitatively and quantitatively: <ul><li>Implications: </li></ul><ul><li>The goal of EA designs is to identify the most suitable and feasible architecture for the enterprise in focus. </li></ul><ul><li>EA information models need to provide the ability to measure the quality and performance of an architecture. </li></ul><ul><li>A qualitative evaluating system: </li></ul><ul><ul><li>Architectural Soundness Checklist </li></ul></ul><ul><li>A quantitative measuring system: </li></ul><ul><ul><li>Architectural Optimization Triple </li></ul></ul>
    26. 26. 8.2 A qualitative evaluating system: Architectural Soundness Checklist <ul><li>Suitability </li></ul><ul><ul><li>The pattern by which elements are interrelated or arranged fits the type and purpose of the enterprise in focus. </li></ul></ul><ul><ul><li>The functionalities of the structure support the functions and activities of the enterprise effectively. </li></ul></ul><ul><li>Integrity </li></ul><ul><ul><li>Elements have compatible interfaces and exchange media to coordinate and interact with each other. </li></ul></ul><ul><ul><li>Elements support and supplement each other so the enterprise whole is better than the sum of individual elements. </li></ul></ul><ul><ul><li>The structure conforms to architectural principles. </li></ul></ul><ul><li>Strength </li></ul><ul><ul><li>The architecture provides sufficient support to the pursuit of the enterprise’s mission. </li></ul></ul><ul><ul><li>The structure can endure a normal range of shocks and impacts from internal or external sources. </li></ul></ul><ul><ul><li>The architecture has self-discipline and self-adjustment ability to respond to changes. </li></ul></ul><ul><li>Economy </li></ul><ul><ul><li>The architecture optimizes enterprise-wide resource use (including time and space use) that is affected by the architecture. </li></ul></ul><ul><ul><li>The architecture optimizes the enterprise gain that can be obtained through the support of the architecture. </li></ul></ul><ul><ul><li>The architecture minimizes the cost to maintain and improve the architecture. </li></ul></ul><ul><li>Sustainability </li></ul><ul><ul><li>The architecture remains vital and capable over the life of the enterprise. </li></ul></ul><ul><ul><li>The changes designed for and implemented in the architecture can persist as intended. </li></ul></ul>
    27. 27. 8.2 A qualitative evaluating system: Architectural Soundness Checklist (cont.) Segment Architecture Module Architecture Component Architecture <ul><li>Soundness Analyses should be enabled by an EA model and information base to identify: </li></ul><ul><li>function gaps and duplications </li></ul><ul><li>Interface/exchange mismatches </li></ul><ul><li>architectural principle violations </li></ul><ul><li>structural instability or torpidity </li></ul><ul><li>resources disconnections </li></ul><ul><li>security loopholes </li></ul><ul><li>implementation gaps </li></ul><ul><li>operation gaps </li></ul><ul><li>change discordance </li></ul><ul><li>critical weaknesses </li></ul><ul><li>… </li></ul>Enterprise Overall Architecture
    28. 28. 8.2 A Quantitative Measuring System: Architectural Optimization Triple Opportu Enterprise Capability Optimization Enterprise Throughput Optimization Opportunity Optimization Process Optimization Resources Use Optimization External Environment/ Context Line of Business Contextual Conceptual Logical Physical Operational Direction of Aggregation Range of Summation
    29. 29. 8.2 A Quantitative Measuring System: Architectural Optimization Triple (cont.) Opportu Enterprise Capability Optimization Enterprise Throughput Optimization Opportunity Optimization Process Optimization Resources Use Optimization <ul><li>Optimization Analyses should be enabled by an EA model and information base: </li></ul><ul><li>goal achievement scorecard </li></ul><ul><li>bottleneck identification and quantification </li></ul><ul><li>total cost summation and decomposition </li></ul><ul><li>inventory summation and decomposition </li></ul><ul><li>capability maturity indicator allocation </li></ul><ul><li>opportunity identification and quantification </li></ul><ul><li>process performance statistics </li></ul><ul><li>… </li></ul>
    30. 30. 9. Summary <ul><li>The EA View Framework serves these purposes: </li></ul><ul><ul><li>Organizes architectural designs; </li></ul></ul><ul><ul><li>Implements architectural integrity in designs; </li></ul></ul><ul><ul><li>Links designs with the end result of improving specific and overall managements; </li></ul></ul><ul><ul><li>Incorporates architectural and design principles into EA information models; and </li></ul></ul><ul><ul><li>Identifies means to evaluate and optimize designs and architectures. </li></ul></ul>

    ×