O GoConqr está de visual novo! Conte para nós o que você achou.

Registre-se grátis

Flashcards

Architecture Repository, Governance Level 1

Juda Osejo TOGAF 9.1 TOGAF v1-2 Espanhol 106 flashcards

Architecture Repository, Governance Level 1

Flashcards do conjunto (106)

  1. 1Architecture Repository Objectives1. Purpose of the Architecute Repository
    2. Its constituent parts
    3. Its relationship to other parts of TOGAF
  2. 2Architecture Repository Purpose (1/2)1. Effective management and leverage of arhitectural output requires a formal taxonomy for different types of architectural assest
  3. 3Architecture Repository Purpose (2/2)2. TOGAF provides a structural framework for an Architecture Repository
    3. This is on part of a wider Enterprise Repository
  4. 4Architecture 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
  5. 5Architecture 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
  6. 6Architecture 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
  7. 7Architecture 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
  8. 8Architecture 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
  9. 9Architecture 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
  10. 10Architecture 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.
  11. 11Architecture 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
  12. 12Architecture Repository Standars Information Base (1/3)1. A repository area to hold a set of specifications to wich architectures must conform
  13. 13Architecture 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
  14. 14Architecture Repository Standars Information Base (3/3)2.2 Standards are stated in a clear and unambiguos manner, so that compliance can be objectively assessed
  15. 15Architecture Repository Standars Information Base - TypesTypes of Standar:
    1. Legal and Regulatory
    2. Industry
    3. Organizational
  16. 16Architecture Repository Standars Information Base - LifecycleStandars Lifecycle:
    1. Trial
    2. Active
    3. Deprecated
    4. Obsolete
  17. 17Architecture 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
  18. 18Architecture 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
  19. 19Architecture 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
  20. 20Architecture Repository Standars Classification (4/4)Technology Standars:
    1. Standard hardware products
    2. Standard software products
    3. Standard for software development
  21. 21Architecture Repository Governace Log (1/2)1. A repositoty area to hold shared information relating to the ongoing governance of projects
  22. 22Architecture 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
  23. 23Architecture Repository Governace Log - Contents1. Decision Log
    2. Calendar
    3. Comliance Assessments
    4. Project Portfolio
    5. Capability Assessments
    6. Performance Measurement
  24. 24Architecture Repository Relationship to other parts of TOGAF1. 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
  25. 25Architecture 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
  26. 26Architecture 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
  27. 27Architecture Governance and the ADM (1/3)1. Governance should be established in the Preleminary Phase
    - Usually an adaptation of existing governanve and support models
  28. 28Architecture 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
  29. 29Architecture Governance and the ADM (3/3)3. Governance plays a key role in Phases G and H
    - The implementation and the change management activities
  30. 30Architecture 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
  31. 31Architecture 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
  32. 32Architecture Governance Nature of Governance (3/3)4. Responsabilities of the board:
    - Reviewing and guiding corporate strategy
    - Setting and monitoring management's performance objectives
  33. 33Architecture Governance Basic Principle (1/2)Is the system by wich business corporations are directed and controlled
  34. 34Architecture 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
  35. 35Architecture Governance Levels (1/2)The hierarchy of governance domains includes:
    1. Technology Governance
    2. IT Governance
    3. Architecure Governance
  36. 36Architecture Governance Levels (2/2)Each domain may exist at multiple geographic levels:
    1. Global
    2. Regional
    3. Local
  37. 37Architecture 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
  38. 38Architecture 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
  39. 39Architecture 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
  40. 40Architecture 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
  41. 41Architecture Governance Conceltual Structure (1/3)Architecture Governance Conceltual Structure (1/3)
  42. 42Architecture 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
  43. 43Architecture 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
  44. 44Architecture Governance Organization StructureArchitecture Governance Organization Structure
  45. 45Architecture 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
  46. 46Architecture 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
  47. 47Architecture 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
  48. 48Architecture 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
  49. 49Architecture Governance in Practice (3/4)4. Management of criteria to control architecture governace processes dispensations, compliance assessments, SLA's and OLA's
  50. 50Architecture 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
  51. 51Architecture 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
  52. 52Architecture Governance Architecture Board (2/2)Board has identifiable and articuleted:
    1. Responsibilities and decision making - capabilities
    2. Remit and authority limits
  53. 53Architecture 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
  54. 54Architecture Governance Architecture Board Value (2/2)2. Lower quality
    3. Higher risk
    4. Difficulty in replicating and re-using solutions
  55. 55Architecture 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
  56. 56Architecture 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
  57. 57Architecture Governance Architecture Board Operations1- 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
  58. 58Architecture Governance Architecture Contracts (1/3)1. Joint agreements between developmnet partners and sponsors on the deliverables quialify and fitness for purpose of an architecture
  59. 59Architecture 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
  60. 60Architecture 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
  61. 61Architecture Governance Architecture Contracts & ADM1. The statement of Architecture Work created in the Phase A
    2. Architectures Domains (Business, Data, Application, Technology)
    3. Phase G
    4. Implementation projects
  62. 62Architecture Governance Architecture Compliance Terminology1. Irrelevant
    2. Consistent
    3. Compliant
    4. Conformant
    5. Fully Conformant
    6. Non-Conformant
  63. 63Architecture Governance Architecture Compliance Terminology IrrelevantThe implementation has no features in common with the arch. specification (so the question of conformance does not arise)
  64. 64Architecture Governance Architecture Compliance Terminology ConsistentImplementation 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
  65. 65Architecture Governance Architecture Compliance Terminology CompliantSome features in the arch, specification are NOT implemented but all features implemented are covered by the specification and in accordance with it
  66. 66Architecture Governance Architecture Compliance Terminology ConformantSome 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
  67. 67Architecture Governance Architecture Compliance Terminology Fully ConformantThere 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
  68. 68Architecture Governance Architecture Compliance Terminology Non ConformantAny of the above in wich some features in the architecture specification are implemented not in accordance with the specification
  69. 69Architecture Governance Architecture ComplianceTwo 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
  70. 70Architecture 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
  71. 71Architecture 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
  72. 72Architecture 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
  73. 73Architecture Governance Architecture Compliance Review ProcessArchitecture Governance Architecture Compliance Review Process
  74. 74Architecture 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
  75. 75Architecture 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
  76. 76Architecture Governance Establishing an Architecture Capability (3/3)3.4 Technology Architecture: Infraestructure requirements and deployment in support of the architecture applications and Enterprise Continuum
  77. 77Reference Models ObjectivesIntroduce 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
  78. 78Reference 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
  79. 79Reference 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
  80. 80Reference Models The Architecture Continuum DiagramReference Models The Architecture Continuum Diagram
  81. 81Reference Models TRM Components DiagramReference Models TRM Components Diagram
  82. 82Reference Models Summary of TRMReference Models Summary of TRM
  83. 83Reference 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
  84. 84Reference Models Integrated Information Infraestructure Reference Model (2/2)3. An Expanded subset of the TOGAF Technical Reference Model using different orientation
  85. 85Reference Models Common System Architectures Integrated Informatin Infraestructure Reference Model - High Level ModelReference Models Common System Architectures Integrated Informatin Infraestructure Reference Model - High Level Model
  86. 86Reference Models III-RM Components1. 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.
  87. 87Building 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
  88. 88Building Blocks Architecure Building Blocks1. 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
  89. 89Building Blocks Architecure Building Blocks Characteristics1. 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
  90. 90Building Blocks Solutino Building Blocks1. Solution Bulding Blocks relate to the Solution Continuum
    2. They can either be procured or developed
  91. 91Building Blocks Solutino Building Blocks Characteristics1. They define what products and components will implement the functionality
    2. They fulfil business requirements
    3. They are product or vendor aware
  92. 92Solution 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
  93. 93Solution 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
  94. 94Building 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
  95. 95Building Blocks and the ADM (2/3)2. The various building blocks in an architecture specify the services required in an enterprise specific system
  96. 96Building 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
  97. 97Building Blocks and the ADM Phase AIn phase A we start with abstract entities
    - A high level model of candidate building blocks
  98. 98Building Blocks and the ADM Phase B, C and D Step 1Building 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
  99. 99Building Blocks and the ADM Phase B, C and D Step 2Step 2: Develop a high-level model of existing building blocks, re-using definitions from the Architecture Repository where they are available
  100. 100Building 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
  101. 101Building 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
  102. 102Building Blocks and the ADM Phase B, C and D Step 4Step 4: Perform Gap Analysis
    -Identify BB carried over
    -Identify eliminated BB
    -Identify new BB
    -Identify gaps and determine realization approach
  103. 103Building Blocks and the ADM Phase B, C and D Step 5-9S5: 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
  104. 104Building Blocks and the ADM Phase EAssociate BB wit work packages that will address the gaps
    BBs in ABB and SBB forms
  105. 105Building 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"
  106. 106Building 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

Informações

Descrição
Architecture Repository Level 1 Governance Level 1
Criado por
Juda Osejo
Visualizações
53
Avaliação

Fale Conosco

Sobre o que é sua mensagem?

O que você acha do novo visual?

Você gostou?