Study Guide: Alex for Enterprise Architects

Your reference for applying Alex to system design, architecture decision records, cloud strategy, cross-team alignment, and technical governance. Ready-to-run prompts — built around the hard parts of architecture at scale, not the whiteboard exercises.

What This Guide Is Not

This is not a habit formation guide (see Self-Study Guide for that). This is a domain use-case library — the specific ways Alex supports enterprise architecture work.

Where to Practice These Prompts

Every prompt in this guide works with any AI assistant you already use — GitHub Copilot, ChatGPT, Claude, Gemini, or others. The prompts are the skill; the tool is just where you type them. If you already have a preferred tool, start there.

For the deepest experience, the Alex VS Code extension (free) was built for these workflows. It understands enterprise architecture context, lets you save what works with /saveinsight, and keeps your study guide and exercises right inside the editor where you already work.

You don’t need a specific tool to benefit. You need the discipline of reaching for AI when the work is genuinely hard — not just when it’s repetitive.

Core Principle for Enterprise Architects

Architecture is the art of making decisions that are expensive to reverse. The hardest part is not choosing a technology — it is understanding the second-order consequences of that choice across teams, timelines, and budgets. The architect who leans on AI effectively is not one who generates diagrams faster; it is one who stress-tests decisions before they harden into infrastructure.

Your primary discipline with Alex: use it to challenge your assumptions, surface hidden coupling, and articulate tradeoffs clearly enough that stakeholders can make informed decisions rather than rubber-stamping your preference.

The Seven Use Cases

1. Architecture Decision Records (ADRs)

The architect’s documentation challenge: Architecture decisions are made in meetings, validated in POCs, and forgotten in wikis. The decisions that matter most — why you chose event-driven over request-response, why you picked Cosmos DB over Postgres, why the team boundary sits here and not there — are rarely documented with enough context for future teams to understand or safely revisit them.

Prompt pattern:

I am making an architecture decision for [system/domain].
Business context: [what the organization needs, constraints, timeline].
Technical context: [current state, tech stack, team capabilities].
Options under consideration:
  Option A: [description, cost, risk]
  Option B: [description, cost, risk]
  Option C: [description, cost, risk]
My current lean: [which and why].

Help me:
1. Identify hidden assumptions in my preferred option
2. Articulate what must be true for this decision to hold in 3 years
3. Find the coupling risks — what else changes if this changes?
4. Draft an ADR with honest tradeoff analysis, not just the conclusion

Follow-up prompts:

What organizational conditions would make us regret this decision within 18 months?

Argue for the option I am rejecting. Give me the strongest case a skeptical principal engineer would make.

Try this now: Your company is evaluating whether to replace a central Oracle database with event-driven microservices. Fourteen applications consume the data, compliance requires ACID transactions on financial records, and the migration budget is two years. Use the ADR prompt to document the decision — including the options you rejected and the conditions that would force you to revisit.

2. Cloud Architecture and Migration Strategy

The architect’s cloud challenge: Cloud migration is never purely technical. It involves sequencing decisions (which workloads move first), organizational readiness (who operates what), cost modeling (which is always wrong initially), and risk management (what breaks during the transition). The failure mode is treating migration as a lift-and-shift project when it is actually an organizational transformation.

Prompt pattern:

I am planning a cloud migration/architecture for [workload/system].
Current state: [on-prem, hybrid, existing cloud — describe honestly].
Business drivers: [cost, scale, compliance, speed-to-market, resilience].
Constraints: [data residency, team skills, budget, timeline, regulatory].
Target cloud: [Azure / AWS / GCP / multi-cloud].

Help me:
1. Identify the workloads that should NOT move first (highest risk, lowest value)
2. Design a migration sequence that builds confidence incrementally
3. Find the hidden costs I have not budgeted for (egress, re-architecture, operations)
4. Articulate the organizational changes required — not just the infrastructure changes

3. Cross-Team Technical Alignment

The architect’s alignment challenge: Enterprise architecture exists at the intersection of multiple teams, each with their own priorities, tech stacks, and definition of “done.” The architect’s job is not to dictate standards but to create enough coherence that teams can integrate without drowning in coordination overhead. The failure mode is either too much governance (teams resent it and route around it) or too little (teams build incompatible systems and discover it in production).

Prompt pattern:

I need to align [N] teams on [technical decision/standard/pattern].
Teams involved: [list with their current approaches].
The integration point: [API contract / data format / event schema / shared service].
Current friction: [where things break or get expensive today].
My proposed approach: [describe].

Help me:
1. Identify which teams will resist and why (honest assessment)
2. Find the minimum viable standard — what must be shared vs. what can vary
3. Design an adoption path that does not require everyone to change at once
4. Draft a technical alignment document that acknowledges tradeoffs, not just rules

4. Technical Governance and Standards

The architect’s governance challenge: Standards documents are written with good intentions and ignored with equal conviction. The failure is not the absence of standards — it is creating standards that are either too abstract to be actionable or too rigid to survive contact with real project constraints. Good governance provides guardrails, not handcuffs.

