Architect's Toolbox Guide

Leave with: A capability-to-application view and a short decision list.

1. List the applications in scope and the business capabilities each one supports.
2. Mark overlaps, gaps and end-of-life technology.
3. Give each application a disposition (keep, invest, migrate, retire) with a reason.
4. Turn the dispositions into a sequenced roadmap someone owns.

When this is not enough: A portfolio view without agreed ownership and a data refresh routine goes stale within a quarter.

Leave with: A capability map with the outcome traced to the capabilities it needs.

1. Name the outcome in business terms, not system terms.
2. Map the capabilities involved, one level deeper than feels comfortable.
3. Trace the value stream stages that use them.
4. Flag the capabilities that are weak, duplicated or unowned.

When this is not enough: Capability maps need business owners to agree on them, or they stay an IT artifact.

Leave with: A system context view, the key interfaces and a decision record.

1. Define the users, the system boundary and external dependencies.
2. Sketch the context before splitting it into deployable parts.
3. Name the important interfaces and quality constraints.
4. Record the major decision, the alternatives and what still needs proving.
5. Review it with whoever will build and run it.

When this is not enough: A diagram is not a design review; regulated or high-risk changes need formal sign-off.

Leave with: Container and component views plus a list of quality-attribute questions.

1. Pick the two or three quality attributes that matter most.
2. Draw containers, then components, only where it helps a decision.
3. Find the dependencies that make change expensive.
4. Write a decision record for each trade-off you accept.

When this is not enough: Views drift from the code unless they are generated from it or reviewed on purpose.

Leave with: A conceptual or logical data view with ownership and flow notes.

1. Name the core entities in business language.
2. Assign an owner and an authoritative source to each.
3. Trace how data moves between systems and where it is copied.
4. Note the quality, retention and sensitivity rules that apply.

When this is not enough: Models do not fix ownership; governance decisions still have to be made by people.

Leave with: A deployment view with reliability, security and cost questions.

1. Place the workload: region, network boundary and shared services.
2. Draw the deployment view, including what is shared and what is dedicated.
3. Walk the Well-Architected pillars and write down the trade-offs.
4. Name who operates it and how failure is detected.

When this is not enough: A framework review does not replace load, failover or cost testing.

Leave with: A threat model and a ranked list of controls to review.

1. Draw the data flows and mark the trust boundaries.
2. Walk each element with a structured method such as STRIDE.
3. Rank the threats by impact and likelihood.
4. Turn the top threats into control requirements with owners.

When this is not enough: A threat model is a point-in-time review; repeat it when the design changes.

Leave with: An AI system boundary view and a risk and evaluation checklist.

1. Draw the boundary: inputs, tools, data sources and outputs.
2. List what the system can read, decide, send and change, and who approves each.
3. Map the risks with a recognized framework and pick the controls.
4. Define how you will evaluate quality and failure before launch and after.

When this is not enough: Frameworks guide the questions, but the evidence comes from testing your own system.