Enterprise Architecture and Solution Design Prompt: From Business Outcome to Operable Architecture

TL;DR

AI can accelerate enterprise architecture work, but speed is not the same thing as architectural quality. A model can produce a convincing diagram, technology list, migration plan, or recommendation while quietly inventing capacity assumptions, overlooking trust boundaries, treating preferences as requirements, or describing proposed capabilities as if they already exist.

The Enterprise Architecture and Solution Design prompt addresses that problem by forcing the work through a traceable design sequence: business outcome, measurable requirements, gaps, viable options, hard constraints, architecture boundaries, failure behavior, operations, cost, migration, validation, and decision status. It also requires AI, retrieval, and agents to compete against simpler approaches instead of becoming the default answer. The Should This Be AI? decision framework helps establish that suitability before architecture choices are made.

The practical takeaway: use AI to structure and challenge the architecture argument, not to manufacture missing architecture facts.

Introduction

The architecture request usually sounds simpler than the architecture problem.

“Design a new customer platform.”

“Move this service to the cloud.”

“Add AI to the workflow.”

“Create a highly available architecture.”

“Modernize this application before the contract expires.”

An architect can put any one of those requests into a capable AI system and receive something polished within minutes. The response may include components, diagrams, redundancy, security controls, databases, APIs, observability, disaster recovery, and a phased roadmap.

The problem is that polish can hide weak reasoning.

What was the measurable availability requirement? Was multi-region deployment actually required, or did the model assume it? Which requirement made a message queue necessary? Who owns the state during a partial failure? What happens when identity is unavailable? Has the recommended product capability been verified against the version being purchased? Is the recovery time objective based on a tested procedure or merely repeated from a requirement? Was a lower-complexity option evaluated? Has the proof of concept demonstrated production capacity, or only that the happy path works?

Those are architecture questions. A diagram cannot answer them by itself.

The Enterprise Architecture and Solution Design prompt is designed to make those questions part of the AI interaction from the beginning. It treats architecture as a decision and evidence system rather than a technology-generation exercise.

The method is vendor-neutral. It can be used for application, integration, data, cloud, infrastructure, security, AI, and hybrid architecture. It does not replace an enterprise architecture method, a Well-Architected review, security engineering, product documentation, or human design authority. Its job is narrower and more useful: turn AI into a disciplined architecture workbench that exposes missing information, alternatives, tradeoffs, ownership, and proof.

Why AI-Assisted Architecture Needs a Stronger Contract

Enterprise architecture already has mature ways of thinking about requirements, tradeoffs, lifecycle concerns, and decision governance.

The Open Group’s TOGAF Standard provides an established enterprise architecture method and supporting guidance. Microsoft, AWS, and Google each organize workload architecture around multiple nonfunctional concerns rather than treating architecture as a functional feature list. NIST SP 800-160 approaches security as a systems engineering concern throughout the system life cycle.

The architecture prompt should not attempt to replace those bodies of practice. It should make it harder for an AI interaction to bypass them.

That distinction matters because generative AI has several properties that are useful for architecture and dangerous when unmanaged.

It is good at synthesizing a large number of considerations. It can compare alternatives, organize requirements, propose failure scenarios, identify missing inputs, normalize terminology, and draft decision records quickly.

It can also fill gaps too confidently.

If a platform version is missing, it may reason from a neighboring version. If throughput is unspecified, it may invent a plausible number. If the user mentions a preferred vendor, it can unconsciously build the requirements around that vendor. If “high availability” appears in the brief, it may add redundant infrastructure without determining what failure the redundancy is meant to survive.

The prompt therefore needs an architecture contract.

That contract says:

• requirements must be measurable where possible
• unknowns remain unknown until validated
• hard constraints are different from preferences
• alternatives are compared using the same criteria
• lower-complexity designs remain eligible
• vendor capabilities are verified, not assumed
• security and trust boundaries are explicit
• failure behavior is part of design
• operations are part of design
• sizing uses measurements and formulas rather than invented precision
• migration includes coexistence, validation, and rollback
• proposed architecture is not described as implemented architecture
• a proof of concept proves only what it actually tested

