Service Line

Enterprise Architecture

Enterprise Architecture Service Line

One-liner. Take a client's existing IT/business landscape (or planned transformation) and produce a structured LeanIX-aligned catalog + interactive HTML diagrams, published directly to the client's website (JCT portail) by the EA digital talent itself.

This is the factory's most mature service line. It is the reference pattern that the other lines are modeled against.

Strategic direction (2026-05-14): Confluence is fully dropped. The EA service publishes HTML directly to the per-client JCT subdomain. The EA digital talent (Edward, agent-ea v2) owns its own publishing pipeline — the factory does not push a separate publish step. Integration with JSM (Jira Service Management) wires deliverables into the client's ticket lifecycle.

When to use this line

Use the EA line when the client request is about understanding, documenting, comparing, or transforming an architecture:

  • "Document our integration landscape" — as-is mapping
  • "Compare option A vs option B for migrating off BizTalk" — orientation memo with CO scenarios
  • "We're acquiring company X — show me the combined IT portfolio" — M&A catalog merge
  • "Where are our end-of-life technologies?" — lifecycle analysis
  • "What capabilities does our application portfolio actually support?" — capability-to-app mapping
  • "We need a vigie/dashboard on our integration platform" — operational EA monitoring

Do not use this line for: building a custom digital talent (→ Talent Factory Build), auditing a process (→ Consulting), evaluating a tool for adoption (→ R&D).

Inputs

A valid EA request provides one or more of:

Input type Examples Maps to extraction mode
Codebase .csproj, .odx, .btm, .bicep, .tf, Logic Apps definitions Code analysis
Documents Existing architecture docs, PPT, Word, Excel, Visio exports Document analysis
Migration scope Legacy + target tech files together OR keyword "migration" Migration project (two-pass)
Existing catalog Prior CSVs to enrich or validate Validation mode
Interview only No source material, capture from stakeholder Interactive capture

The intake form (/request-create --service=ea) collects:

  1. Client + sponsor
  2. Scope statement (one sentence)
  3. Mode hint (auto-detected at extraction)
  4. Source path(s) or interview availability
  5. Output naming hints (Display_Name conventions, FR/EN)
  6. Deliverable target (catalog only / catalog + diagram / catalog + diagram + CO scenarios)
  7. Publishing destination (JCT subdomain or internal-only)

Standard production process

Stage 1 — Capture          /toolkit:note-create            (raw context)
   ↓
Stage 2 — Structure        /toolkit:note-review            (Q&A on gaps)
   ↓
Stage 3 — Extract          /ea:leanix-catalog-extract      (source → CSVs)
   ↓
Stage 4 — Generate         /toolkit:diagram-generate       (CSVs → HTML)
   ↓
Stage 5 — Optimize         /toolkit:auto-research          (binary eval loop)
   ↓
Stage 6 — Package          standalone HTML showpiece       (livrable)
   ↓
Stage 7 — Publish          JCT portail client repo         (deploy)

Stage details

Stage 3 — Extract. Output is two CSVs (sometimes three):

  • {slug}-objects.csv — 18 ID prefixes covering 12 SAP LeanIX fact sheets + 6 factory types (ROL, DEP, WFL, SKL, PRS, ITC/INT split). TOGAF layer assigned. 3 naming columns (Name = product, Display_Name = org alias, Group = concept) so the same data renders as physical, logical, or conceptual views.
  • {slug}-relations.csv — 12 standardized relationship types (9 LeanIX + 3 factory).
  • {slug}-co.csv (only for migration / orientation programs) — CO records using LeanIX lxImpactType for as-is → to-be diff.

Stage 4 — Generate. Output is one self-contained HTML file (zero external deps): sidebar with view presets, layer toggles, edge-type toggles, view-mode selector (Physical / Logical / Conceptual / Combined), clickable nodes, detail panel, zoom/pan, light theme with STM brand palette.

Stage 5 — Optimize. Run /toolkit:auto-research with binary eval criteria when the diagram needs to pass a specific quality bar (e.g., orchestration granularity for a BizTalk migration). Skip for simple as-is maps.

Stage 7 — Publish (self-published by Edward). Edward (the EA digital talent, agent-ea v2) writes the HTML livrable, commits it to the client's JCT portail repo (bockbr/jct-portail-{client}), adds a card to the hub (title + date + status + link), and pushes. Cloudflare Pages auto-deploys behind Cloudflare Access. The factory does not perform this step manually. See TFD-017 (JCT architecture) and REQ-CONS-008 (Edward self-publishing spec).

JSM integration. When the source ticket lives in Jira Service Management, Edward also:

  • Adds a "Livrable publié" comment on the originating JSM ticket with the JCT URL
  • Transitions the ticket to "Resolved" (or the equivalent workflow state)
  • Attaches the catalog CSVs as a .zip to the JSM ticket for audit trail
  • Stores the transcript reference (Maya conversation that led to the request, when applicable) in the ticket's External_Ref field

Wiring spec: REQ-CONS-010 (JSM ↔ EA service integration).

Deliverables (DAE-NNNN contract)

The output folder of an EA request always contains:

