Compare capabilities, not only inventories
An application can remain in the inventory and still have an important gap. If it currently supports only full recovery and the objective requires selective recovery, an unchanged name does not remove the difference. Record the missing capability and related requirements before choosing a solution. Analysis may lead to modification, replacement or another assessed option. Avoid turning gap identification into an automatic product recommendation: understanding the difference and choosing how to address it are related steps requiring distinct evidence and decisions.
Distinguish mandatory conditions from preferences
A scoring matrix is useful when it is clear what can be traded off. In the example, residency in one territory is mandatory and no exception is authorized. A 92-point option violating that condition does not beat an 81-point option through better user experience. First assess feasibility against explicit conditions, then compare preferences among feasible options. If context or authority allows reconsidering a condition, that is a separate traceable decision. Do not hide it inside an opportunistic change to weights.
Look for common failure dependencies
Distributing applications across two zones improves some scenarios but does not remove dependency on a single identity service needed for startup. Represent the authentication path, startup conditions and recovery options. Also ask whether recovery mechanisms require the unavailable service. Relationship analysis helps reveal this kind of operational circularity. Do not multiply availability numbers while assuming independence without establishing it. The exercise aims to identify needed questions and evidence, not calculate actual banking availability from a diagram or a component count.
Connect partitions without removing useful autonomy
API and batch teams can keep separate cadences while respecting a shared contract. Changing a field meaning requires coordination even without changing its name or technical type. Record consumers and versions, define the uncertainty to resolve and use an iteration to obtain necessary evidence. An exit criterion, such as agreement on examples and expected behavior, helps stabilize the contract. Local autonomy remains possible where it does not break agreed relationships; merging every decision is not a necessary consequence of one dependency.
Interpret approval, effective period and implementation
The repository may hold v3 approved for November while v2 remains in production in October. An operational view should represent the state relevant to operations; a planning view also needs the approved target. Retain statuses and dates allowing correct selection without deleting useful history. The same discipline applies to exceptions: time-limited approval is not permanent compliance. When the term expires or a condition is missing, reporting should show current circumstances and route the decision through established authority without inventing a renewal.
Use relationships to prepare retirement
An asset catalog identifies what exists. To retire a database, you also need to know who reads, writes or depends on it for recovery. A matrix can clarify these relationships; choose the format according to the question. In the example, A has migrated but B still reads a view in D. Financial ownership by A does not prove exclusive use. Confirm B consumption, assess an alternative and include residual cost, an owner and the retirement condition. Disabling alerts removes neither the dependency nor the need for reconciliation.
Assemble a decision package that can be checked
For the requirement to recover within 30 minutes, link the architecture option to relevant evidence with version, scenario, result and limitations. Add the decision owner and next steps when a gap remains. An attractive diagram without this link may be insufficient for a decision. Publisher deliverable templates can guide structure, but filling sections does not demonstrate compliance. Here we use original examples and public information about Foundation scope; exercises neither replace study of the complete body of knowledge nor equal an official assessment.
Guided exercise: draw A → D and B → view → D. Mark A as migrated and check which path remains. Prepare a retirement recommendation including the owner of B and evidence for the new source.
Common pitfalls
Confusing the highest version with the installed one; adding preferences to offset mandatory constraints; inferring independence from two zones; deleting the history of an expired exception.
Related topics: Gap and option analysis · Content and traceability · Exceptions and decommission
Relationships and states give meaning to an inventory. Use them to explain what depends on what, which evidence applies and who can decide before retiring services or accepting deviations.
Reference: How ArchiMate and TOGAF complement each other · OGEA-101, TOGAF Enterprise Architecture Foundation; body of knowledge drawn from TOGAF Standard, 10th Edition