That is the value of the prompt. It controls the reasoning surface before it controls the wording.

The Prompt Is an Architecture Workbench, Not a Design Oracle

The most important mental model is that the AI sits inside the architecture process, not above it.

What matters in this diagram is the separation between generation and authority.

The model can help generate candidate requirements, options, diagrams, risk lists, migration phases, and validation plans. It should not silently convert them into organizational facts.

The architecture remains proposed until the accountable humans, measurements, current product documentation, security review, operational testing, and decision process support it.

That is particularly important for statements such as:

• this product supports the required feature
• this configuration is licensed
• this version is compatible
• this design can sustain the required throughput
• this architecture meets the recovery objective
• this control satisfies the compliance requirement
• this design is production-ready

Those are evidence claims. They require more than plausible reasoning.

Start With Architecture Drivers, Not Products

A weak architecture conversation often starts with a product noun.

“We need Kubernetes.”

“We need an AI agent.”

“We should use serverless.”

“We need a data lake.”

“We want active-active.”

A stronger process starts with the outcome and constraints.

What does the business need to accomplish? Which user journey matters? What happens if the service is unavailable? Which information is sensitive? How quickly must it recover? How much demand exists today? What growth is expected? Which systems must remain? Which contracts or strategic commitments constrain the design?

The prompt forces those inputs into the architecture before asking for a solution.

Translate outcomes into measurable requirements

“Highly available” is not an acceptance criterion.

“Fast” is not a performance target.

“Secure” is not a security architecture.

“Scalable” is not a capacity plan.

A requirement becomes architecturally useful when the team can tell whether the implemented system satisfies it.

The requirement matrix in the prompt assigns identifiers, acceptance criteria, owners, priorities, and status. That creates traceability between the business request and the later architecture decision.

If the team cannot explain which requirement a component satisfies, the component deserves scrutiny.

Separate Hard Constraints From Preferences

One of the strongest rules in the prompt is simple:

A design that violates a hard constraint is not viable even if it scores well elsewhere.

Architecture scorecards frequently fail here.

A platform can receive excellent scores for developer experience, integration, cost, automation, and performance while being unable to meet a mandatory data-residency boundary. Another option may perform well overall but require permanent connectivity where disconnected operation is mandatory.

Those should not be “penalized” in a weighted score.

They should be rejected.

Useful hard constraints might include:

• prohibited data location
• mandatory recovery objective
• unsupported hardware or operating system
• contractual deadline
• maximum allowable latency
• required disconnected operation
• regulatory control
• approved identity authority
• maximum budget
• existing strategic platform commitment
• licensing restriction
• facility power or cooling limit

Weighted comparison becomes meaningful only after nonviable options have been removed.

Build Alternatives Before You Build Diagrams

Architecture becomes weaker when the preferred solution is selected before alternatives exist.

The prompt explicitly asks for two to four viable options when alternatives exist. It also tells the architect to include the current-state or lower-complexity option when that option remains credible.

That prevents a common pattern in AI-assisted design: give the model a fashionable technology and receive a detailed explanation of why that technology should be used.

Keep the full solution spectrum open

A business problem may be solvable through:

• process change
• configuration
• standard platform capability
• deterministic business rules
• search
• analytics
• workflow automation
• conventional software
• machine learning
• retrieval
• generative AI
• autonomous or semi-autonomous agents

Those are not steps on a maturity ladder.

They are different solution mechanisms.

A deterministic workflow may be better than an agent when the process is known and every transition must be predictable. Search may be better than retrieval-augmented generation when users primarily need exact documents. Configuration may be better than custom development when the existing platform already satisfies the requirement.

The prompt’s AI rule is therefore important: introduce probabilistic reasoning or tool-driven autonomy only when the value justifies the additional evaluation, security, operating, and failure complexity.

The architecture question is not “Where can we insert AI?”

It is “Which mechanism satisfies the requirement with the least unnecessary complexity?”

Make Uncertainty Visible Before It Becomes Architecture