File Required Purpose
{slug}-objects.csv Yes Catalog data
{slug}-relations.csv Yes Relationships
{slug}-co.csv Migration/orientation only Change scenarios
{slug}-architecture.html Yes Interactive diagram (logical view default)
design-note-{topic}.md When framing decisions matter Logical-vs-physical, view-mode rationale, etc.
livrable.html When publishing Standalone showpiece pour le client (header + intro + diagram embed + closing)
README.md Yes Délai, mode d'extraction, source paths, publishing target

Numbered as DAE-NNNN within the client's OneDrive (OneDrive-STM/agent-ea/DAE-NNNN-{title}/). Internal references use the REQ ID; client-facing references use the DAE.

Acceptance Criteria (AC)

  • CSVs match the v3.1 unified schema (column names, value casing)
  • Every object has Type, Name, Display_Name, Description, Level, TOGAF_Layer, Lifecycle, Business_Criticality
  • No orphan objects (every object has either Parent_ID or at least one relationship)
  • All 4 view modes (physical / logical / conceptual / combined) render coherently — no Display_Name containing the product name in parentheses
  • Relationships use only the 12 standard types
  • Migration mode: CO records present for every decommissioned / introduced / migrated object
  • HTML diagram is self-contained (no external deps), light theme, opens in any modern browser
  • Bilingual content respected (FR for STM, EN for international clients) — column names always English
  • Sources cited (every non-trivial object has a Notes field with the source path)

Definition of Done (DoD)

  • AC all checked
  • Catalog reviewed against the migration validation checklist when applicable (10-item checklist in /ea:leanix-catalog-extract STEP 5)
  • Diagram passes auto-research eval (when run)
  • Livrable HTML opens cleanly behind JCT Cloudflare Access on the target subdomain
  • DAE folder structure complete, archived to OneDrive-STM/agent-ea/DAE-NNNN-*
  • Internal request folder closed via /request-close
  • Lesson learned captured in kb/learnings/ if the request surfaced a non-obvious pattern

Publishing target

Default: Jackson Creek Tech portail client.

  • Hub: {client}.jacksoncreektech.ca (Cloudflare Pages + Cloudflare Access, email magic-link auth)
  • Repo: bockbr/jct-portail-{client} (HTML/CSS only, no React/Next/Vue per TFD-017)
  • Hub card pattern: title + date + status + link to livrable.html
  • Pilot live: transgesco.jacksoncreektech.ca (DAE-0007)

Internal-only mode: if publishing_target = internal, output stays in the intranet under /diagrams or /architecture and never hits a public subdomain.

Look & feel — reuse the intranet aesthetic

The HTML livrable reuses the factory intranet visual language (Anthropic warm cream + Trustworthy Blue #2563EB, Instrument Serif headings, per project_docs-design-system). The diagram canvas keeps the STM brand palette internally (green/blue/yellow per /toolkit:diagram-generate).

The legacy drawio templates (9 STM-branded gabarits in v1 agent-ea .claude/commands/templates/) are retained as look-and-feel reference — integration card, ER model, BPMN, architecture applicative, business context, roadmap swimlane, roadmap timeline. They are not part of the v2 production chain, but their visual conventions inform the HTML diagram styling. Do not delete them.

Frameworks used

  • SAP LeanIX — primary catalog methodology (framework guide)
  • TOGAF — layer assignment (Business / Application / Data / Technology) (framework guide)
  • Macroscope — orientation memos when comparing scenarios (framework guide)

Worked examples

Request Mode Output Status
DAE-0007 — Transgesco Portrait TI Document analysis LeanIX catalog + diagram + livrable Shipped, published on transgesco.jacksoncreektech.ca
REQ-EXEC-007 — STM Vigie opérationnel Code analysis (BizTalk) Operational catalog Internal pilot
REQ-METH-002 — Unified LeanIX schema Schema design v3.1 unified CSV schema Shipped (reference)

Lead role

Edward — Enterprise Architect (digital talent). Lives as agent-ea (v1 frozen, v2 regen pending). Edward owns extraction, classification, diagram, and the publishing handoff. The factory's QA layer (Quincy) validates against AC/DoD before close.

Open follow-ons

  • REQ-CONS-008 — Agent-EA v2 self-publishing (Edward owns the publish-to-JCT pipeline)
  • REQ-CONS-010 — JSM integration into EA service line (ticket-aware publish, comment-back, transition)
  • REQ-CONS-XXX skill /ea:livrable-showpiece — automate the standalone livrable.html packaging
  • WO-DESIGN-XXX logo JCT — branding for the portail
  • agent-ea v2 regen — unblock once v1 freeze is lifted (precondition for REQ-CONS-008)

Source-of-truth links

  • Skill: .claude/commands/ea/leanix-catalog-extract.md
  • Skill: .claude/commands/toolkit/diagram-generate.md
  • Frameworks: production-lines/digital-talent/frameworks/enterprise-architecture/
  • Decision: company/decisions/TFD-017-jct-portail-architecture.md
  • Intake lifecycle: departments/consulting/requests/REQ-CONS-006-client-request-intake-lifecycle/