The three basic approaches to change, the implementation methodologies that follow them, and how readiness and risk evidence point to the right fit.
From Ultra Transcenders OGEA-102 by Tony Rough (publishing soon)
Step 8 sets the overall shape of change. It is done in two layers: first the strategic approach, then the methodology for pursuing the strategic direction. Together with the dependencies, these choices form the basis for the work packages, and the step ends with agreement on the Implementation and Migration Strategy.
| Approach | Meaning | Planning implication |
|---|---|---|
| Greenfield | A completely new implementation | There is no existing system to migrate from |
| Revolutionary | Radical change: the new is switched on and the old switched off | A single cut-over, so migration risk and back-out need explicit planning |
| Evolutionary | Convergence, through parallel running or phased introduction | Suits incremental delivery through Transition Architectures that each add value |
Having chosen the approach, the architect selects a way of addressing the strategic direction that takes account of the risks. The most common are:
Common trap: Confusing the strategic approach (Greenfield, Revolutionary, Evolutionary) with the implementation methodology (Quick win, Achievable targets, Value chain method) - they are two separate decisions made in that order within step 8.
Common trap: Choosing a revolutionary approach because the sponsor wants the Target quickly - wanting speed is not the same as being able to absorb change; readiness and risk evidence should drive the choice.
This note is one section of Ultra Transcenders OGEA-102: Enterprise Architecture Practitioner, an independent study guide that explains every learning unit the exam covers, topic by topic, with comparison tables, diagrams and the common traps, plus a glossary linked to the TOGAF Standard.
Publishing soon on Amazon in Kindle and paperback editions.
About the book · OGEA-102 terms in the glossary · All OGEA-102 study notes
What each architecture state means, why candidate work cannot govern change, and a practical way to organise states and recency in the repository.
Why security architecture is not a separate domain, why every stakeholder has security concerns, and how security services differ from a control framework.
How to identify stakeholders beyond the organisation chart, classify their positions, place them on the power/interest grid and tailor what each group receives.
Why more than one option is worth showing, the criteria used to judge them, and how the choice is made jointly with stakeholders at a formal review.
What an Architecture Contract settles, the points in the cycle where contracts arise, and the three kinds of contract with the parties each one binds.
How the governance body decides how large a response a change deserves, the three categories of change and the stakeholder guideline for redesign.
The three classes of standard, the five lifecycle states from proposed to retired, and what a deprecated standard does and does not require.