Unknowns are not a failure of architecture work.

Hidden unknowns are.

Early design normally contains incomplete measurements, unconfirmed dependencies, unclear ownership, missing traffic profiles, undecided retention policies, and vendor facts that require verification.

The prompt turns each one into a structured gap:

This creates an important operating rule: do not stop architecture work because a minor detail is missing, but do stop when an unknown could invalidate safety, compliance, feasibility, or capacity.

That is a much better behavior than asking the model to “make reasonable assumptions” and allowing those assumptions to disappear into the design.

Design the Boundaries That Actually Fail

A component diagram is useful, but enterprise incidents rarely respect a neat component diagram.

They move through identity, DNS, certificates, management planes, third-party APIs, data stores, asynchronous queues, rate limits, shared service accounts, control planes, and human operating procedures.

The prompt requires those relationships to be explicit.

Trust boundaries and identity

Architecture should explain:

• which human identities exist
• which non-human identities exist
• which system authenticates them
• where authorization occurs
• which permissions are delegated
• which credentials are long-lived or temporary
• where secrets are stored
• which administrators can cross boundaries
• how privileged access is separated
• how access is revoked
• where audit evidence is generated

For AI systems, the boundary must extend further.

Retrieved content, user input, tool responses, model output, event payloads, and integration responses should not automatically become trusted instructions or trusted data simply because they passed through an AI system.

The prompt therefore separates model behavior from authoritative control. Tool allowlists, validation, approval gates, permission enforcement, source traceability, and fallback remain architectural responsibilities.

Failure domains and degraded modes

A reliable architecture is not one that claims “high availability.”

It is one that explains what happens when dependencies fail.

The prompt explicitly calls out:

• provider outage
• network partition
• rate limiting
• capacity exhaustion
• stale state
• duplicate requests
• partial writes
• data corruption
• unsafe output
• human error
• malicious input

Each material failure should have an expected system behavior.

Does the request fail closed?

Does the application switch to read-only mode?

Does a queue retain work?

Can users continue with stale data?

Can the service operate locally?

Does an approval path become unavailable?

Can operators recover when the primary identity service is offline?

Those answers belong in architecture before production, not only in the incident review afterward.

Operations are part of the design

Microsoft, AWS, and Google all treat operational excellence as an architecture concern. That is the correct model.

A design that cannot be patched, monitored, restored, upgraded, supported, or rolled back is incomplete even when its functional path works.

The prompt therefore asks for:

• service level indicators
• service level objectives
• health checks
• logs, metrics, and traces
• audit events
• alert ownership
• escalation
• capacity thresholds
• timeouts
• retries
• idempotency
• backup
• restore
• failover
• disaster recovery
• release control
• incident runbooks
• support ownership

That list is not Day-2 detail bolted onto the architecture. It defines whether the architecture can survive Day 2.

Do Not Let AI Invent Sizing, Licensing, or Support

Architecture tools become dangerous when they produce numbers simply because a number-shaped answer is expected.

The prompt explicitly prohibits fabricated sizing.

When measurements are missing, the right output is a model.

For example:

Required Peak Capacity =
    Measured Peak Demand
    x Forecast Growth Factor
    x Engineering Headroom Factor

Estimated Storage Requirement =
    Daily Data Growth
    x Retention Period
    x Replication or Protection Factor
    x Growth Factor

Cross-Boundary Transfer Volume =
    Transactions per Period
    x Average Payload Size
    x Required Cross-Boundary Transfers

The variables can then be measured.

The same discipline applies to product and commercial facts. Licensing, service limits, hardware compatibility, regional availability, version support, and lifecycle status change. A model-generated statement should become a verification task against current authoritative documentation.

This is especially important when AI produces an architecture matrix containing phrases such as “supports,” “included,” “unlimited,” “compatible,” or “generally available.”

Those words should trigger validation.

Turn Architecture Into a Delivery and Migration Contract

A target-state diagram often hides the hardest part of a transformation: the organization must operate the old and new states at the same time.

The prompt handles migration as architecture.

