Enterprise Architecture
Use this skill to make enterprise-wide structure and change legible without turning
architecture into a shelf of diagrams. Connect outcomes to capabilities, value
streams, applications, information, technology, ownership, and a feasible sequence
of change.
Workflow
- Frame the enterprise question. State the outcome, scope, time horizon,
stakeholders, constraints, authority, and evidence gaps. Separate strategy,
product commitments, operational facts, and architectural hypotheses.
- Map the landscape. Identify capabilities and value streams, then relate
applications, information objects, technology dependencies, owners, costs,
risks, duplication, and lifecycle status. Use
references/capability-value-stream-and-portfolio-mapping.md.
- Describe states. Record the current state from evidence, define a target
state from explicit principles and outcomes, and identify constraints that make
a direct jump unsafe or unrealistic. Use
references/current-target-and-transition-architecture.md.
- Choose the operating model. Compare centralized, federated, and hybrid
arrangements against decision locality, coordination cost, required coherence,
skills, and risk. Do not prescribe reporting lines or compensation. Use
references/enterprise-operating-model-and-roles.md.
- Make authority executable. Assign decision rights, consultation, standards,
exceptions, escalation, and feedback to named roles. Use
references/federated-governance-and-decision-rights.md.
- Engage and publish for use. Adapt views to stakeholder jobs, make uncertainty
and provenance visible, and maintain accessible, findable information with a
review owner. Use
references/stakeholder-engagement-and-architecture-information.md.
- Sequence change. Connect transition increments to capabilities, outcomes,
dependencies, investment assumptions, and exit evidence. Use
templates/transition-architecture-roadmap.md; hand approved delivery plans to
implementation-planning or migration-engineering as appropriate.
Output Contract
Produce an enterprise context brief, capability/application portfolio view,
current-target-transition assessment, operating-model and decision-rights record,
or transition roadmap. Every material claim must be labeled as evidence,
assumption, decision, or open question and have a source or named owner.
Ownership Boundaries
- System boundaries, runtime behavior, architecture characteristics, and solution
tradeoffs belong to
software-architecture.
- API contracts and API portfolio mechanics belong to
api-design-and-evolution.
- Data platforms, data products, data models, and data governance belong to
data-architect.
- Reporting structures, team topology, talent, compensation, and culture belong to
org-design; this skill records organizational dependencies without designing HR
systems.
- Product bets, product outcomes, and product sequencing belong to
product-roadmapping-and-portfolio.
- Technology adoption posture, build-versus-buy, standards, and technology
governance mechanics belong to
technology-radar.
- Corporate direction, competitive choices, capital allocation, and M&A belong to
strategy-frameworks.
- Process optimization and operational execution belong to
operational-design;
enterprise architecture may use its findings as evidence.
- Approved cross-system execution belongs to
implementation-planning and
migration-engineering, not this skill.
- Cross-project program coordination, shared capacity, integrated benefits, and
transformation delivery belong to
technical-program-management; this skill
provides the architecture evidence and decision-rights inputs.
When Not To Use
Use the narrow owner when the request has no enterprise portfolio, cross-domain
alignment, operating-model, or transition-architecture question. Do not use this
skill to produce a solution design, organization chart, product roadmap, technology
radar entry, data architecture, API contract, or corporate strategy verdict.
Reference Guide
| Decision point |
Load |
| Mapping capabilities, value streams, applications, information, or duplication |
references/capability-value-stream-and-portfolio-mapping.md |
| Comparing current, target, and transition states |
references/current-target-and-transition-architecture.md |
| Selecting an enterprise operating model and defining architecture roles |
references/enterprise-operating-model-and-roles.md |
| Assigning decision rights, standards, exceptions, or escalation |
references/federated-governance-and-decision-rights.md |
| Interviewing stakeholders or publishing usable architecture information |
references/stakeholder-engagement-and-architecture-information.md |
| Establishing scope and evidence |
templates/enterprise-context-brief.md |
| Creating a portfolio view |
templates/capability-portfolio-view.md |
| Sequencing target-state change |
templates/transition-architecture-roadmap.md |
| Checking provenance and transformation constraints |
references/source-index.md |
Completion
Stop when the enterprise scope and decision owner are explicit, the portfolio and
state claims have evidence or named gaps, transition increments have dependencies
and exit evidence, decision rights include conflict handling, and specialist
handoffs are recorded. Escalate unresolved authority or strategy conflicts rather
than resolving them by assumption.
1---2name: enterprise-architecture3description: Design and evolve enterprise architectures by connecting business capabilities, value streams, applications, information, technology, operating models, and transition choices. Use when mapping an enterprise portfolio, comparing current and target states, sequencing transition architectures, or defining federated architecture decision rights and stakeholder communication. Do not use for system or solution design, API or data-platform design, organizational or talent design, product roadmaps, technology adoption, or corporate strategy; route those to the named specialist skills.4license: MIT5---67# Enterprise Architecture89Use this skill to make enterprise-wide structure and change legible without turning10architecture into a shelf of diagrams. Connect outcomes to capabilities, value11streams, applications, information, technology, ownership, and a feasible sequence12of change.1314## Workflow15161. **Frame the enterprise question.** State the outcome, scope, time horizon,17 stakeholders, constraints, authority, and evidence gaps. Separate strategy,18 product commitments, operational facts, and architectural hypotheses.192. **Map the landscape.** Identify capabilities and value streams, then relate20 applications, information objects, technology dependencies, owners, costs,21 risks, duplication, and lifecycle status. Use22 `references/capability-value-stream-and-portfolio-mapping.md`.233. **Describe states.** Record the current state from evidence, define a target24 state from explicit principles and outcomes, and identify constraints that make25 a direct jump unsafe or unrealistic. Use26 `references/current-target-and-transition-architecture.md`.274. **Choose the operating model.** Compare centralized, federated, and hybrid28 arrangements against decision locality, coordination cost, required coherence,29 skills, and risk. Do not prescribe reporting lines or compensation. Use30 `references/enterprise-operating-model-and-roles.md`.315. **Make authority executable.** Assign decision rights, consultation, standards,32 exceptions, escalation, and feedback to named roles. Use33 `references/federated-governance-and-decision-rights.md`.346. **Engage and publish for use.** Adapt views to stakeholder jobs, make uncertainty35 and provenance visible, and maintain accessible, findable information with a36 review owner. Use `references/stakeholder-engagement-and-architecture-information.md`.377. **Sequence change.** Connect transition increments to capabilities, outcomes,38 dependencies, investment assumptions, and exit evidence. Use39 `templates/transition-architecture-roadmap.md`; hand approved delivery plans to40 `implementation-planning` or `migration-engineering` as appropriate.4142## Output Contract4344Produce an enterprise context brief, capability/application portfolio view,45current-target-transition assessment, operating-model and decision-rights record,46or transition roadmap. Every material claim must be labeled as evidence,47assumption, decision, or open question and have a source or named owner.4849## Ownership Boundaries5051- System boundaries, runtime behavior, architecture characteristics, and solution52 tradeoffs belong to `software-architecture`.53- API contracts and API portfolio mechanics belong to `api-design-and-evolution`.54- Data platforms, data products, data models, and data governance belong to55 `data-architect`.56- Reporting structures, team topology, talent, compensation, and culture belong to57 `org-design`; this skill records organizational dependencies without designing HR58 systems.59- Product bets, product outcomes, and product sequencing belong to60 `product-roadmapping-and-portfolio`.61- Technology adoption posture, build-versus-buy, standards, and technology62 governance mechanics belong to `technology-radar`.63- Corporate direction, competitive choices, capital allocation, and M&A belong to64 `strategy-frameworks`.65- Process optimization and operational execution belong to `operational-design`;66 enterprise architecture may use its findings as evidence.67- Approved cross-system execution belongs to `implementation-planning` and68 `migration-engineering`, not this skill.69- Cross-project program coordination, shared capacity, integrated benefits, and70 transformation delivery belong to `technical-program-management`; this skill71 provides the architecture evidence and decision-rights inputs.7273## When Not To Use7475Use the narrow owner when the request has no enterprise portfolio, cross-domain76alignment, operating-model, or transition-architecture question. Do not use this77skill to produce a solution design, organization chart, product roadmap, technology78radar entry, data architecture, API contract, or corporate strategy verdict.7980## Reference Guide8182| Decision point | Load |83|---|---|84| Mapping capabilities, value streams, applications, information, or duplication | `references/capability-value-stream-and-portfolio-mapping.md` |85| Comparing current, target, and transition states | `references/current-target-and-transition-architecture.md` |86| Selecting an enterprise operating model and defining architecture roles | `references/enterprise-operating-model-and-roles.md` |87| Assigning decision rights, standards, exceptions, or escalation | `references/federated-governance-and-decision-rights.md` |88| Interviewing stakeholders or publishing usable architecture information | `references/stakeholder-engagement-and-architecture-information.md` |89| Establishing scope and evidence | `templates/enterprise-context-brief.md` |90| Creating a portfolio view | `templates/capability-portfolio-view.md` |91| Sequencing target-state change | `templates/transition-architecture-roadmap.md` |92| Checking provenance and transformation constraints | `references/source-index.md` |9394## Completion9596Stop when the enterprise scope and decision owner are explicit, the portfolio and97state claims have evidence or named gaps, transition increments have dependencies98and exit evidence, decision rights include conflict handling, and specialist99handoffs are recorded. Escalate unresolved authority or strategy conflicts rather100than resolving them by assumption.
magnus919