Start with the outcome that must continue
In a funds migration, the portal name may change while the need to receive valid instructions remains. Start by identifying that capability and who depends on it. Then record the applications, data and services supporting it. This separation helps discuss alternatives without assuming that retaining a product preserves the outcome. Also ask what work moves to APS: reducing licenses may increase manual reconciliation. The agreed scope should include that effect so options can be compared using consistent criteria.
Turn direction into observable requirements
A direction toward predictable recovery does not establish whether a design complies. For the example service, the business defines 30 minutes under a particular scenario and requires preserving accepted instructions. Link those requirements to the direction and identify necessary evidence. An old image ready to start covers only part of the problem. You need to know what data exists after change and whether the old consumer interprets it. The limit is a condition of this exercise, not a TOGAF recommendation for every bank.
Retain consistency across domains
Correcting an instruction involves business authority, data history, application behavior and technical mechanisms. Analyzing these aspects in separate domains organizes work but does not justify approving them as independent. If the need to preserve origin emerges during data design, also check API contracts, batch processing and support. Record the requirement and affected decisions. Iterating on new information may be necessary; the phase in which the problem was discovered does not itself determine the full extent of impact.
Design the state that will actually exist
The target design may show all services in cloud while the first delivery leaves the batch on premises. That intermediate state has its own connections, costs and recovery conditions. Represent coexisting versions, the data each reads and writes, and startup dependencies. Do not assume a final-state test covers this combination. A useful transition explains how to maintain service during the interval and which conditions allow moving forward, stopping or choosing an authorized alternative when evidence remains insufficient.
Analyze return beyond the binary
Suppose the new API writes schema v2 and batch v1 only interprets v1. Reinstalling v1 does not transform already accepted data. The plan must address that difference, for example through a compatible transition or another assessed path preserving requirements. Do not invent reversible conversion or authorize instruction loss for technical convenience. The rehearsal should include data created after cutover and observe the business outcome rather than ending when the process appears as running again. An executable image alone cannot establish recoverability.
Check numerical design assumptions
In an explicitly sequential path, 20 ms networking, 45 ms application and 50 ms database total 115 ms. Against a 100 ms limit, at least 15 ms must be removed in that model. Using only the slowest component would assume overlap that was not given. The calculation helps identify the gap and compare hypotheses but does not measure production. Queues, variability, percentiles and load may require further analysis before inferring actual performance or promising contractual compliance.
Plan implementation with actual resources
After identifying packages and transitions, check sequence against available capacity. A and B may be logically independent yet compete for the same person. If each needs three full-time days from the only specialist, they occupy six sequential days. C, taking two days after both, brings the total to eight. A five-day plan is feasible only with changed assumptions, such as another equivalent specialist. Record cost, competence and the needed decision rather than hiding the conflict in separate calendars.
Guided exercise: draw API v2, batch v1 and data produced during the interval. Mark the path that fails on return. Explain why starting v1 does not establish instruction preservation or recovery within 30 minutes.
Common pitfalls
Confusing capabilities with application names; reusing a pattern beyond its assessed scope; ignoring new data during rollback; assuming parallel work without checking the shared person.
Related topics: Requirements and ADM domains · Migration planning · Recovery and APS handover
The path between current and target states needs its own requirements, dependencies and evidence. A transition state can only be accepted through relevant decisions and criteria, not through the existence of a final design.
Reference: How ArchiMate and TOGAF complement each other · OGEA-101, TOGAF Enterprise Architecture Foundation; body of knowledge drawn from TOGAF Standard, 10th Edition