Lecture 2 - EA Models, Frameworks and Methodology

EA Models, Frameworks and Methodology CIS3000 - Information Systems Architecture and Infrastructure Objectives 1.8 Create an Enterprise Architecture using established models, frameworks and methodologies to support business strategic objectives EA Framework The Framework is a ge...

EA Models, Frameworks and Methodology CIS3000 - Information Systems Architecture and Infrastructure Objectives 1.8 Create an Enterprise Architecture using established models, frameworks and methodologies to support business strategic objectives EA Framework The Framework is a generic classification scheme for design artifacts, that is, descriptive representations of any complex object. EA - Models, Frameworks and Methodologies Zachman Framework Federal Enterprise Architecture Framework Gartner EA Framework The Open Group Architectural Framework (TOGAF) Zachman Framework Zachman Framework The Framework for Enterprise Architecture (or Zachman Framework) as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise’s systems, manual systems as well as automated systems. The Framework graphic in its most simplistic form depicts the design artifacts that constitute the intersection between the perspectives and the product abstractions Zachman Framework Perspectives Product Abstractions: PLANNER WHAT OWNER HOW DESIGNER WHERE BUILDER WHO IMPLEMENTER WHEN OPERATOR/USER WHY PERSPECTIVES Planner’s view (scope): This row is where you identify the business plan or strategy and establish what issue or concern will be addressed in the matrix. Owner’s view (business concepts): The second row is where you will identify business needs and the resources the business will need to execute the plan. Designer’s view (system logic): The third row identifies how the plan will meet the business’ needs. This row corresponds to work done by systems analysts who handle the data, process flows and functions of business processes. PERSPECTIVES Engineer’s perspective (technology physics): The fourth row includes relevant information about how to implement the strategy and what tools, technology, materials and constraints the team will be working with. Technician’s perspective (component assembly): This row is where you will include representations of requirements for products, services or hardware. User’s view (operations classes): The final row includes information about the functioning system and how it works in the IT or business environment. PRODUCT ABSTRACTIONS What (data): This is where you establish what business data, information and requirements are necessary for the project. How (function): The “how” or “function” column identifies how processes work and impact the business. Where (network): This column includes the “where,” which includes all system networks and relevant locations where business operations take place. PRODUCT ABSTRACTIONS Who (people): In column four you will identify the key stakeholders and determine all of the relevant personnel for the project. When (time): Column five is where you will identify when and at what time business processes are performed in the company. Why (motivation): The final column is where you will identify why you chose the final solution and what the motivation is behind the initiative or project. https://www.zachman.com/images/ZI_PIcs/ZF3.0.jpg Federal Enterprise Architecture Framework Federal Enterprise Architecture Framework The Federal Enterprise Architecture was implemented by the U.S. federal government in an effort to unite its myriad agencies and functions under a common enterprise architecture. Federal EA Domains There are six important domains of enterprise architecture for government agencies: Strategy Business Data Applications Infrastructure Security Steps in Federal EA - Collaborative Planning Step 1: Identify & Validate - identify and assess what needs to be achieved, understand the major drivers for change, and then define, validate, and prioritize the mission and goals with stakeholders and operational staff Step 2: Research & Leverage - identify organizations and service providers that may have already met, or are currently facing needs similar to the ones identified in Step 1, and then to analyze their experiences and results to determine if they can be applied and leveraged or if a partnership can be formed to address the needs together. Steps in Federal EA - Collaborative Planning Step 3: Define & Plan - develop the integrated plan for the adjustments necessary to meet the needs identified in Step 1. Recommended adjustments could be within any or all of the architecture domains: strategy, business, data, applications, infrastructure, or security Step 4: Invest & Execute - make the investment decision and implement the changes as defined in the integrated plan. Step 5: Perform & Measure - operate the mission and measure performance outcomes against identified metrics (Step 1). Federal EA - Consolidated Reference Model (CRM) The Consolidated Reference Model of the Federal Enterprise Architecture Framework (FEAF) equips the Office of Management and Budget (OMB) and Federal agencies with a common language and framework to describe and analyze investments. Federal EA - Reference Models The Performance Reference Model (PRM) links agency strategy, internal business components, and investments, providing a means to measure the impact of those investments on strategic outcomes. The Business Reference Model (BRM) describes an organization through a taxonomy of common mission and support service areas instead of through a stove-piped organizational view, thereby promoting intra- and inter-agency collaboration. The Data Reference Model (DRM) facilitates discovery of existing data holdings residing in “silos” and enables understanding the meaning of the data, how to access it, and how to leverage it to support performance results. Federal EA - Reference Models The Application Reference Model (ARM) categorizes the system- and application- related standards and technologies that support the delivery of service capabilities, allowing agencies to share and reuse common solutions and benefit from economies of scale. The Infrastructure Reference Model (IRM) categorizes the network/cloud related standards and technologies to support and enable the delivery of voice, data, video, and mobile service components and capabilities. The Security Reference Model (SRM) provides a common language and methodology for discussing security and privacy in the context of federal agencies’ business and performance goals. Federal EA - Core Artefacts Gartner EA Framework Gartner EA Framework Gartner: After acquiring The Meta Group in 2005, Gartner established best practices for EAP and adapted them into the company’s general consulting practices. While it’s not an individual framework, CompTIA recognizes it as a “practical” methodology that focuses on business outcomes with “few explicit steps or components.” Environmental Trends Economic climate Identify relevant environmental conditions as input to the business Customer market demand strategy and EA future-state Regulation and other legalities developments. Geography A technology trend document should be Political conditions created — and updated at least annually — as a deliverable to senior IT Culture and business managers to inform them Labor of relevant macrotechnology trends and their potential implications on the Technology enterprise. Business Strategy VIsion, mission, strategies and goals of the enterprise Organize Architecture Effort Scoping the EA program and the next iteration Gaining executive sponsorship and support Conducting stakeholder analysis Identifying the EA leader or chief architect Building and chartering the "EA team," Assessing organizational readiness and EA maturity Developing an initial communications plan Establishing a plan for setting up a governance mechanism Defining measures of success to articulate value delivered Future-State Architecture Translate business strategy into a set of prescriptive guidance to be used by the organization (business and IT) in projects that implement change. 1. Requirements — Express the needs of the enterprise 2. Principles — Provide high-level guidance for decision making 3. Models — Illustrate future-state architecture in greater detail to guide more- detailed decision making Current-State Architecture — Documenting Provide an initial baseline to compare against the future state Help identify dysfunctions, duplications, complexity and dependency Facilitate continual updating of infrastructure documentation Serve as reference material Closing the Gap Inputs: Steps: Business solution requirements Identify and classify gaps (cultural, structural from the common requirements vision and functional) Conceptual architecture principles Analyze gaps — Different tools are used to understand the difference between the current Future-state specifications state and the target. Future-state architecture models and artifacts Develop recommendations — Actions are proposed to close the gaps. Documentation of the current- state architecture Prioritize recommendations — Illustrations of interdependencies and priorities are completed to fulfill the recommendations to close the gaps Governing and Managing Governing EA Artifact Creation Governing EA Compliance and Project/Procurement Management Managing the EA repository and its contents The Open Group Architectural Framework (TOGAF) The Open Group Architectural Framework (TOGAF) The TOGAF® standard is an open, industry consensus framework for Enterprise Architecture. It is a foundational framework, which means that it is applicable to the development of any kind of architecture in any context. This foundational framework is supplemented by The Open Group TOGAF Library, an extensive and growing portfolio of guidance material, providing practical guidance in the application of the TOGAF framework in specific contexts. TOGAF - Architecture Development Method (ADM) Cycle Preliminary phase A. Architecture Vision B. Business Architecture C. Information System Architecture D. Technology Architecture E. Opportunities and Solutions F. Migration Plan G. Implementation Governance H. Architecture Change Management Requirements Management TOGAF - Architecture Development Method (ADM) Architecture Vision: high-level vision of the principles, capabilities and business value of the desired EA Business architecture: includes information on business strategy, governance, organization and how to adapt any existing processes within the organization. Applications architecture: a blueprint for structuring and deploying application systems and in accordance with business goals, other organizational frameworks and all core business processes. Data architecture: defining the organization’s data storage, management and maintenance, including logical and physical data models. Technical architecture: also called technology architecture; it describes all necessary hardware, software and IT infrastructure involved in developing and deploying business applications. TOGAF - Architecture Development Method (ADM) Opportunity and Solutions: includes the Architecture Roadmap, transition architectures and the overall solution building blocks to finalize Target Architecture Migration Planning: Coordinate the Implementation and Migration Plan with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio, ensuring business value is delivered Implementation Governance: Ensure conformance with the Target Architecture by implementation projects and perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests Architecture Change Management: Ensure that the architecture lifecycle is maintained using the Architecture Governance Framework. Ensuring that the Enterprise Architecture Capability meets current requirements while managing risks. Requirements Management: Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases REFERENCES https://www.zachman.com/resources/ea-articles-reference/327-the-framework-for-enterprise-architecture- background-description-and-utility-by-john-a-zachman https://www.cio.com/article/193229/what-is-the-zachman-framework-a-matrix-for-managing-enterprise-arc hitecture.html https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/egov_docs/fea_v2.pdf http://www3.cis.gsu.edu/dtruex/courses/CIS8090/2013Articles/Gartner%20Enterprise%20Architecture%2 0Process%20Evolution%202005.pdf https://www.cio.com/article/228328/what-is-togaf-an-enterprise-architecture-methodology-for-business.htm l