architecture-enterprise-alignment

What this skill does

# Architecture Enterprise Alignment Skill

## Purpose

This skill maps a **Product Owner Specification** (Phase 1 artifact) onto the **organization's BIAN v14 capability map** (8 top-level domains, 47 capabilities) to produce `ENTERPRISE_ALIGNMENT.md` at the project root.

The report identifies — **before** the architecture team begins design — which corporate domains are impacted, which governance rules apply, which owner counterparts must be engaged, and where cross-cutting concerns (Finance & Risks, Business Enabler, Enterprise Management) require mandatory checks.

It answers: *"Which enterprise domains does this initiative touch, what governance rules will constrain it, and who do we need to talk to before designing?"*

**Output**: `ENTERPRISE_ALIGNMENT.md` at the project root — single markdown file designed for tickets, emails, Architecture Review Boards, and stakeholder kickoffs.

**Mandatory gate**: `architecture-docs` Workflow 1 (Step 0.3) BLOCKS new ARCHITECTURE.md creation until this file exists.

---

## When to Invoke This Skill

- User asks to "align with enterprise architecture", "map to enterprise domains", or "load enterprise context"
- User asks to "check enterprise alignment" or "run enterprise domain mapping"
- User has just accepted the PO Spec and needs to proceed to architecture design
- `architecture-docs` Workflow 1 Step 0.3 directs the user here because `ENTERPRISE_ALIGNMENT.md` is missing
- User uses `/skill architecture-enterprise-alignment`

**Do NOT invoke for:**
- Creating or editing the PO Spec → use `architecture-readiness` skill
- Creating or editing ARCHITECTURE.md → use `architecture-docs` skill
- PO Spec coverage analysis → use `architecture-traceability` skill
- Compliance contracts → use `architecture-compliance` skill
- Architecture quality/peer review → use `architecture-peer-review` skill

---

## Files in This Skill

| File | Purpose |
|------|---------|
| `SKILL.md` | This file — entry point and workflow |
| `ENTERPRISE_MODEL.md` | Bundled 8-domain default model (BIAN v14, 47 capabilities). Used unless overridden by a project-local `ENTERPRISE_MODEL.md` at the project root. |
| `ENTERPRISE_ALIGNMENT_TEMPLATE.md` | Output template — Summary table, per-domain analysis (8 sub-sections), Cross-Cutting Findings, Owner Engagement Plan, Next Steps |
| `ANALYSIS_METHODOLOGY.md` | How to extract business capabilities from the PO Spec and classify each domain — "What vs. How" rule, evidence citation, cross-cutting checks |

---

## Workflow

### Step 1 — Locate PO Spec File

Search for the Product Owner Specification:

```
Search order:
1. PRODUCT_OWNER_SPEC.md at project root
2. PO_SPEC.md at project root
3. Glob **/PRODUCT_OWNER_SPEC.md, **/PO_SPEC.md
4. Glob **/po-spec*, **/product-owner*
5. Ask user for path
```

If no PO Spec found, abort with: *"No Product Owner Specification found. Use `/sa-skills:architecture-readiness` to create one first — enterprise alignment requires accepted business context."*

If multiple matches, list them and ask the user to select one.

---

### Step 2 — Locate Enterprise Model

Resolve which enterprise model to use:

```
Resolution order:
1. ENTERPRISE_MODEL.md at project root  → project-local override
2. Bundled default at <plugin>/skills/architecture-enterprise-alignment/ENTERPRISE_MODEL.md
```

Record the source so it can be cited in the report header:
- `Enterprise Model: project-local override (ENTERPRISE_MODEL.md)` if (1) found
- `Enterprise Model: bundled default (sa-skills v{plugin-version})` if (2) used

If neither exists (plugin install corrupted), abort with: *"Bundled ENTERPRISE_MODEL.md missing from plugin. Reinstall sa-skills or provide a project-local ENTERPRISE_MODEL.md."*

