GoConqr has a new look! Let us know what you think.

Sign up free

Flashcards

Core Concepts Phase D - Requirements Management Level 2

Juda Osejo TOGAF 9.1 TOGAF v1-2 Spanish 86 cards

Cards in this deck (86)

  1. 1Phase D Technology Architecture1. The fundamental organization of an IT system, embodied in its hardware, software and Communications technology
    2. Their relationships to each other and the environment, and the principies
    governing its design and evolution
  2. 2Phase D Technology Architecture Objectives (1/2)1. Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns
  3. 3Phase D Technology Architecture Objectives (2/2)2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures
  4. 4Phase D Technology Architecture Using Architecture RepositoryReview the Resources available:
    1. Existing IT Services in the IT Repository or IT Service Catalog
    2. The TOGAF TRM
    3. Technology models relevant to the organization
  5. 5Phase D Technology Architecture Catalogs1. Technology Standards catalog
    2. Technology Portfolio catalog
  6. 6Phase D Technology Architecture Technology Standards catalog (1/2)1. Documents the agreed standards for tech. across the enterprise covering tech., and versions, the tech. lifecycles, and the refresh cycles for the technology.
  7. 7Phase D Technology Architecture Technology Standards catalog (2/2)2. Itcan be implemented as an extension to the Technology Portfolio Catalog and thus will share the same metamodel entities:
    - Platform Service
    - Logical Technology Component
    - Physical Technology Component
  8. 8Phase D Technology Architecture Matrices1. Application/Technology matrix
  9. 9Phase D Technology Architecture Application/Technology matrix (1/2)1. Documents the mapping
    of applications to the technology platform.
    2. The Matrix Shows:
    2.1 Logical/Physical Application Components
  10. 10Phase D Technology Architecture Application/Technology matrix (2/2)2.2 Services, Logical Technologhy Components, and Physical Technology Components
    2.3 Physical Technology Component realizes Physical Application Component relationships
  11. 11Phase D Technology Architecture Diagrams1. Environments and Locations
    2. Platform Decomposition
    3. Processing
    4. Networked Computing/Hardware
    5. Communications Engineering
  12. 12Phase D - Technology Architecture Environments and Locations Diagram1. Shows which locations host which apps
    2. Identifies what technologies and/or applications are used at which locations
    3. Identifies the locations from which buss users typically interact with the apps
  13. 13Phase D - Technology Architecture Environments and Locations Diagram4. Show the existence and location of different deployment environments
    - including non-production environments
  14. 14Phase D - Technology Architecture Platform Decomposition Diagram1. Shows the tech. platform that supports the operations of the Information Systems Architecture
    2. The diagram covers all aspects of the infrastructure platform and provides an overview of the enterprise's tech. platform
  15. 15Phase D - Technology Architecture Processing Diagram (1/3)1. Focuses on deployable units of code/configuration and how these are deployed onto the technology platform.
    2. Addresses the following:
    2.1 Which set of application components need to be grouped to form a deployment unit
  16. 16Phase D - Technology Architecture Processing Diagram (2/3)2.2 How one deployment unit connects/interacts with another (LAN, WAN, and the applicable protocols)
    2.3 How app configuration and usage patterns generate load or capacity requirements for different tech. components
  17. 17Phase D - Technology Architecture Processing Diagram (2/3)3. The organization and grouping of deployment units depends on separation concerns of the presentation, business logic, and data store layers and service-level requirements of the components.
  18. 18Phase D - Technology Architecture Network Computing/Hardware Diagram (1/3)1. Show the "as deployed" logical view of
    logical app components in a distributed network computing environment
    2. The diagram is useful for:
    2.1 Enable understanding of which application is deployed where
  19. 19Phase D - Technology Architecture Network Computing/Hardware Diagram (2/3)2.2 Establishing authorization, security, and access to these technology components
    2.3 Understand the Technology Architecture that support the apps during
    problem resolution and troubleshooting
    2.4 Identify areas of optimization
  20. 20Phase D - Technology Architecture Network Computing/Hardware Diagram (3/3)2.5 Isolate performance problems encountered and perform necessary upgrade to specific physical tech components
  21. 21Phase D - Technology Architecture Communications Engineering Diagram (1/2)1. Describes the means of communication between assets in the Technology Arch.
    2. It does not describe the information format or content, but addresses protocol and capacity issues.
  22. 22Phase D - Technology Architecture Communications Engineering Diagram (2/2)3. It takes logical connections between client and server components and identifies network boundaries and network infrastructure required to physically implement those connections.
  23. 23Phase D - Technology Architecture Architecture Definition Document - Technology Architecture Components (1/3)1. Baseline Tech. Arch., if appropriate
    2. Target Tech. Arch., including:
    2.1 Tech components and their relationships to information systems
  24. 24Phase D - Technology Architecture Architecture Definition Document - Technology Architecture Components (2/3)2.2 Tech platforms and their decomposition, showing the combinations of tech required to realize a particular technology "stack"
    2.3 Environments and locations - a grouping of the required technology into
    computing environments
  25. 25Phase D - Technology Architecture Architecture Definition Document - Technology Architecture Components (3/3)2.4 Expected processing load and distribution of load across tech compnts
    2.5 Physical (network) Communications
    2.6 Hardware and network specifications
    3. Views corresponding to the selected viewpoints addressing key stakeholder concerns
  26. 26Phase D - Technology Architecture Architecture Requirements Specification - Technology Architecture Components1. Gap analysis results
    2. Updated technology requirements
  27. 27Phase E - Opportunities and Solutions1. Perform initial implementation planning
    2. Identify the major implemtation projects
    3. Group changes into work packages
    4. Decide on approach (Make, Rebuild, COTS, Open Source)
    5. Assess priorities, 6.Identify dependecies
  28. 28Phase E - Opportunities and Solutions Objectives (1/2)1. Generate the initial complete versión of the Arch. Roadmap, based upon the gap analysis and candidate Arch. Roadmap components from Phases B, C, & D
  29. 29Phase E - Opportunities and Solutions Objectives (2/2)2. Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver
    continuous business value
  30. 30Phase E - Opportunities and Solutions Approach (1/4)1. This is the first phase concerning implementation
    2. It takes into account the complete set of gaps between the Target and Baseline Architectures in all architecture
    domains
  31. 31Phase E - Opportunities and Solutions Approach (2/4)3. It logically groups changes into work packages
    4. It builds a best-fit roadmap based upon:
    4.1 Stakeholder requirements
    4.2 The enterprise's business transformation readiness
  32. 32Phase E - Opportunities and Solutions Approach (3/4)4.3 Identified opportunities and solutions
    4.4 Identified implementation constraints
    5. Four concepts are key to transitioning from developing to delivering a Target Architecture:
  33. 33Phase E - Opportunities and Solutions Approach (4/4)5.1 Architecture Roadmap
    5.2 Work Packages
    5.3 Transition Architectures
    5.4 Implementation and Migration Plan
  34. 34Phase E - Opportunities and Solutions Steps (1/3)1. Determine corporate change attributes
    2. 2. Determine business constraints for implementation
    3. Review and consolidate gap analysis results from Phases B to D
  35. 35Phase E - Opportunities and Solutions Steps (2/3)4. Review Consolidated requirements across related business functions
    5. Consolidate and reconcile interoperability requirements
    6. Refine and validate dependencies
    7. Confirm readiness and risk for business transformation
  36. 36Phase E - Opportunities and Solutions Steps (3/3)8. Formulate Implementation & Migration
    Strategy
    9. Identify and group major work packages
    10. Identify Transition Architectures
    11. Create Architecture Roadmap &
    Implementation and Migration Plan
  37. 37Phase E - Migration Planning1. For work packages and projects identified in Phase E perform
    - Cost/benefit analysis
    - Risk assessment
    2. Develop a detailed Implementation and
    Migration Plan
  38. 38Phase E - Migration Planning Objectives (1/2)1. Finalize the Arch. Roadmap and the supporting Implementation and Migration Plan
    2. Ensure that the Implementation and Migration Plan is coordinated with the enterprise's approach to managing the enterprise's overall change portfolio
  39. 39Phase E - Migration Planning Objectives (2/2)3. Ensure that the business valué and cost of work packages and Transition Architectures is understood by key
    stakeholders
  40. 40Phase E - Migration Planning Steps (1/3)1. Confirm management framework interactions for the Implementation & Migration Plan
    2. Assign a business value to each work package
  41. 41Phase E - Migration Planning Steps (2/3)3. Estimate resource requirements, project timings, and availability/delivery vehicle
    4. Prioritize migration projects through the conduct of a cost/benefit assessment and risk validation
  42. 42Phase E - Migration Planning Steps (3/3)5. Confirm Architecture Roadmap and Architecture Definition Document
    6. Complete the Implementation & Migration Plan
    7. Complete the architecture development
    cycle and document lessons learned
  43. 43Phase G - Implementation Governance (1/2)1. Provide architectural oversight for the
    implementation.
    2. Defines architecture constraints on implementation projects
    3. Govern and manage an Architecture contract
  44. 44Phase G - Implementation Governance (2/2)4. Monitors implementation work for conformance
    5. Produce a Business Value Realization.
  45. 45Phase G - Implementation Governance Objectives1. Ensure conformance with the Target Architecture by implementation projects
    2. Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture
    Change Requests
  46. 46Phase G - Implementation Governance Approach (1/7)1. Phase G relates the architecture to the implementation through the Architecture Contract
    2. The information for successful management of the projects must be brought together
  47. 47Phase G - Implementation Governance Approach (2/7)3. The development happens in parallel with Phase G
    4. Establish an implementation program that will enable the delivery of the Transition Architectures agreed for
    implementation during the Migration Planning phase
  48. 48Phase G - Implementation Governance Approach (3/6)5. Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap
    6. Follow the organization's standard for corporate, IT, and architecture governance
  49. 49Phase G - Implementation Governance Approach (4/6)7. Use the organization's established portfolio/program management approach, where this exists
    8. Define an operations framework to ensure the effective long life of the deployed solution
  50. 50Phase G - Implementation Governance Approach (5/6)9. Establish the connection between the architecture and implementation organization through the Architecture
    Contract
    10. Project details are developed, including:
  51. 51Phase G - Implementation Governance Approach (6/6)10.1 Name, descriptíon, and objectives
    10.2 Scope, deliverables, and constraints
    10.3 Measures of effectiveness
    10.4 Acceptance entena
    10.5 Risks and issues
  52. 52Phase G - Implementation Governance Steps (1/2)1. Confirm scope and priorities for deployment with the development management
    2. Identify deployment resources and skills
    3. Guide development ofsolutions deployment
  53. 53Phase G - Implementation Governance Steps (2/2)4. Perform EA compliance reviews
    5. Implement business and IT operations
    6. Do post-implementation review, cióse
    the implementation
  54. 54Phase H - Architecture Change Management (1/3)1. Provide continual monitoring and a change management process
    2. Ensures that changes to the architecture are managed in a cohesive and architected
    way
  55. 55Phase H - Architecture Change Management (2/3)3. Establishes and supports the Enterprise Architecture to provide flexibility to evolve
    rapidly in response to changes in the technology or business environment
  56. 56Phase H - Architecture Change Management (3/3)4. Monitors the business and capacity management.
  57. 57Phase H - Architecture Change Objectives1. Ensure that the architecture lifecycle is maintained
    2. Ensure that the Architecture Governance Framework is executed
    3. Ensure that the enterprise Architecture Capability meets current requirements
  58. 58Phase H - Architecture Change Approach (1/3)1. The goal of an architecture change management process is to ensure that the architecture achieves its original target business value
  59. 59Phase H - Architecture Change Approach (2/3)2. This can be done by:
    2.1 Ensuring that changes to the architecture are managed properly
    2.2 Supporting a dynamic architecture.
  60. 60Phase H - Architecture Change Approach (3/3)3. The process will determine the circumstances under which:
    3.1 The architecture will be permitted to change after deployment, and the process for this.
    3.2 The ADM will be used again.
  61. 61Phase H - Architecture Change Change Management Process (1/2)There are three main categories of architecture change:
    1. Simplification: this can be handled via change management techniques.
  62. 62Phase H - Architecture Change Change Management Process (2/2)2. Incremental: this may be handled via change managementtechniques, or it may require partial rearchitecting.
    3. Re-architecting: this requires putting the whole architecture through the Arch. development cycle again.
  63. 63Phase H - Architecture Change Determine Change Management Process (1/2)1.Register all events that may impact the architecture
    2. Allocate resources and management for the architecture tasks
  64. 64Phase H - Architecture Change Determine Change Management Process (2/2)3. The process (or role) responsible for resources has to make an assessment of what should be done
    4. Evaluate the impact
  65. 65Phase H - Architecture Change Maintenance versus Redesign (1/2)If the change:
    1. Impacts 2 stakeholders or more, then it is likely to require an architecture redesign and re-entry to the ADM
  66. 66Phase H - Architecture Change Maintenance versus Redesign (2/2)2. Impacts only 1 stakeholder, then it is likely to be a candidate for change management
    3. Can be allowed under a dispensation, then it is likely to be a candidate for change management
  67. 67Phase H - Architecture Change Steps (1/2)1. Establish Value Realization process
    2. Deploy Monitoring Tools
    3. Manage Risks
    4. Provide Analysis for Architecture Change
    Management
  68. 68Phase H - Architecture Change Steps (2/2)5. Develop Change Requirements to meet
    Performance Taraets
    6. Manage Governance Process
    7. Activate the process to implement
    Change
  69. 69Phase H - Architecture Change Iteration to deveiop a comprehensive Architecture Landscape (1/2)1. Projects will exercise through the
    entire ADM cycle, commencing Phase A.
    1.1 Each cycle of the ADM is bounded
    by a Request for Architecture Work
    1.2 The output populates the
    Architecture Landscape, either
    extending or changing the landscape
  70. 70Phase H - Architecture Change Iteration to deveiop a comprehensive Architecture Landscape (2/2)2. Separate projects may operate their
    own ADM cycles concurrently, with
    relationships between them
    3. One project may trigger the initiation
    of another project.
  71. 71Phase H - Architecture Change Iteration within an ADM Cycle (1/2)1. Projects may operate multiple ADM Phases concurrently
    1.1 Typically uses to manage the inter-relationship between the Business Arch., Information Systems Arch. and Technology Arch.
  72. 72Phase H - Architecture Change Iteration within an ADM Cycle (2/2)2 Projects may cycle between phases to converge on a Target Architecture
    3. Projects may return to previous phases in order to update work products with new information
  73. 73Phase H - Architecture Change Iteration to Manage the Architecture Capability (1/2)1. Projects may require a new iteration of the Preliminary Phase to establish aspects of the Architecture capability identified in Phase A to address a Request for Architecture work
  74. 74Phase H - Architecture Change Iteration to Manage the Architecture Capability (2/2)2. Projects may require a new
    iteration of the Preliminary Phase to establish aspects of the Architecture capability identified in Phase A to address
    a Request for Architecture work
  75. 75Phase H - Architecture Change Factors Influencing the use of Iteration (1/2)1. The formality and nature of established checkpoints within the organization
    2. The level of stakeholder involvement expected within the process
    3. The number of teams involved and the relationships between different teams
  76. 76Phase H - Architecture Change Factors Influencing the use of Iteration (2/2)4. The maturity of the solution area and expected rework to arrive at an acceptable solution
    5. Attitude to risk
  77. 77ADM Requirements ManagementThe process of managing architecture requirements:
    1. Applies to all phases of the ADM cycle
    2. Is central to the ADM process
    3. Is a dynamic process addressing the identification of requirements, their storage and delivery to the phases
  78. 78ADM Requirements Management Requirements Development (1/4)1. The first high level requirements are developed in the Architecture Vision
    2. For each ADM phase, from Preliminary to Phase H
  79. 79ADM Requirements Management Requirements Development (2/4)2.1 Select the approved requirements for that phase as held in the Requirements Repository and Arch. Requirements Specification
    2.2 At the completion of a phase the status of all such requirements needs to be updated
  80. 80ADM Requirements Management Requirements Development (3/4)3. During phase execution
    3.1 New requirements generated for future architecture work within the scope of the current Statement of Architecture Work need to be documented within the Architecture Requirements Specification
  81. 81ADM Requirements Management Requirements Development (4/4)3.2 New requirements which are outside of the scope of the current Statement of Architecture Work must be input to the Requirements Repository for management through the Requirements Management process
  82. 82ADM Requirements Management Objectives (1/2)1. Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
    2. Manage architecture requirements identified during any execution of the ADM cycle or a phase
  83. 83ADM Requirements Management Objectives (2/2)3. Ensure that the relevant architecture requirements are available for use by each phase as the phase is executed
  84. 84ADM Requirements Management Approach (1/2)1. The ability to deal with changes in the requirements is crucial to the ADM process since architecture deals with uncertainty and change
    2. Architecture bridges the divide between the aspirations of the stakeholders and a practical solution
  85. 85ADM Requirements Management Approach (2/2)3. The Requirements Management process does not dispose of, address or prioritize requirements; this is done within the phases of the ADM
    4. It is recommended that a Requirements Repository is used to record and manage all arch. requirements
  86. 86ADM Requirements Management Resources1. TOGAF specifies generic needs for requirements, not specific tools or processes
    2. It recommends use of
    2.1 Business Scenarios
    2.2 Commercial off the shelf tools

Information

Description
Phase D Level 2 Phase E Level 2 Phase F Level 2 Phase G Level 2 Phase H Level 2 Requirements Management Level 2
Created by
Juda Osejo
Views
5
Rating

Feedback

What is it about?

What do you think of the new look?

How do you like it?