4 of the 20 questions we have for this objective, shown with the answer and the reasoning.
How to implement the Architecture Vision phase including its applicable techniques
Larchfield University has identified the main risks of moving student records to a new platform, assessed their initial level, and assigned a mitigation approach to each. The sponsor wants to be sure that the cost and effort of mitigation are agreed as part of the engagement rather than discovered later.
Where should the architect place the risks and mitigation activities in Phase A?
- AInclude them in the Statement of Architecture Work so they are approved with the engagement scope and planPhase A identifies business transformation risks and mitigation activities and includes them in the Statement of Architecture Work, so the sponsor approves them as part of the engagement.
- BRecord them only in the Compliance Assessments that the Architecture Board performs in Phase GCompliance Assessments review implementation projects in Phase G. They are too late to agree the cost of mitigating risks identified in Phase A.
- CHold them back until Phase F, when the Implementation and Migration Plan is costedPhase F refines and sequences mitigation within the plan, but the risks are first identified and agreed in Phase A.
- DAdd them to the architecture principles so all future projects must mitigate themPrinciples are general rules that guide decisions. Engagement-specific risks and their mitigation do not belong there.
Why: Phase A in the TOGAF Standard includes the step 'Identify the Business Transformation Risks and Mitigation Activities'. The architect identifies the risks associated with the Architecture Vision, assesses their initial level, assigns a mitigation strategy, and includes these considerations in the Statement of Architecture Work. That way the sponsor approves the mitigation effort together with scope and schedule, which is the scenario's stated need. The distractors use real TOGAF outputs that are either too late or the wrong kind of document.
How to implement the Architecture Vision phase including its applicable techniques
Calder Freight's Statement of Architecture Work was approved for a European parcel network. Midway through Phase B, the sponsor asks the team to add the North American subsidiary, which has different regulations, systems and stakeholders. The approved document includes a change of scope procedure.
What should the architect do?
- AAdd North America to the Phase B work and keep the existing plan and acceptance criteriaAbsorbing a major scope change without assessment leaves schedule, deliverables and acceptance criteria inconsistent with the work being done.
- BRaise a change request through Architecture Change Management in Phase HPhase H manages change to implemented architectures through the change management process. A scope change to an engagement in progress follows that engagement's own procedure.
- CRestart the Preliminary Phase to redefine the organization's Architecture CapabilityThe Architecture Capability is not in question. The change concerns the scope of one engagement.
- DApply the change of scope procedure: assess the impact on scope, stakeholders, plan and deliverables, revisit the Architecture Vision as needed, and obtain approval of an updated Statement of Architecture WorkThe change of scope procedure in the Statement of Architecture Work exists for this case. A large addition with new stakeholders and regulations calls for an updated vision and a re-approved agreement.
Why: The TOGAF Standard includes specific change of scope procedures in the Statement of Architecture Work so that changes during the engagement are handled in an agreed way. Adding a subsidiary with its own regulations, systems and stakeholders changes scope, stakeholders and possibly the vision, so the architect assesses the impact, revisits Phase A outputs as needed, and gets the updated Statement of Architecture Work approved before continuing. The ADM's iterative nature supports returning to Phase A when scope changes substantially. The distractors either ignore the procedure, use Phase H change management for a scope change, or reset the whole Architecture Capability.
How to implement the Architecture Vision phase including its applicable techniques
Brightwater Utilities has agreed the scope of an engagement to replace its customer billing landscape. The CFO and the Head of Customer Service each ask the architect to explain, in their own terms, what the target state will deliver for them and how success will be measured. The engagement is still in Phase A.
Which Phase A activity addresses this request?
- ADevelop the Architecture Requirements Specification with quantified service levelsThe Architecture Requirements Specification is built during Phases B to D. It records measurable requirements for implementers, not stakeholder value propositions.
- BRun a compliance review of the current billing system against the targetCompliance reviews are part of Implementation Governance in Phase G. They check projects against an architecture that already exists.
- CPerform a business transformation readiness assessment for each departmentReadiness assessment shows whether departments can absorb the change. It does not explain the value of the target state or define success measures.
- DDefine the Target Architecture value propositions and KPIs for each stakeholder groupPhase A includes a step to define the value propositions and Key Performance Indicators of the target. It states the value for each stakeholder and how it will be measured.
Why: Phase A in the TOGAF Standard, 10th Edition includes the step 'Define the Target Architecture Value Propositions and KPIs'. In this step the architect develops the business case, states the value proposition for each stakeholder grouping, assesses the business risk, and defines the performance metrics and measures that will be built into the work. The CFO and Head of Customer Service are asking for exactly this: value in their terms and how success is measured. The other options are real TOGAF activities placed in the wrong phase or used for a different purpose.
How to implement the Architecture Vision phase including its applicable techniques
Ellsworth Airports is developing a business scenario in Phase A for automated baggage tracking. The first draft says the objective is 'improve baggage handling' and lists only the baggage system as an actor. The business line managers have not been involved yet.
Which three changes should the architect make to the business scenario? Each correct answer presents part of the solution.
- ARestate the objectives so they are specific, measurable, actionable, realistic and time-boundThe business scenario technique requires SMART objectives, so the vague 'improve baggage handling' must be made measurable and time-bound.
- BIdentify the human actors, such as handlers and passengers, as well as the computer actors, and define their roles and responsibilitiesA business scenario names both human and computer actors and their roles, which reveals requirements a single system actor hides.
- CInvolve business line management and the people who will use the solution in developing and reviewing the scenarioBusiness scenarios are developed with business users and line management, not by architects alone, so the requirements reflect the real business need.
- DSelect the specific baggage tracking products in the scenario so that the requirements are realisticBusiness scenarios describe the business problem and requirements, not product choices. Products are selected much later, during implementation planning.
- EReplace the Statement of Architecture Work with the finished business scenarioA business scenario is a technique for discovering requirements and supporting the vision. It does not replace the Statement of Architecture Work.
Why: The business scenario technique, which Phase A refers to and the TOGAF Series Guide on Business Scenarios describes, identifies the problem, the business and technical environment, the objectives, the human and computer actors, and their roles and responsibilities, and then checks fitness for purpose and refines the scenario. Objectives are expected to be SMART, and the scenario is developed in collaboration with business users and line management. The draft in the scenario fails on all three counts. The distractors introduce product selection too early or confuse the technique with the Phase A agreement document.