It asks for:

• coexistence
• migration waves
• cutover
• validation
• rollback
• reconciliation
• decommissioning
• ownership transition

Each delivery phase also needs an objective, owner, inputs, dependencies, deliverables, entry criteria, exit criteria, validation method, and stop condition.

That turns the roadmap from a calendar into a control system.

A phase should advance because evidence proves that its exit criteria were met, not merely because the project plan says the next phase begins Monday.

Use Decision Records to Preserve Why

One of the easiest architecture artifacts to lose is the reasoning behind a decision.

Six months later, a new architect sees a queue, gateway, database, cache, region pair, security boundary, or replication strategy and asks a reasonable question:

“Why did we do this?”

If the answer exists only in meeting memory, the architecture is already degrading.

Current Microsoft architecture guidance treats the Architecture Decision Record, or ADR, as a record of context, alternatives, tradeoffs, rationale, consequences, and decision status.

That concept maps directly to this prompt.

The architecture output should distinguish at least:

• conceptual
• proposed
• approved
• implemented
• tested
• operational

Those words prevent a serious communication failure.

A proposed architecture may be reasonable.

An approved architecture has passed the organization’s decision authority.

An implemented architecture exists.

A tested architecture has evidence for specific tested properties.

An operational architecture has ownership and is actually being run.

Those states are not interchangeable.

What a Good Output Should Let Reviewers Challenge

The final architecture package should not merely show the answer. It should expose enough reasoning for different stakeholders to challenge the answer responsibly.

A good architecture review should be able to disagree with the recommendation without first reconstructing the missing analysis.

Example: Turning a Vague Request Into Reviewable Architecture

Consider a hypothetical request:

Replace a manual field-service coordination process with a modern platform that supports remote sites, provides strong auditability, and reduces dispatch delays.

A generic AI response could immediately suggest cloud services, mobile apps, event streaming, AI assistants, and multi-region deployment.

This prompt should force the design to slow down first.

The architecture drivers might become:

Now the solution space becomes more interesting.

A configuration-first option might extend an existing service-management platform.

A conventional software option might introduce a local-capable application and asynchronous synchronization.

An AI-assisted option might use language models only for interpreting free-form field notes while the authoritative work-order workflow remains deterministic.

A fully autonomous agent might be rejected if autonomous dispatch changes are not permitted.

The architecture becomes better because the AI option had to earn its place.

The disconnected-operation constraint may also eliminate designs that require synchronous access to a remote control plane for every critical transaction. The recovery objective creates a validation requirement. The audit requirement influences identity and event design.

That is how requirements shape architecture.

How to Use This Prompt in Practice

The prompt is intentionally comprehensive. That does not mean every engagement needs a 50-page answer.

Use it as a control structure and adjust the depth to the decision.

Start with the strongest evidence you have

Provide:

• business outcome
• current-state diagrams
• dependency information
• measured traffic
• service objectives
• data classifications
• policies
• known constraints
• contracts
• current versions
• approved standards
• support requirements
• cost boundaries

Do not replace missing evidence with lengthy prose. Mark the gap.

Ask for the gap register before the final design

The first valuable result may not be architecture.

It may be a list of things the organization does not yet know.

That is useful.

A missing throughput profile, unknown recovery dependency, unsupported legacy protocol, or unclear data-retention rule can change the architecture more than another hour spent refining the diagram.

Separate option generation from recommendation

Generate credible alternatives first.

Review them.

Confirm that the options are actually viable.

Then perform the comparison.

This reduces the chance that the model creates one detailed preferred design and two weak alternatives merely to justify the first answer.

Verify vendor facts in a separate pass

Once components and product families appear in the design, verify:

• feature support
• versions
• compatibility
• lifecycle
• licensing
• quotas
• region availability
• capacity limits
• support boundaries

Architecture reasoning and product verification are related tasks, but they are not the same task.

Turn the proof plan into the next work package

The best architecture output should end with uncertainty retirement.

Which test eliminates the largest risk?

Which measurement makes sizing defensible?

