9498336
Description
| Question | Answer |
| Architecture Repository Objectives | 1. Purpose of the Architecute Repository 2. Its constituent parts 3. Its relationship to other parts of TOGAF |
| Architecture Repository Purpose (1/2) | 1. Effective management and leverage of arhitectural output requires a formal taxonomy for different types of architectural assest |
| Architecture Repository Purpose (2/2) | 2. TOGAF provides a structural framework for an Architecture Repository 3. This is on part of a wider Enterprise Repository |
| Architecture Repository Parts (1/3) | 1. Architecture Metamodel: describes the architecure framework in use within the Enterprise 2. Architecture Landscape: shows the state of the operating Enterprise at particular points in time |
| Architecture Repository Parts (2/3) | 3. Reference Library: contains re-usable architecture work products. 4. Standars Information Base: defines the compliance critecria for work governed by architecture |
| Architecture Repository Parts (3/3) | 5. Governance Log: captures results of governance activity, such as compliance 6. Architecture Capability describes the organisation, roles, skills and responsabilitites of the EA practice |
| Architecture Repository Architecture Landscape (1/3) | 1. Strategic Architectures: 1.1 Show a long-term summary view of the entire enterprise 1.2 Provide an organization framework for operational and change activity and allow for direction setting at an executed level |
| Architecture Repository Architecture Landscape (2/3) | 2. Segment Architectures: 2.1 Provide more detailed operating models for areas within an enterprise 2.2 Can be used at the program or portfolio level to organize and operationally align more detailed change activity |
| Architecture Repository Architecture Landscape (3/3) | 3. Capability Architectures: 3.1 Show in detail how the enterp. can support a particular capability 3.2 Provide overview of current capability increments and allow for individual work packages and projects to be grouped within managed portfolios and programs |
| Architecture Repository Reference Library (1/2) | 1. A repository area to hold best practice or template materials that can be used to construct architectures within an enterprise. |
| Architecture Repository Reference Library (2/2) | 2. Reference materials held in the Reference Library, some sources are: 2.1 - Standars Bodies 2.2 - Product and service vendors 2.3 Industry community & forums 2.4 Corporately defined temoplates 2.5 Best practices from project implemntn |
| Architecture Repository Standars Information Base (1/3) | 1. A repository area to hold a set of specifications to wich architectures must conform |
| Architecture Repository Standars Information Base (2/3) | 2. Establishment of a SIB provides an unambiguos basis for arch. governance since: 2.1 The standars are easily accesible to projects and therefore the obligations of the project can be understood and planned for |
| Architecture Repository Standars Information Base (3/3) | 2.2 Standards are stated in a clear and unambiguos manner, so that compliance can be objectively assessed |
| Architecture Repository Standars Information Base - Types | Types of Standar: 1. Legal and Regulatory 2. Industry 3. Organizational |
| Architecture Repository Standars Information Base - Lifecycle | Standars Lifecycle: 1. Trial 2. Active 3. Deprecated 4. Obsolete |
| Architecture Repository Standars Classification (1/4) | Business Standards: 1. Standard shared business function 2. Standard role and actor definitions 3. Security and Governance standards for business activity |
| Architecture Repository Standars Classification (2/4) | Applications Standards: 1. Standard/Shared applications supporting specific business functions 2. Standards for application communication and interoperation 3. Standards for access, presentation and style |
| Architecture Repository Standars Classification (3/4) | Data Standards: 1. Standad coding and values dor data 2. Standard structures and formats for data 3. Standards for origin and ownership of data 4. Restriction on replication and access |
| Architecture Repository Standars Classification (4/4) | Technology Standars: 1. Standard hardware products 2. Standard software products 3. Standard for software development |
| Architecture Repository Governace Log (1/2) | 1. A repositoty area to hold shared information relating to the ongoing governance of projects |
| Architecture Repository Governace Log (2/2) | 2. Maintanig a shared repository of governace information is important since: 2.1 Decisions made during projects are important to retain and access on an ongoing basis 2.2 Many Stakeholders are interested in the outcome of project governance |
| Architecture Repository Governace Log - Contents | 1. Decision Log 2. Calendar 3. Comliance Assessments 4. Project Portfolio 5. Capability Assessments 6. Performance Measurement |
| Architecture Repository Relationship to other parts of TOGAF | 1. The ADM has reminders when to use assets from the Arch. Repository 2. The Arch. Repository is a model for a physical instance of the Enterprise Continuum |
| Architecture Governance Introduction (1/2) | Archcitecture Governance Include: 1. Controls ont he creation and monitoring of components and activities - ensuring introducction, implementation, and evolution of architectures |
| Architecture Governance Introduction (1/2) | 2. Ensuring compliance with internal and external standards and regulatory obligations 3. Supporting management of the above 4. Ensuring accountability to external and internal stakeholders |
| Architecture Governance and the ADM (1/3) | 1. Governance should be established in the Preleminary Phase - Usually an adaptation of existing governanve and support models |
| Architecture Governance and the ADM (2/3) | 2. The Architecture Board shoud ensure that the ADM is being applied correctly - Compliance to the ADM is dundamental to the governance of the Architecture |
| Architecture Governance and the ADM (3/3) | 3. Governance plays a key role in Phases G and H - The implementation and the change management activities |
| Architecture Governance Nature of Governance (1/3) | 1. Governance ensures business is conducted properly 2. It is about effective and equitable usage of resources to ensure sustainability of strategic objectives |
| Architecture Governance Nature of Governance (2/3) | 3. Basic principles of corporate governance: - Focus on the rights, roles and equitable treatment of shareholders - Disclosure and transparency - Accountability of the Board to the Shareholder |
| Architecture Governance Nature of Governance (3/3) | 4. Responsabilities of the board: - Reviewing and guiding corporate strategy - Setting and monitoring management's performance objectives |
| Architecture Governance Basic Principle (1/2) | Is the system by wich business corporations are directed and controlled |
| Architecture Governance Basic Principle (2/2) | The corporate governance structure specifies the distribution of rights and responsabilities among different participants and spells out the rules and procedures for making decisions on corporate affairs it also provides the structure to company objectives |
| Architecture Governance Levels (1/2) | The hierarchy of governance domains includes: 1. Technology Governance 2. IT Governance 3. Architecure Governance |
| Architecture Governance Levels (2/2) | Each domain may exist at multiple geographic levels: 1. Global 2. Regional 3. Local |
| Architecture Governance Framework (1/4) | 1. Cobit, open standard for control of IT 2. It was develop and promoted by the IT Governance Institution 3. COBIT provides a generally accepted standard for good IT security and control practices |
| Architecture Governance Framework (2/4) | 4. There is also a set of Management Guidelines for COBIT, includig Maturity Models, Critical Success Factors, Key Goal Indicators, and Key Performance Indicators 5. The framework can help managers to control and measure IT resources |
| Architecture Governance Framework (3/4) | 6. Phase G of the TOGAF ADM is about Implementation Governance - the realization of architecture through change projects 7. Arch Governance covers management and control of all aspects of the develppment and evolution of EA |
| Architecture Governance Framework (4/4) | 8. Arch. Governance Framework is generic and can be adapted to an existing governance environment. It helps to identify effective processes and organizational structures, so that the business responsibilities can be elucidated, communicated and managed |
| Architecture Governance Conceltual Structure (1/3) | |
| Architecture Governance Conceltual Structure (2/3) | 1. Architecture Governanceis an approach a series of processes a cultural orientation and a set of responsabilities that ensure the integrity and effectiveness of architectures |
| Architecture Governance Conceltual Structure (3/3) | 2. The split of process, content and context is key to supporting an architecture governance initiative. It allows introduction of new governace material without impacting the process and ensures framework flexibility |
| Architecture Governance Organization Structure | |
| Architecture Governance benefits of Arch. Governance (1/2) | 1. Links processes, resources and information to organization strategies and objectives 2. Integrates and instutionalizes best practices 3. Aligns with industry frameworks |
| Architecture Governance benefits of Arch. Governance (2/2) | 4. Enables the organization to take full advantage of the organization 5. Protects the underlying digital assets of the organization 6. Supports regulatory and best practice requirements 7. Promotes visible risk management |
| Architecture Governance in Practice (1/4) | Sucees factors include: 1. Best practices for submission, adoption, reuse, reporting, and retirement of architecture policies, procedures, roles, skills, organizational structures and support services |
| Architecture Governance in Practice (2/4) | 2. Organizational responsabilities and structures to support the architecture governance processes and reporting requirements 3. Tools and processes to procedurally and culturally promote take-up |
| Architecture Governance in Practice (3/4) | 4. Management of criteria to control architecture governace processes dispensations, compliance assessments, SLA's and OLA's |
| Architecture Governance in Practice (4/4) | 5. Meet internal and external requirements for effectiveness efficiency, confidentiality, integrity, availability, compliance and reliability of architecture governance-related information, services and processes |
| Architecture Governance Architecture Board (1/2) | 1. The board oversees implementation of the governance strategy 2. Board comprises of representative stakeholders, responsible for review and maintenance of architecture typically at 2 levels: Local & Global |
| Architecture Governance Architecture Board (2/2) | Board has identifiable and articuleted: 1. Responsibilities and decision making - capabilities 2. Remit and authority limits |
| Architecture Governance Architecture Board Value (1/2) | Cost is offset by preventing one-off solutions and unconstrained developments wich lead to: 1. high costs of dev., operation and support, due to numeroues run-time environments, languages, interfaces, protocols |
| Architecture Governance Architecture Board Value (2/2) | 2. Lower quality 3. Higher risk 4. Difficulty in replicating and re-using solutions |
| Architecture Governance Architecture Board Reponsabilities (1/2) | 1. Providing the basis for all decision-arch making with regard to changes to the 2. Ensuring consistency between sub-arch 3. Establishing targets for re-use of comp. 4. Ensuring flexibility of EA: 4.1 To meet changing business needs |
| Architecture Governance Architecture Board Reponsabilities (2/2) | 4.2 To leverage new technologies 5. Enforcement of Arch. Complience 6. Improving the arch. maturity level within the organization 7. Ensuring that the discipline of arch-based dev is adopted 8.Supor. escalation capability for decisions |
| Architecture Governance Architecture Board Operations | 1- Focused on best practice for meeting management. 1.1 Meetign should be conducted with clearly defined agendas 1.2 Each participant attending a meeting should be fully prepared 2. Togaf provide a sample outline agenda |
| Architecture Governance Architecture Contracts (1/3) | 1. Joint agreements between developmnet partners and sponsors on the deliverables quialify and fitness for purpose of an architecture |
| Architecture Governance Architecture Contracts (2/3) | 2. Use of Architecture Contracts ensures: 2.1 Continuous monitoring to check integrity, changes, decision making and audit of all architecture related activities 2.2 Adherence to the principles, standars, and requirements of the existing or developing architectures |
| Architecture Governance Architecture Contracts (3/3) | 2.3 Identification or Risks 2.4 A set of processes and practices that ensure accountability, responsability and discipline with regard to the dev. and usage of all arch. artifacts 2.5 A formal understanding of gov. orgaz |
| Architecture Governance Architecture Contracts & ADM | 1. The statement of Architecture Work created in the Phase A 2. Architectures Domains (Business, Data, Application, Technology) 3. Phase G 4. Implementation projects |
| Architecture Governance Architecture Compliance Terminology | 1. Irrelevant 2. Consistent 3. Compliant 4. Conformant 5. Fully Conformant 6. Non-Conformant |
| Architecture Governance Architecture Compliance Terminology Irrelevant | The implementation has no features in common with the arch. specification (so the question of conformance does not arise) |
| Architecture Governance Architecture Compliance Terminology Consistent | Implementation has some features in common with the arch. specification and and implemented in accordance with the specification. However, some features in the arch specificat. are not implemented and the implementation has other features not covered by the specification |
| Architecture Governance Architecture Compliance Terminology Compliant | Some features in the arch, specification are NOT implemented but all features implemented are covered by the specification and in accordance with it |
| Architecture Governance Architecture Compliance Terminology Conformant | Some features in the arch, specification are implemented in accordance with the specification but some more features are implemented that are not in accordance with it |
| Architecture Governance Architecture Compliance Terminology Fully Conformant | There is full correspondace between architecture specification and implementation. All specified features are implemented in accordance with the specification and there are no features implemented that are not covered by the specification |
| Architecture Governance Architecture Compliance Terminology Non Conformant | Any of the above in wich some features in the architecture specification are implemented not in accordance with the specification |
| Architecture Governance Architecture Compliance | Two processes are defined to ensure compliance of projects with the EA: 1. Prepare Project Impact Assessment "views that illustrate how the EA impact" 2. Perform an Arch. Compliance Review |
| Architecture Governance Architecture Compliance Reviews (1/3) | 1.Catch errors in the preject arch early 2.Aplication of best practices to arch. work 3.Overview of the compliance to standars 4.Identify where standards themselves may require modifications |
| Architecture Governance Architecture Compliance Reviews (2/3) | 5. Identify services that are currently application-specific but might be provided as part of the EA infraestructure 6. Document strategies for collaboration, resource sharing and other synergies across multiple arch. teams 7. Take advantage of advances in Technolgy |
| Architecture Governance Architecture Compliance Reviews (3/3) | 8. Communicate to management the status of technical readiness of the project 9. Identify key criteria for procurement activities 10. Identify and communicate significant architectural gaps to product and service providers |
| Architecture Governance Architecture Compliance Review Process | |
| Architecture Governance Establishing an Architecture Capability (1/3) | Guideliness to establish an EA capability: 1. Use of the ADM 2. Treat is as an ongoing practice 3. Address the four domain architectures 3.1 Business Architecture: arc. governance, process, organizational estructure, information requeriments, products |
| Architecture Governance Establishing an Architecture Capability (2/3) | 3.2 Data Architecture: the structure of the organizaiton's Enterprise Continuum and Architeture Repository 3.3 Application Architecture: the functionallaty and/or application services required to enable the architecture practice |
| Architecture Governance Establishing an Architecture Capability (3/3) | 3.4 Technology Architecture: Infraestructure requirements and deployment in support of the architecture applications and Enterprise Continuum |
| Reference Models Objectives | Introduce the two Togaf Reference Models: 1. Technical Reference Model (TRM) 2. Integrated Information Infraestructure Reference Model (III-RM) And the relationship of the III-RM to the concept of Boundaryless Information Flow |
| Reference Models Foundation Architectures (1/2) | Is an architecture of builfing blocks and corresponding standars that supprts all the Common System Architectures and therefore the complete enterprise operating environment |
| Reference Models Foundation Architectures (2/2) | 1. Togaf provides the TRM as a Foundation Architecture 2. ADM supports specialization of such Foundation Arch. in order to create organization-specific models 3. TRM is an example of a FounArch. on wich other specific arch. can be based |
| Reference Models The Architecture Continuum Diagram | |
| Reference Models TRM Components Diagram | |
| Reference Models Summary of TRM | |
| Reference Models Integrated Information Infraestructure Reference Model (1/2) | 1. A model of the key components for developing, managinf and operating an integrated information infraestructure "Supporg. Boundaryless Information Flow" 2. A model of a set of applications that sit on top of an application platform |
| Reference Models Integrated Information Infraestructure Reference Model (2/2) | 3. An Expanded subset of the TOGAF Technical Reference Model using different orientation |
| Reference Models Common System Architectures Integrated Informatin Infraestructure Reference Model - High Level Model |
Image:
Iirm (binary/octet-stream)
|
| Reference Models III-RM Components | 1. A taxonomy wich defines terminology and provides a coherent description of the compnts and concepual structure of an III 2. Asociated III-RM graphic, wich provides a visual representation of the taxonomy and the inter-relationship of the compnts. |
| Building Blocks | - 2 Types: 1. Architecture Building Blocks 2. Solution Building Blocks - Systems are built from collections of building blocks - They can be defined at many levels of detail |
| Building Blocks Architecure Building Blocks | 1. Architecture documentation and models from the enterprise Architecture Continuum 2. They are defined or selecting during application of the ADM, mainly in phases A,B,C & D |
| Building Blocks Architecure Building Blocks Characteristics | 1. They define what functionallity will be implemented 2. They capture business and technical requirements 3. They direct and guide the development of Solution Building Blocks |
| Building Blocks Solutino Building Blocks | 1. Solution Bulding Blocks relate to the Solution Continuum 2. They can either be procured or developed |
| Building Blocks Solutino Building Blocks Characteristics | 1. They define what products and components will implement the functionality 2. They fulfil business requirements 3. They are product or vendor aware |
| Solution Building Blocks Specifications (1/2) | 1. Specific funcitonality and attributes 2. Interfaces: the implemented set 3. Requiered SBBs used with required func. and names or interfaces used 4. Mapping from the SBBs to the IT topology and operational policies 5. Specification of attributes shared such as security, manageability, scalability |
| Solution Building Blocks Specifications (2/2) | 6. Specifications of attributes shared such as security, manageability, scability 7. Performance, configurability 8. Designdrivers and constraints including physical architecture 9.relationship between the SBB and ABB |
| Building Blocks and the ADM (1/3) | 1. An architecture is a set of building blocks -Depicted in an architectural model -A specification of how those building blocks are connected to meet the overall requirements of an information system |
| Building Blocks and the ADM (2/3) | 2. The various building blocks in an architecture specify the services required in an enterprise specific system |
| Building Blocks and the ADM (3/3) | 3. General principles should apply: -An architecture need only contain BB to implement those serivces it requires - BB may implement one, more than one, or only part of a sevice indetif. in the arch. -BB shoul conform to standards |
| Building Blocks and the ADM Phase A | In phase A we start with abstract entities - A high level model of candidate building blocks |
| Building Blocks and the ADM Phase B, C and D Step 1 | Building Blocks within the Business, Data, Applications and Technology Architectures are evolved to a common pattern of steps Step 1: Select Reference Models, Viewpoints and Tools |
| Building Blocks and the ADM Phase B, C and D Step 2 | Step 2: Develop a high-level model of existing building blocks, re-using definitions from the Architecture Repository where they are available |
| Building Blocks and the ADM Phase B, C and D Step 3 (1/2) | Step 3: Develop view of required BB through catalogs, matrices and diagrams -Fully document each building block -Document rationale for building blocks -Identify the impacted BB within the Arch. Repository, reusing where appropiate |
| Building Blocks and the ADM Phase B, C and D Step 3 (2/2) | -Where necessary, define new BB's -Select standards for each BB -Document mapping of building blocks to Architecture Landscape -Identify BB for re-use, publish as either standards or reference models |
| Building Blocks and the ADM Phase B, C and D Step 4 | Step 4: Perform Gap Analysis -Identify BB carried over -Identify eliminated BB -Identify new BB -Identify gaps and determine realization approach |
| Building Blocks and the ADM Phase B, C and D Step 5-9 | S5: Define candidate Roadmap Components S6: Resolve Impacts across the Arch. Landscape S7: Formal Stakeholder review S8: Finalize the Arch. S9: Create the Arch. Definition Document |
| Building Blocks and the ADM Phase E | Associate BB wit work packages that will address the gaps BBs in ABB and SBB forms |
| Building Blocks Architecture Patterns (1/2) | Pattern: Defined as "an idea that has been useful in one practical context and will probably be useful in others" |
| Building Blocks Architecture Patterns (2/2) | - In TOGAF, patterns are considered to be a way of putting BB into context; for exameple to describe a reusable solution to a problem - BB are what you use: patterns can tell you how you use them, when, why & what tradeoffs you have to make in doing so |
0 comments
Want to create your own Flashcards for free with GoConqr? Learn more.