Prompt pattern:

I need to create/update a technical standard for [area: API design / data classification / security controls / observability / deployment].
Audience: [who must follow this — all teams / platform team / external vendors].
Current state: [no standard / outdated / exists but not followed].
The problem this standard solves: [specific failures or risks it prevents].

Help me:
1. Distinguish between MUST (non-negotiable) and SHOULD (recommended) requirements
2. Include concrete examples for every rule — no abstract guidance without illustration
3. Define the compliance check — how does someone know if they are following this?
4. Write the exceptions process — because every standard needs one

5. System Design Review and Risk Assessment

The architect’s review challenge: Design reviews often degenerate into style debates or rubber stamps. The valuable design review identifies the decisions that will be most expensive to reverse, the failure modes no one has mentioned, and the gaps between what the design assumes and what the organization can actually deliver.

Prompt pattern:

Review this system design:
[Paste design document, diagram description, or architecture summary]

Focus on:
1. Failure modes — what happens when each component fails?
2. Scaling bottlenecks — where does this design break under 10x load?
3. Operational complexity — can the team that built this actually run it?
4. Security boundaries — where are the trust boundaries and are they enforced?
5. Cost trajectory — what does this cost at current scale vs. projected scale?

Skip style feedback. I need structural risk analysis.

Follow-up prompts:

What is the most likely production incident this design will cause in its first year?

If I had to cut the scope of this design by 40%, what should I keep and what should I defer?

6. Stakeholder Communication and Business Cases

The architect’s communication challenge: The architect who cannot explain a $2M infrastructure investment to a CFO in business terms will not get the investment funded. The gap between technical reasoning (“we need to decouple the monolith for deployment velocity”) and business reasoning (“this reduces our time-to-market by 60% and eliminates a $400K annual outage risk”) is where most architecture proposals die.

Prompt pattern:

I need to present [technical initiative] to [audience: CTO / CFO / board / business stakeholders].
Technical substance: [what we are doing and why].
Business impact: [what this enables, prevents, or saves].
Cost: [one-time and ongoing].
Risk of not doing it: [what happens if we do nothing].
Timeline: [when it delivers value, not just when it is "done"].

Help me:
1. Translate technical value into business language without dumbing it down
2. Build a cost model that includes the cost of the status quo
3. Anticipate the three questions this audience will ask
4. Draft talking points that lead with impact, not implementation

7. Technology Radar and Emerging Technology Assessment

The architect’s evaluation challenge: The pressure to adopt new technology is constant. The discipline of evaluation is distinguishing signal from hype — understanding not just what a technology does but what it costs to operate, what it replaces, and whether your organization has the skills to use it effectively. The failure mode is either adopting too early (paying the pioneer tax) or too late (accumulating technical debt from outdated stacks).

Prompt pattern:

Evaluate [technology/pattern/platform] for our context:
Our current stack: [describe].
The problem this would solve: [specific, not "modernization"].
Team capability: [honest assessment of skills and learning capacity].
Organizational risk appetite: [startup-fast / enterprise-cautious / regulated-conservative].

Help me:
1. Separate the genuine capability from the marketing claims
2. Identify the hidden operational costs (training, migration, tooling gaps)
3. Find case studies of organizations similar to ours who adopted this — what went well and what did not
4. Recommend: adopt now / trial / assess / hold — with conditions for each

What Great Looks Like

After consistent use, you should notice:

• Architecture decisions are documented before they calcify — future teams can understand and safely revisit them
• Cloud strategies account for organizational readiness, not just technical feasibility
• Cross-team alignment improves because standards are actionable and adoption is incremental
• Stakeholder conversations lead with business impact, and technical investments get funded
• Technology evaluations are rigorous — you adopt deliberately rather than reactively

The enterprise architect who will thrive in an AI-augmented environment is not the one who generates the most diagrams. It is the one whose decisions are the most clearly reasoned, most honestly documented, and most effectively communicated.

Your AI toolkit: These prompts work in ChatGPT, Claude, Copilot, Gemini — and in the Alex VS Code extension, which was designed around them. Start with whatever you have. The skill transfers across all of them.

Your First Week Back: Practice Plan

Month 2–3: Advanced Applications

Architecture Decision Archive

Build a queryable repository of past decisions:

/saveinsight title="ADR: [decision title]" insight="Context: [system state and business drivers]. Options: [A, B, C with tradeoffs]. Decision: [chosen option] because [rationale]. Revisit if: [conditions]." tags="architecture,adr,enterprise"

Technology Radar Library

Track your technology evaluations over time:

/saveinsight title="Tech eval: [technology]" insight="Status: [adopt/trial/assess/hold]. Strengths: [list]. Risks: [list]. Our readiness: [honest assessment]. Revisit: [date or trigger condition]." tags="tech-radar,evaluation"

Continue your practice: Self-Study Guide — the 30/60/90-day habit guide.