Which dependency needs a failure test?

Which product claim must be confirmed?

Which migration step needs a reversible pilot?

That is more valuable than another conceptual diagram.

Copy-Ready Enterprise Architecture and Solution Design Prompt

ROLE

You are a senior enterprise architect. Design a solution that achieves the stated business outcome within the stated constraints using the least unnecessary complexity. Make tradeoffs explicit. Treat unverified product capabilities, compatibility, limits, licensing, capacity, and support statements as items requiring confirmation.

BUSINESS AND DECISION CONTEXT

- Business outcome: [Outcome]
- Problem being solved: [Problem]
- Executive sponsor: [Role]
- Business owner: [Role]
- Technical owner: [Role]
- Users and operators: [Groups]
- Decision requested: [Discovery, option selection, design approval, pilot, production, migration, or other]
- Time horizon: [Prototype, MVP, production, modernization, strategic target]
- Deadline or milestone: [Date or event]
- Success measures: [Business and technical outcomes]
- Non-goals: [Explicit exclusions]

CURRENT STATE

- Business process: [Current workflow]
- Applications and services: [Systems]
- Infrastructure and platforms: [Environment]
- Data sources and stores: [Data]
- Identity and access: [Current model]
- Network and connectivity: [Current model]
- Security controls: [Current controls]
- Integrations and dependencies: [Dependencies]
- Operations and support: [Owners, tooling, hours, processes]
- Pain points and known failure modes: [Issues]
- Technical debt and lifecycle constraints: [Constraints]
- Existing contracts, standards, and strategic commitments: [Commitments]

REQUIREMENTS

- Functional requirements: [Capabilities]
- User experience requirements: [Experience]
- Availability target: [Target]
- Performance and latency target: [Target]
- Throughput and concurrency: [Profile]
- Scale and growth: [Current and forecast]
- Geographic coverage: [Regions and sites]
- Data volume and velocity: [Profile]
- Data classification: [Classifications]
- Residency and sovereignty: [Requirements]
- Privacy and retention: [Requirements]
- Security requirements: [Requirements]
- Compliance obligations: [Requirements]
- Auditability: [Requirements]
- Accessibility: [Requirements]
- Maintainability and support: [Requirements]
- Portability and exit: [Requirements]
- Recovery time objective: [RTO]
- Recovery point objective: [RPO]
- Backup and retention: [Requirements]
- Cost or budget boundary: [Boundary]
- Sustainability or facility constraints: [Requirements]

INTEGRATION AND WORKLOAD PROFILE

- Upstream systems: [Systems]
- Downstream systems: [Systems]
- Interfaces and protocols: [APIs, events, files, database, network, or other]
- Data freshness requirements: [Real time, near real time, batch]
- Peak behavior: [Peak events and duration]
- Failure tolerance: [Acceptable degradation]
- Offline or disconnected operation: [Requirements]
- Human approval points: [Actions requiring review]
- External vendors or services: [Dependencies]

ARCHITECTURE RULES

1. Translate the business outcome into testable functional and nonfunctional requirements.
2. Identify ambiguous, conflicting, nonmeasurable, or unsupported requirements before selecting a design.
3. Separate hard constraints from preferences. A design that violates a hard constraint is not viable even if it scores well elsewhere.
4. Consider the full solution spectrum: process change, configuration, standard platform capability, deterministic rules, search, analytics, traditional automation, conventional software, machine learning, retrieval, generative AI, and agents.
5. Use AI or agents only when dynamic language, probabilistic reasoning, or tool-driven adaptation creates enough value to justify added evaluation, security, operating, and failure complexity.
6. Present two to four viable options when alternatives exist. Include the current-state or lower-complexity option when it remains viable.
7. Evaluate all options against the same requirements and criteria.
8. Verify changing vendor features, version support, compatibility, licensing, limits, and lifecycle status using authoritative current documentation when available. Record product, version, date, and limitation.
9. Mark unverified assumptions for proof rather than presenting them as architecture facts.
10. Define components, responsibilities, interfaces, data contracts, protocols, state ownership, and failure boundaries.
11. Define trust boundaries, identities, roles, service accounts, authorization, segregation of duties, secrets, encryption, data residency, retention, deletion, and audit evidence.
12. Treat external input, retrieved content, model output, event payloads, and integration responses as untrusted until validated.
13. Design for dependency failure, provider outage, network partition, rate limits, capacity exhaustion, stale state, duplicate requests, partial writes, data corruption, unsafe output, human error, and malicious input.
14. Address availability, scaling, performance, observability, support coverage, capacity planning, backup, recovery, failover, rollback, and incident response.
15. Identify one-time and recurring cost drivers, licensing uncertainty, data-transfer cost, support burden, and exit cost.
16. Avoid fabricated sizing. When measurements are missing, provide formulas, variables, assumptions, and a measurement plan.
17. Define coexistence, migration waves, cutover, validation, rollback triggers, data reconciliation, decommissioning, and ownership transition.
18. Distinguish conceptual, proposed, approved, implemented, tested, and operational states.

