Frameworks and governance
In the last five lessons you built a capability map, a value stream, a portfolio view, a target state and a roadmap for Mangrove Market. This lesson shows how that work lines up with TOGAF's method and ArchiMate's notation, and how to govern the decisions that follow so that teams ask for architecture advice instead of working around it.
By the end you can
- Map the phases of the TOGAF ADM to the work you did in ea-01 to ea-05, and tailor the method for a three-person team
- Read and draw a small ArchiMate view with the right layers and the serving, realization, assignment and flow relationships
- Write architecture principles with a rationale and implications, and decision records people actually read
- Run an advice process, with a time-limited review board for the few high-impact decisions
- Measure whether governance helps delivery: time to decision, decisions revisited and teams bypassing it
The everyday picture
In ea-01 you met the city planner who decides zoning, roads and water so that buildings fit together. Now think about how that city handles building permits. A good city has a short building code that everyone can read: fire exits, wall strength, how close to the road you may build. It has a book of pre-approved house designs, so a family that picks one gets a permit in a day. For anything else, the builder must show the plan to the neighbours and to the fire officer, listen to them, and then go ahead. Only a tower or a new road goes to the full planning committee, and the committee must answer within a fixed time.
A bad city sends every garden shed to the committee, which meets once a month and has a six-month queue. People stop asking. They build at night, and the city finds out when a wall falls down. Architecture governance works the same way. A few clear principles are the building code, reference designs are the pre-approved houses, the advice process is showing the plan to the neighbours, and the review board is the committee for towers only.
TOGAF's ADM: the cycle you already ran
TOGAF is the most widely used enterprise architecture framework. Its core is the ADM, the Architecture Development Method. The ADM is a cycle of phases, each with a purpose, inputs and outputs. You do not need to read the whole standard to use the idea. You need to know what each phase is for, so you can see which question you are answering at any moment.
- Preliminary. Get the organisation ready to do architecture: who the architects are, the principles, the governance, and how you will tailor the method.
- Phase A, Architecture Vision. Scope, stakeholders, the business goals and a high-level picture of the change. Approval to go on.
- Phase B, Business Architecture. Baseline and target for capabilities, value streams, processes and organisation.
- Phase C, Information Systems Architectures. Baseline and target for data and applications.
- Phase D, Technology Architecture. Baseline and target for platforms, infrastructure and technology standards.
- Phase E, Opportunities and Solutions. Group the gaps into work packages and decide the main steps (transition architectures).
- Phase F, Migration Planning. Order the work packages by value, cost, risk and dependency, and agree the funded roadmap.
- Phase G, Implementation Governance. Make sure the projects deliver what the architecture intended, through reviews and agreements with delivery teams.
- Phase H, Architecture Change Management. Watch for changes in the business or technology and decide whether they fit the current architecture or need a new cycle.
- Requirements Management sits at the centre. Requirements arrive and change at every phase, and this process keeps them stored, traced and fed to whichever phase needs them.
Now look at what you did in this course. Mangrove's board goals were your requirements: double partner-shop revenue from about $52M to about $104M (G1), open two new cities by mid FY2028 (G2), and cut the cost to serve a partner order by 30% (G3). ea-01 framed the vision and stakeholders, which is Phase A. The capability map and the order-to-cash value stream in ea-02 and ea-03 are Phase B. The application portfolio in ea-04 covers Phase C and touches Phase D (two WMS versions, a support end date in 2027). The target state, the plateaus and the roughly $3.1M roadmap in ea-05 are Phases E and F. This lesson is the Preliminary phase and Phases G and H. You have run a light ADM without calling it that.
Two things about the ADM matter more than the phase names. First, it is iterative. You loop back when you learn something. If migration planning shows the fifth DC cannot have every system ready by the fixed city opening, you go back to the business view and ask which capabilities it needs on day one. Second, TOGAF itself says the method should be adapted to the organisation. Tailoring is part of the Preliminary phase. A team of three at Mangrove should not produce every deliverable the standard describes. It should produce the few views that answer the board's and the teams' questions, and keep them current. Pick outputs by asking "who will use this, for which decision, by when?"
Quick check
Six months into the roadmap, the board decides to add a third new city. Where in the ADM is this change handled?
Phase H, Architecture Change Management, exists for exactly this: a change in the business arrives and someone must decide whether it is a small adjustment or a new cycle. A third city changes the vision and the capability needs, so it probably starts a new cycle at Phase A. Jumping straight to the roadmap skips the question of whether the target state still holds.