Read the resolved model fully. The bundled default defines 8 top-level domains (Enterprise Management, Resource Management, Finance & Risks, Operations, Products, Customers, Channels, Business Enabler) covering 47 capabilities, plus 8 cross-cutting governance principles.

---

### Step 3 — Extract Business Capabilities from PO Spec

Read the PO Spec and extract business-capability evidence from these sections (matching the structure in `skills/architecture-readiness/templates/PO_SPEC_TEMPLATE.md`):

| PO Spec Section | What to extract | Feeds which domains |
|-----------------|-----------------|---------------------|
| § 1 Business Context | Problem statement, target market, strategic alignment, timing | Customers, Enterprise Management |
| § 2 Stakeholders & Users | User personas (employees vs customers vs prospects), stakeholder roles | Customers, Resource Management (if employees are users) |
| § 3 Business Objectives | Goals, KPIs, monetary impact, customer impact | Products, Customers, Finance & Risks |
| § 4 Use Cases | Actors, primary/alternative flows, edge cases | All 8 (most evidence-rich section) |
| § 5 User Stories | Acceptance criteria, role-based capabilities | Customers, Channels |
| § 6 UX Requirements | Channels mentioned, performance, accessibility | Channels |
| § 7 Business Constraints | Regulatory, integration, budget, operational | Finance & Risks, Business Enabler, Resource Management, Enterprise Management |
| § 8 Success Metrics | Adoption, KPIs, leading/lagging indicators | All cross-cutting (Enterprise Management, Finance & Risks, Business Enabler) |

**Extraction filter — "What vs. How"**: When the PO Spec mentions specific technologies, vendors, or implementation paths (e.g., "integrate with the interbank settlement network via SOAP"), record the **business capability** ("inter-bank transfer settlement") not the implementation. The "how" belongs to the architecture team; the alignment maps "what" against enterprise domains.

Produce a structured capability list:

```yaml
capabilities:
  - text: "<short business-capability statement>"
    source: "§ <section number> — <heading>"
    evidence_quote: "<verbatim excerpt, max 200 chars>"
    actors: ["<actor>", ...]      # if mentioned
    channels: ["<channel>", ...]  # if mentioned
    money_flow: true|false        # does it move money?
    data_touched: ["<entity>", ...] # customer, product, transaction, etc.
```

Capabilities are the unit of analysis for Step 4.

---

### Step 4 — Per-Domain Classification

For each of the 8 domains in the Enterprise Model, perform classification:

**Status taxonomy**:

- **🟢 Impacted** — At least one PO Spec capability falls squarely inside this domain's purpose. Governance rules WILL apply. Owner counterparts MUST be engaged.
- **🟡 Partial** — The initiative touches the edges of this domain (e.g., consumes a service from this domain) but does not own capabilities inside it. Selected governance rules apply (typically "integration by contract" / "consume as service" rules).
- **⚪ Not Applicable** — No PO Spec capability touches this domain. No owner engagement needed.

For each domain, capture:

1. **Status** — 🟢 / 🟡 / ⚪
2. **Rationale** — one sentence explaining the classification
3. **Rules Triggered** — verbatim citations from `ENTERPRISE_MODEL.md` § "Governance rules" for that domain (quote literally — do not paraphrase)
4. **Impacted Capabilities** — for every 🟢 / 🟡 domain, classify each of the domain's canonical capabilities (listed under `**Capabilities**` in `ENTERPRISE_MODEL.md` § 3.X) using the same 🟢 / 🟡 / ⚪ taxonomy. Output a bullet list of every 🟢 / 🟡 capability with per-capability status, one-line rationale, and PO Spec § citation, followed by a parenthesized `(not impacted: <comma-separated remaining capability names>)` footer. ⚪ domains use the single line `_None._` (or `_None — see § Cross-Cutting Findings._` for mandatory-check domains). Capability names cited **verbatim** — no abbreviation, no aliasing.
5. **Evidence** — bulleted excerpts from the PO Spec capability list with source section reference
6. **Owner Counterparts** — roles to engage, derived from the domain's stated owner (per the model) and the rule wording (e.g., "must be validated by Archi