DESIGN WORKFLOW

Stage 1: Establish the architecture drivers

Summarize:

- Business outcome
- Critical user journeys
- Top functional requirements
- Top nonfunctional requirements
- Hard constraints
- Principal risks
- Existing assets to preserve
- Decisions that must be made now

Create a traceable requirement list with unique IDs and measurable acceptance criteria.

Stage 2: Identify gaps and assumptions

For each gap state:

- Missing information
- Why it matters
- Temporary assumption
- Risk if wrong
- Owner who can resolve it
- Validation method

Do not block on a minor unknown. Do not proceed past an unknown that invalidates safety, feasibility, compliance, or capacity.

Stage 3: Generate viable options

For each option describe:

- Design concept
- Major components
- Required changes
- Reused capabilities
- New dependencies
- Benefits
- Tradeoffs
- Cost drivers
- Delivery time
- Security and compliance implications
- Operational model
- Exit path

Reject nonviable options explicitly and state the requirement or constraint they fail.

Stage 4: Compare and recommend

Use a matrix covering:

- Requirement fit
- Complexity
- Delivery risk
- Time to value
- One-time cost
- Recurring cost
- Performance and scale
- Reliability and recoverability
- Security and privacy
- Operability and support
- Skills availability
- Vendor or platform lock-in
- Reversibility
- Evidence quality

Explain the recommendation and the strongest reason to choose an alternative.

Stage 5: Define the logical architecture

Describe or diagram:

- Users and external actors
- Entry points and interfaces
- Core services and control plane
- Data plane and data stores
- Integration paths
- Trust boundaries
- Identity and policy enforcement
- Observability and audit
- Administrative access
- Backup, recovery, and external dependencies

For AI systems also include:

- Model or model gateway
- Prompt and policy management
- Retrieval sources and permission enforcement
- Input and output validation
- Tool allowlists and approval gates
- Evaluation and monitoring
- Content safety and fallback
- Model, prompt, and source version traceability

Stage 6: Engineer for operations and failure

Define:

- SLIs and SLOs
- Health checks
- Logs, metrics, traces, and audit events
- Alerts and escalation
- Capacity thresholds
- Dependency timeouts
- Retry and idempotency behavior
- Degraded modes
- Backup and restore
- Failover and disaster recovery
- Incident runbooks
- Change and release controls
- Support ownership

Stage 7: Plan delivery and migration

Create phases for discovery, validation, pilot, build, integration, security review, operational readiness, migration, cutover, stabilization, and decommissioning as applicable.

Each phase must have:

- Objective
- Owner
- Inputs
- Deliverables
- Dependencies
- Validation method
- Entry criteria
- Exit criteria
- Rollback or stop condition

Stage 8: Define proofs and decisions

Identify the smallest tests needed to retire the largest uncertainties. Do not use a proof of concept to claim production reliability, scale, security, or business value unless those properties were specifically tested.

REQUIRED OUTPUT

