Enterprise Architecture .vs. Collection of Architectures in Enterprise
10 likes3,255 views
The document discusses the differences between enterprise architecture (EA) and a collection of architectures in an enterprise. It argues that EA requires a top-down guidance framework to ensure the various architectures developed across an organization are coordinated and aligned. The key elements of an effective EA framework include a target vision, principles, governance, reference architectures, development approaches, and an evolution roadmap. The document also outlines the focus areas in each phase of the TOGAF architecture development method to help ensure successful adoption of EA in initiatives, programs and projects. Effective EA requires balancing top-down guidance with bottom-up flexibility for organic growth.
Enterprise Architecture .vs. Collection of Architectures in Enterprise
- 1. The Open Group Conference, Washington D.C., July 16 – 18, 2012 Enterprise Architecture vs. Collection of Architectures in Enterprise Yan Zhao, PhD Chief Architect, ArchiTech Consulting LLC [email protected] www.architechllc.com July 17, 2012
- 2. Content Summary Rationale EA concept and position EA vs. a collection of architectures in enterprise The essential elements for EA development The focus in each phase and stage of EA development (e.g. based on TOGAF) to ensure successful EA adoptions in solutions, initiatives, programs, and projects Yan Zhao, Ph.D, ArchiTech Consulting LLC 2
- 3. Rationale EA practice needs improvement: EA has been practiced visibly for over 10 years, necessity is well recognized, but success is limited; more collection of architectures in enterprise vs. real EA The major challenges: stakeholder participation, architecture modeling, architecture usage, architecture maintenance and program management Lessons learned: EA development needs target vision as its soul, and needs core concepts as its art of creation. The common knowledge of architecture is applicable to EA The federated EA development needs to be more effective -> EA vs. Collection of Architectures in Enterprise Too much control will be counter-productive Too much freedom can be chaotic, self adjustment can be very costly Intention: clarify the concept, find the soul, refresh the core, simplify the efforts, promote a balanced approach for success 7/17/2012 Yan Zhao, Ph.D, ArchiTech Consulting LLC 3
- 4. Architecture Concept Original definition of Architecture by Sir Henry Watton: “In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight” This definition is applicable to EA as well: EA is an operative art, the EA products must direct the effective enterprise operation Commodity: EA should serve all its relevant audience and stakeholders, should be consistent and understandable by them (e.g. via multiple views) Firmness: EA products should be solid and practicable enough for implementation Delight: EA has to be well appreciated and accepted to be adopted and be effective in implementation Yan Zhao, Ph.D, ArchiTech Consulting LLC 4
- 5. What is Enterprise Architecture? Enterprise Architecture (EA) is an enterprise blueprint with descriptions of enterprise structure and operating models. It consists of business, application, info/data, and technical architectures as sub-domains (each sub-domain can drive down further beyond EA). Program & Project Management Enterprise Architecture Business & IT Strategies Business Application Architecture Architecture Security Architecture Info/Data Technical Architecture Architecture Performance Management Model Solutions & Execution Yan Zhao, Ph.D, ArchiTech Consulting LLC 5
- 6. The Purpose of EA Establish common vision and views across organizations to support achievement of common goals (via target vision) Have a blueprint to support business decision making and decision impact analysis (via both as-is and target EA) Provide guidance for enterprise evolution in response to the continuous change requests imposed from business and technologies, to avoid less informed decisions (roadmap) Have better understanding of the current business and system implementations, identify improvement and optimization opportunities across board (via as-is EA) Enable cost reduction and overall performance improvement from enterprise global optimization. Enable the use of IT effectively and efficiently across enterprise, so to improve automation opportunities (via target EA) Yan Zhao, Ph.D, ArchiTech Consulting LLC 6
- 7. EA vs. Collection of Architectures in Enterprise Enterprise Architecture Plan: EA consists of architecture artifacts in concert by planning ahead with a designated purpose and scope for its views Content: EA is an art of creation, with core concepts serving its soul of vision, and has the sense of entirety. The level of details should be just good enough to convey the intent and to serve the purpose. It can be refined in federated manner by sub-organizations and tasks to go further Cultural Fitness: EA has to be fit in its cultural environment, with global optimization in nature, so to be appreciated and accepted for implementation Collection of Architecture in Enterprise Architecture artifacts may be developed separately, in different timeframes, cover different level of content details, and are created from different perspectives for different purpose Lack of an overall guidance for the core, the soul, and the disciplinary elements Make above two work together in concert -> a balanced approach Provide the essential top-down guidance and governance framework to facilitate federated EA development effectively The bottom-up EA development should follow the guidance and governance framework, so to keep in concert during organic growth Yan Zhao, Ph.D, ArchiTech Consulting LLC 7
- 8. EA Best Practice Observation EA Stakeholder Participation It needs clear target vision or work direction for stakeholders to understand what they need to do and why doing it It needs clearly identify the roles and responsibilities in order to proceed for EA development and in collaboration with others EA Modeling Just by using an EA tool and framework, and follow some widely published EA process will not get the EA as the end products EA is a creative art, it needs soul and core concepts EA Lifecycle and Management EA is a living art with lifecycle, the evolution of architectural vision, drivers, insight, intent, and requirements guide EA through its evergreen process EA is in a complex domain of people, systems, and culture, and in a constantly changing environment. It is important to balance top-down guidance/governance with bottom-up flexibility/freedom for organic growth -> collection of federated architectures developed with discipline. EA Skills Bridge technical and business, with breadth and depth in knowledge Creative and artistic on vision, insight, models and views with abstraction 7/17/2012 Yan Zhao, Ph.D, ArchiTech Consulting LLC 8
- 9. The Essential Disciplinary Elements for EA Top-Down Guidance and Governance EA target vision: a commonly accepted direction, as the soul of intent and purpose, which is important in identify the scope of EA efforts, e.g. for both current state assessment and target architecture creation EA principles: EA Principles are general rules and guidelines last a long time, which support enterprise vision, mission, goals and objectives EA governance: policies, rules, guidelines, processes, measurements, and enforcement mechanisms EA reference architectures: provide guidance for effective, disciplined, consistent, and cohesive architecture description mechanism across organizations EA development approach, methodologies, and tools: these are selectable for the best fit EA evolution roadmap: EA products should be alive with evergreen process in place, which will keep it current and effective all the time Yan Zhao, Ph.D, ArchiTech Consulting LLC 9
- 10. The Role and Context of EA Principles EA principles reflect an enterprise's purpose, vision, and values. It provides a foundation for EA development and implementation. •Business mission, vision, value •Business & IT strategic plan •Industry best practice •Target vision and requirements •Knowledge & experience Drivers Guidance EA Principles Governance Guidance Policies & procedures •Reference Architectures for governance framework Support •EA development •Solution implementation Business & IT decision making (via best practice guidance, criteria, and constrains) 7/17/2012 Yan Zhao, Ph.D, ArchiTech Consulting LLC 10
- 11. From EA Principles to Executions EA Principles Implications Governance Action Items Guidance Policies & procedures •Reference Architectures Support •EA development for governance framework •Solution implementation Business & IT decision making (via best practice guidance, criteria, and constrains) 7/17/2012 Yan Zhao, Ph.D, ArchiTech Consulting LLC 11
- 12. EA Governance Structure Constitution: EA principles Legislation: guidelines, Judiciary process, standards, rules, policies, measurement, etc. Judiciary: governance board for enforcement of execution -> results, and consequences Continuous Operation: for process execution and sustainable performance Change of Operation: for Legislation Constitution determination and management of changes 7/17/2012 Yan Zhao, Ph.D, ArchiTech Consulting LLC 12
- 13. EA Framework with Reference Models Views What How Where Who When Why Entity/Data Function Network People Time Motivation B1. List of Entities B2. Operational B4. List of Business B7. List of Stakeholders: B9. List of Events B10. Architecture Vision; Business Important to the Business Concept Diagram: Locations Role Catalog; Actor/Role Driver/Goal/Objective Catalog Environment (security entity included) Enterprise View Matrix and Cycles B11. Architecture Principles B5. Context Diagram Important to the B8.Organization Model for (Planner) B3. Business Footprint B6. Business Enterprise Architecture Business B12. List of Critical Business Diagram Business and Enterprise Reference Models Interaction Matrix Concerns and Risks Info/Data Reference Models F1. Data Entity/Data F3. Business Functional Services and F6. Environments and Location F9 Organization Charts: Capabilities, F12. Master F13. Performance Component Catalog for Business and Enterprise Level Architecture Decomposition: Architecture Building Diagram; Location Catalog Organization for Info/Data Architecture Blocks; Business Service Function Functions, F2. Business Catalog; Function Decomposition Diagram Schedule Model F7. Locations Mapped to Services Decomposition Diagram Service/Information Diagram F10. Organization/Actor Services F4. Activity Model F8. Communication Interfaces: Catalog F3. Data Entity/Business F5. Business Process Model: Process Interface Catalog (Owner) Function Matrix Flow Diagram F11. Stakeholder Map F6. Security Capability Specification Matrix L3. Application and Service Logical System L9. Distributed Service Architecture: L1. Logical Data Model: L11. Role/System Matrix L14. Event Diagram L17. Business Rule Logical Entity Relationship Models: Architecture Building Blocks Application Communication Diagram; L4. Business Services to Application Services Application Interaction Matrix; L12. System/Organization L15. Model Systems Diagram Mapping L5. Process Flow Diagram Communications Engineering Diagram; Processing Diagram Matrix Process/Event/Control/Prod (Designer) L2. Data Security L6. System/Function Matrix L10. Distributed Security Service L13. Use Case Diagram uct Catalog L18. Business Rule L16. Process/System Design Application/Service Reference Models L7. System/Data Matrix Diagram Model L8. Application Security Service Model Realization Diagram Physical P2. Physical System Architecture: P5. Application and User P1. Physical P8. Stakeholder Systems Data Model, Platform Decomposition Diagram P3. Logical System Components to Physical System Components Mapping for Application Architecture Location Diagram List (include P6. Network Architecture : (Builder) P4. Physical Security Service Spec. Networked Computing /Hardware Diagram security) P7. Network Security Spec. Technology T1. Information T2. Fannie Mae Technical Reference Model (TRM): T4. Technology References Dictionary Technology Principles; Technology Standards Catalog Portfolio T3.System/Technology Matrix Catalog Technology Reference Models Technology DS1. Data DS2. Building for Technology Architecture DS3. Network DS4. PoCs DS5. Detailed DS6. Rule Details Definitions Components (e.g. implementation Schedule Specification COTS and Specification (Dictionary) Program) components 7/17/2012 Yan Zhao, Ph.D, ArchiTech Consulting LLC 13
- 14. Reference Architectures across EA Sub-Domains Business Reference Architecture: consists of Business Reference Models (BRM) describing business environment, capabilities, functions, and services (in yellow area) Application/Service Reference Architecture: consists of Application/Service Reference Models (ARM) describing logical and physical systems for implementing business functions (in blue area) Info/Data Reference Architecture: consists of Info/Data Reference Models (DRM) describing presentation for information and data structures (in green area) Technology Reference Architecture: consists of Technology Reference Models (TRM) covers technology architecture relevant matters and technology standard specifications (in pink area) Security Reference Architecture: consists of Security Reference Models (SRM) addressing security solution options across layers Performance Reference Model (PRM): serves as motivation and measurement mechanism for capabilities, functions, and services improvement *Note: Many reference models that compose the reference architectures can be found in EA modeling tools Yan Zhao, Ph.D, ArchiTech Consulting LLC 14
- 15. EA Development Approaches, Methodologies, and Tools Examples of EA Development Approaches Service-orientation Component-based Model-driven Examples of EA Development Methodologies TOGAF ADM DoDAF Examples of EA Development Tools Modeling tools (System Architect, Metis, MEGA, SPARX, ArchiMate, etc.) Repositories (Troux EA Repository, Rational System Architect Repository, etc.) Requirements management tools (DOORS, Requisite Pro, etc.) Presentation tools (EA Modeling Tools, Visio, PowerPoint, etc.) Examples of Frameworks and Best Practice References Zachman Framework (a framework) TOGAF (a framework and best practice reference) Gartner Framework (a framework with best practice reference) A Practical Guide to Federal EA (best practice reference) 7/17/2012 Yan Zhao, Ph.D, ArchiTech Consulting LLC 15
- 16. The Focus in TOGAF ADM Phases to Ensure EA Adoption Preliminary Phase Stakeholder identification EA program and governance structure establishment (e.g. federated) EA development approach, methodologies, and tools decision Phase A: Architecture Vision EA target vision (driven by enterprise strategic plan) EA principles and guidance EA reference architectures EA evolution roadmap Phase B, C, D: Architecture Development Can be accomplished in federated manner across organizations Phase E: Solution Development Identify sub-domains, and develop solution architectures Identify initiatives, programs and projects for implementation Phase F, G, H: Architecture Implementation Define and implementation roadmap and transition plan in a federated manner across organizations, initiatives, programs and projects Manage EA with lifecycle process and governance 7/17/2012 Yan Zhao, Ph.D, ArchiTech Consulting LLC 16
- 17. EA Framework with Scope of Focuses Views What How Where Who When Why Entity/Data Function Network People Time Motivation B1. List of Entities B2. Operational B4. List of Business B7. List of Stakeholders: B9. List of Events B10. Architecture Vision; Business Important to the Business Concept Diagram: Locations Role Catalog; Actor/Role Driver/Goal/Objective Catalog Environment (security entity included) Enterprise View Matrix and Cycles B11. Architecture Principles B5. Context Diagram Important to the B8.Organization Model for (Planner) B3. Business Footprint Diagram Enterprise Architecture B6. Business Interaction Matrix Enterprise Architecture Business B12. List of Critical Business Concerns and Risks Capabilities, F1. Data Entity/Data Component Catalog F3. Business Functional Services and Decomposition: Architecture Building Blocks; Business Service Function (scope of focus)F12. Master F6. Environments and Location Diagram; Location Catalog F9 Organization Charts: Organization F13. Performance Functions, Catalog; Function Decomposition F7. Locations Mapped to Decomposition Diagram Schedule Model Info/Data Architecture F2. Business Diagram Services Service/Information Diagram F10. Organization/Actor Services F4. Activity Model F8. Communication Interfaces: Catalog F3. Data Entity/Business F5. Business Process Model: Process Interface Catalog (Owner) Function Matrix Flow Diagram F11. Stakeholder Map (scope of focus) F6. Security Capability Specification Matrix L3. Application and Service Logical System L9. Distributed Service Architecture: L1. Logical Data Model: L11. Role/System Matrix L14. Event Diagram L17. Business Rule Logical Entity Relationship Models: Architecture Building Blocks Application Communication Diagram; L4. Business Services to Application Services Application Interaction Matrix; L12. System/Organization L15. Model Systems Diagram Mapping L5. Process Flow Diagram Communications Engineering Diagram; Processing Diagram Matrix Process/Event/Control/Prod (Designer) uct Catalog L18. Business Rule L2. Data Security Diagram L6. System/Function Matrix L7. System/Data Matrix L8. Application Security Service Model Model Solution Architectures L10. Distributed Security Service L13. Use Case Diagram L16. Process/System Realization Diagram Design Physical P1. Physical P2. Physical System Architecture: Platform Decomposition Diagram Location Diagram (scope of focus) P5. Application and User P8. Stakeholder Systems Data Model, P3. Logical System Components to Physical System Components Mapping P6. Network Architecture : List (include (Builder) P4. Physical Security Service Spec. Networked Computing /Hardware Diagram security) P7. Network Security Spec. Technology T1. Information T2. Fannie Mae Technical Reference Model (TRM): T4. Technology References Dictionary Technology Principles; Technology Standards Catalog Portfolio T3.System/Technology Matrix Technology Architectures Catalog Technology DS1. Data DS2. Building (scopeDS4. PoCs DS3. Network of focus) DS5. Detailed DS6. Rule Details Definitions Components (e.g. implementation Schedule Specification COTS and Specification (Dictionary) Program) components 7/17/2012 Yan Zhao, Ph.D, ArchiTech Consulting LLC 17
- 18. Recommended Action Items Have a target vision as the soul (e.g. in response to next generation Internet, shared services, cloud computing, Internet of things, etc.) and have the core concepts in place before EA development; EA development is not an engineering process, it is an art of creation for enterprise operation, like the building architecture for building construction Enhance guidance, discipline, coordination, and governance for EA development. EA is not merely a collection of architectures in an enterprise Balance the centralized efforts and control from top-down with the flexible federated development efforts from bottom- up to be productive in organic growth, where insightful and wise decisions have to be made in the Chief Enterprise Architect level Yan Zhao, Ph.D, ArchiTech Consulting LLC 18