Optimize Your Architecture

This workflow uses Workspaces, Context, Integrations, Stacks, Blueprints, and Plans. Start with those if any is unfamiliar.

This workflow is for a large architecture decision about an estate you already run: rationalize the portfolio, cut run-rate cost, modernize a platform, integrate an acquisition, separate a divestiture, place a technology bet, or justify an investment. The question is what to keep, change, consolidate, or remove, in what order, and why.

Done manually, that question is answered with weeks of discovery, spreadsheet analysis that starts aging the day it is approved, and execution that drifts from the decision. In Catio, the same work runs on a live model of your architecture, the analysis arrives as a generated Plan your team validates, and the Plan stays the plan of record through execution.

Who runs it

• The sponsor: the executive who owns the outcome. Frames the mandate and makes the commitment.
• The operator: a chief architect, platform lead, or principal engineer. Runs the four phases below end to end.
• Unit owners: the people who run the systems in scope. Validate findings and own their waves.
• Delivery teams: build the engineering changes, through the Architecture-Led AI SDLC.

Start with Archie

Describe what you are trying to achieve to Archie, the way you would at a whiteboard: "What depends on this database, and what breaks if we change it?" or "Which systems in this workspace overlap functionally?" Archie answers from your architecture and Context, which is the fastest way to orient before the formal work begins.

---

Phase 1: Discovery and inventory

Purpose: turn the business imperative into a scoped mandate, and see the estate as it actually runs before anyone reasons about changing it.

1. Frame the mandate. State the outcome, the deadline, and what must not degrade, in the sponsor's words. Name the one data source every figure must reconcile to, such as your billing data or asset inventory.
2. Scope the workspace. Create a workspace around a durable boundary: an organizational unit, a product line, or the systems in scope. Everything downstream inherits this boundary.
3. Encode the objective in Context. Add the goals, constraints, timeline, and standards to Workspace Context, and company-wide mandates to Global Context. Catio generates against Context, so this step decides the quality of everything after it. See Using Context Effectively.
4. Connect the estate. Connect integrations so Stacks builds the live model: components, dependencies, and topology, kept current.
5. Work the model. Investigate through Diagrams and the Architecture Inventory, and save the Views your team will return to. See Using Stacks to Investigate Your Architecture.

Done when: the sponsor can state the decision in one sentence with a target and a date, the workspace exists with Context in place, and the team works from the model rather than a whiteboard.

Common failure mode: framing the call as "optimize everything." Generic scope produces generic guidance.

Phase 2: Analysis

Purpose: generate the Plan from the mandate, then validate and shape it into a judgment your team will defend.

You do not build the Plan by hand. From the Blueprints page, write the mandate itself as the prompt. When the prompt is mandate-level (broad, aimed at an outcome) rather than feature-level, Catio generates a Plan: a set of targeted Blueprints organized against your goal. Writing that prompt well is the highest-leverage step in this workflow.

1. Generate. Write the mandate as the prompt: goal, priorities, constraints, timeframe. Set Scope to the boundary under review and Focus to the benefits that matter, and attach supporting documents such as a mandate memo or budget guidance. Review the outline Catio proposes, adjust it, then generate.
2. Validate. Unit owners review each Blueprint on its own evidence: the Gap Analysis, the Business Impact, and the Implementation Plan. Every Blueprint gets a disposition: confirmed, corrected, or rejected with a reason. See Interpreting and Acting on Blueprints.
3. Shape. Refine Blueprints that are close but not right with Edit with Archie. Deliberate open trade-offs with Archie against the live system (see Using Archie for Architecture Deliberation). Add Designs where your team sees opportunities Catio did not surface, and remove what does not serve the mandate.
4. Label the evidence. Mark each figure by what it rests on: reconciled to your data, a structural finding with stated assumptions, or an identified opportunity still awaiting validation. An unknown becomes a question with an owner and a date, never a guess.

Done when: every Blueprint in the Plan has a disposition, the figures are labeled by the evidence behind them, and open questions have owners.

Common failure mode: accepting the generated Plan untouched. The opposite failure costs as much: abandoning the Plan to rebuild the analysis in a spreadsheet, which loses the live model and the evidence trail.

Phase 3: Prioritization

Purpose: refine the Plan with the people who will carry it, sequence it, and commit it as the plan of record.

1. Walk stakeholders through the Plan in Catio, with each Blueprint's analysis one click away. Answer what-if questions in the session with Archie, against the real system.
2. Turn objections into work: a Blueprint edit, or a question with an owner. Nothing lives only in meeting notes.
3. Sequence into waves. Structure the Plan to match the teams that own the work, using Sublists as waves. Give each wave owners and a definition of done, and put date-bound decisions such as renewals on their dates.
4. Commit. The validated Plan becomes the plan of record. Add a tracking link to each Blueprint so progress can be followed from the Blueprint itself.

Done when: the Plan is committed, with waves, named owners, and a definition of done per wave.

Common failure mode: committing a Plan nobody validated, which moves the debate into execution, where it costs the most.

Phase 4: Execution and feedback

Purpose: track execution to the committed Plan, confirm the outcome landed, and carry what you learned into the next decision.

Execution runs in two lanes:

• Commercial and configuration changes (renewals, rightsizing, tier changes): owned by your platform, FinOps, and procurement owners, and tracked on the Plan.
• Engineering changes: delivery teams pull committed Blueprints into their coding IDE through the Catio MCP and build against the spec. See Architecture-Led AI SDLC Workflow.

Then:

1. Track progress wave by wave against the Plan, through the tracking links on each Blueprint.
2. Review by exception. Architects look at deviations from the committed design rather than at every change.
3. Confirm the outcome against the data source named in Phase 1.
4. Feed learnings into Context: what worked becomes a standard, what failed becomes a guardrail. Every later Blueprint inherits it.

Done when: the outcome is confirmed against your data, the learnings are in Context, and the next decision can start from a live model on day one.

Common failure mode: treating commitment as completion. The Plan is not the outcome.

---

Shapes this workflow takes

The four phases stay the same. What changes is the mandate you write in Phase 2. Adapt one of these patterns:

---

What stays with your team

Catio informs everything about the technology system: the architecture, the dependencies, the cost, the options, and the evidence. Your team makes the call and carries it: the keep and sunset decisions, the negotiations, the delivery, and the change management.

Full playbook

The complete program, including roles, cadence, and a worked treatment of each decision shape, is in The Strategic Call Playbook.

Related

• Achieve Your Outcomes
• Building Plans
• How to Best Utilize Blueprints
• Architecture-Led AI SDLC Workflow