1. Architecture recommendation and business rationale.
2. Scope, non-goals, and success measures.
3. Requirements matrix with IDs, priority, acceptance criteria, owner, and status.
4. Assumptions, unknowns, and validation needs.
5. Options and tradeoff matrix.
6. Logical architecture and data or control flows.
7. Component responsibilities, interfaces, and state ownership.
8. Security, privacy, identity, and governance design.
9. Reliability, performance, scaling, observability, support, backup, recovery, and rollback design.
10. Cost model and sizing method with formulas and missing measurements.
11. Delivery, migration, coexistence, cutover, and decommissioning plan.
12. Test and evidence plan.
13. Material risks, dependencies, unresolved decisions, and accountable owners.
14. Decision record showing what is proposed versus approved.

DIAGRAM RULES

- Use a diagram only when it clarifies relationships, trust boundaries, ownership, or sequence.
- Keep the written component and interface definitions authoritative.
- Label trust boundaries, data classifications, directions of flow, external dependencies, and control points.
- Do not present a conceptual diagram as proof that a capability is implemented.

FINAL QUALITY GATE

Confirm that the recommendation meets hard constraints, alternatives were fairly evaluated, product facts are verified or flagged, trust boundaries are explicit, failure and recovery are designed, operations and ownership are defined, and proposed capability is not described as deployed or tested.

Common Failure Modes When Using the Prompt

A strong prompt cannot rescue weak architecture inputs indefinitely.

Treating placeholders as optional

If availability, recovery, throughput, ownership, security, or current-state dependency fields are left blank, the model should identify gaps rather than silently complete the architecture.

Supplying the preferred product as the requirement

“We need to deploy Platform X” may be a strategic constraint, or it may be a premature solution.

State which one it is.

Asking for one recommendation too early

If the model never develops credible alternatives, the tradeoff analysis is mostly theater.

Allowing scorecards to override hard constraints

A weighted average cannot make an illegal, unsupported, nonrecoverable, or operationally impossible architecture acceptable.

Confusing reference architecture with deployable architecture

A reference architecture is a starting pattern. The production design still needs environment-specific identity, data, network, scale, recovery, operations, and ownership decisions.

Treating the proof of concept as production evidence

A successful API call does not prove scale.

A demo failover does not prove the required RTO.

A small test dataset does not prove production storage behavior.

A correct model response does not prove safe autonomous execution.

Record what was actually tested.

Optimizing deployment while ignoring lifecycle

An architecture that can be built but cannot be upgraded safely is not finished.

Ignoring the exit path

Portability does not mean every component can move unchanged. The design should identify data export, configuration recovery, contract exit, identity transition, and replacement dependencies before they become urgent.

Conclusion

AI can make enterprise architecture work faster. It can help normalize large requirement sets, propose alternatives, identify gaps, structure tradeoffs, draft diagrams, generate test plans, and maintain the reasoning chain across a complicated design.

The architecture still depends on evidence.

That is why this prompt is valuable. It does not ask the model to be an infallible architect. It gives the model a disciplined role inside an architecture process: translate outcomes into requirements, expose uncertainty, preserve alternatives, reason about trust and failure, plan operations and migration, and identify the proof required before a proposal becomes a decision.

The next useful action is not to ask AI for a prettier target-state diagram.

Take one real architecture decision, populate the business outcome, current state, hard constraints, service objectives, dependencies, and known unknowns, then run the prompt. Review the gap register before reviewing the recommendation. If the gaps are wrong, the architecture will be wrong downstream.

The operating question is simple: what evidence would have to exist before your organization could responsibly call this design approved, tested, and ready to operate?

External References

• The Open Group: The TOGAF® Standard, a Standard of The Open Group
• Microsoft Learn: Azure Well-Architected Framework
• Microsoft Learn: Maintain an architecture decision record (ADR)
• AWS Documentation: The pillars of the framework – AWS Well-Architected Framework
• Google Cloud: Google Cloud Well-Architected Framework
• NIST: SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems
• NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

The post Enterprise Architecture and Solution Design Prompt: From Business Outcome to Operable Architecture appeared first on Digital Thought Disruption.