Agent Instructions: Fujitsu Macroscope

Agent Instructions: Fujitsu Macroscope

For use by digital talents deployed with the Macroscope framework Based on: framework-guide-template.md Client context: STM (Societe de transport de Montreal)

How to Apply This Framework

Macroscope organizes enterprise architecture work into four service areas (Exigences, Architecture, Changement, Qualite) that map to specific deliverables identified by A-codes. When working with STM architects, use Macroscope artifact names and codes as the primary vocabulary, and map data to LeanIX Fact Sheets for storage and analysis.

The workflow follows Macroscope's natural sequence: Requirements define goals, Architecture designs the solution, Change plans the transformation, and Quality validates the result.

Service 1 — Exigences d'entreprise (Enterprise Requirements)

Establish the strategic context and business requirements that drive architecture decisions.

Step 1: Capture Enterprise Context (A140)

  1. Document the organizational structure — business units, teams, reporting lines
  2. Map value streams and customer journeys that define how the business creates value
  3. Identify market context, regulatory constraints, and strategic drivers
  4. LeanIX mapping: Organization fact sheets (legalEntity, country, businessUnit, team) + BusinessContext fact sheets (valueStream, customerJourney)

Step 2: Define Business Scenarios (A130)

  1. Identify desired business outcomes in the client's own words
  2. Structure each scenario: stakeholder, business goal, current pain, desired future state
  3. Prioritize scenarios by business impact and feasibility
  4. LeanIX mapping: Objective fact sheets with objectiveType: tactical

Step 3: Formalize Enterprise Requirements (A240)

  1. Translate business scenarios into structured requirements (strategic and operational goals)
  2. Categorize: strategic objectives (organization-wide), operational requirements (process-level)
  3. Establish measurable success criteria for each requirement
  4. LeanIX mapping: Objective fact sheets with objectiveType: strategic or operational

Step 4: Document Principles and Rules (A360)

  1. Define architecture principles: technology neutrality, reuse, interoperability, security-by-design
  2. Document business rules that constrain architecture choices
  3. Validate principles against enterprise requirements
  4. LeanIX mapping: Objective fact sheets with objectiveType: strategic (principles as guiding objectives). Business rules are captured in descriptions — no direct LeanIX equivalent.

Service 2 — Architecture d'entreprise (Enterprise Architecture)

Design the enterprise architecture across business, information, application, and technology layers.

Step 5: Map Business Capabilities (A200)

  1. Build a hierarchical business capability map (L1 through L4)
  2. For each capability: identify strategic importance (parity, tier2, tier1), current maturity, target maturity
  3. Link capabilities to the business processes that implement them
  4. Identify AI transformation potential per capability
  5. LeanIX mapping: BusinessCapability fact sheets with hierarchy (relToParent/relToChild), capabilityLevel (auto-set from depth), strategicImportance, currentMaturity, targetMaturity, aiPotential

Step 6: Define Architecture Orientations (A230)

  1. For each business scenario, define architecture orientations — strategic direction documents
  2. Each orientation drives one or more target-state projections
  3. Document the rationale linking orientation to business requirement
  4. LeanIX mapping: Initiative fact sheets with category: idea. Each orientation = 1 Initiative.

Step 7: Catalog Systems / Applications (A250)

  1. Inventory all applications: name, description, business owner, technical owner
  2. Assess each application: lifecycle status, business criticality, functional suitability, technical suitability
  3. Classify subtypes: businessApplication, microservice
  4. Map application-to-capability relationships (which apps support which capabilities)
  5. Map application-to-technology relationships (which tech components each app uses)
  6. LeanIX mapping: Application fact sheets with all standard fields. Key relationships: relAppToBC (with functionalSuitability), relAppToITC (with technicalSuitability)

Step 8: Document Business Processes (A251)

  1. Catalog business processes in a hierarchy (category, group, process, variant)
  2. Assess maturity level and automation level for each process
  3. Map processes to supporting applications and data objects
  4. LeanIX mapping: BusinessProcess fact sheets with subtypes. Relationships: relProcessToApp, relProcessToBC, relProcessToDataObj

Step 9: Model Information Architecture (A170)

  1. Identify data entities and information assets
  2. Classify data: public, sensitive, restricted, confidential
  3. Map data flows between applications (CRUD: create, read, update, delete)
  4. LeanIX mapping: DataObject fact sheets with dataClassification. Relationship: relAppToDataObj with usage (CRUD as MULTIPLE_SELECT)

Step 10: Map Technology Infrastructure (A370)

  1. Inventory technology components: software, hardware, cloud services (SaaS, PaaS, IaaS)
  2. Track lifecycle status and vendor lifecycle (active, end of life, extended support)
  3. Categorize using TechnicalStack (technology groups: Database, Middleware, Framework, etc.)
  4. Map technology-to-application dependencies
  5. LeanIX mapping: ITComponent fact sheets with subtypes (software, hardware, saas, paas, iaas, service, llm). TechnicalStack fact sheets for categorization. Platform fact sheets for grouping. Relationships: relAppToITC, relITCToTechStack (with resourceClassification for tech radar)

Step 11: Software Architecture (A219) and Work Environments (A269)

  1. Document software component architecture (microservices, APIs, shared libraries)
  2. Map physical and virtual work environments
  3. LeanIX mapping: Application (microservice subtype) + ITComponent for software. ITComponent (hardware) for work environments.

Service 3 — Changement organisationnel (Organizational Change)

Plan and manage the transformation from current-state to target-state architecture.

Step 12: Define Enterprise Solutions (A100)

  1. For each architecture orientation, define concrete solution proposals
  2. Each solution becomes a project or program with defined scope, timeline, and resources
  3. Link solutions to the business requirements and architecture artifacts they address
  4. LeanIX mapping: Initiative fact sheets with category: project or program. Link to Objectives, Applications, ITComponents via Initiative relationships.

Step 13: Analyze Impacts (A280)

  1. For each solution, identify what changes to which architecture elements
  2. Classify impact types: introduction (new), decommissioning (retire), rollout (deploy), withdrawal (remove), scope change
  3. Identify transformation types: implement new application, upgrade technology, custom development
  4. LeanIX mapping: Impact is captured as relation attributes on Initiative-to-Application and Initiative-to-ITComponent relationships: lxImpactType (MULTIPLE_SELECT) and transformationType (MULTIPLE_SELECT)

Step 14: Estimate Costs and Benefits (A290)

  1. Estimate budget and actual costs per solution
  2. Document expected benefits (qualitative and quantitative)
  3. Calculate cost per affected architecture object where possible
  4. LeanIX mapping: Initiative fields: costBudget, costActual. Per-object costs via relAppToITC.costTotalAnnual on relationships.

Step 15: Plan Delivery Strategy (A270)

  1. Define implementation phases with start and end dates
  2. Sequence solutions based on dependencies, risk, and business value
  3. Create a transformation roadmap with milestones
  4. LeanIX mapping: Initiative lifecycle phases (plan, phaseIn, active, phaseOut) with dates. Fields: startDate, endDate.

Step 16: Plan Organizational Change (A275)

  1. Identify organizational units affected by each solution
  2. Define change management activities: communication, training, stakeholder engagement
  3. Assign change ownership
  4. LeanIX mapping: Initiative-to-Organization relationships showing which org units are affected.

Service 4 — Assurance qualite (Quality Assurance)

Validate architecture work against requirements and quality criteria.

Step 17: Define Evaluation Criteria (A610)

  1. Establish criteria for evaluating architecture quality: completeness, consistency, alignment with principles
  2. Configure quality rules (what constitutes a "complete" fact sheet)
  3. LeanIX mapping: Quality Seal configuration — define completion rules per fact sheet type.

Step 18: Evaluate Architecture (A620)

  1. Assess each application and IT component against functional suitability and technical suitability scales
  2. Conduct architecture reviews at defined checkpoints
  3. Document evaluation results and remediation actions
  4. LeanIX mapping: functionalSuitability (perfect, appropriate, insufficient, unreasonable) and technicalSuitability (fullyAppropriate, adequate, unreasonable, inappropriate) on fact sheets and relationships. Quality Seal workflow: DRAFT -> APPROVED -> BROKEN_QUALITY_SEAL.

Step 19: Track Requirements (A900)

  1. Monitor progress of each requirement/objective (0-100%)
  2. Link requirements to the architecture artifacts and solutions that address them
  3. Flag requirements at risk
  4. LeanIX mapping: Objective fact sheets with progress field (NUMBER, 0-100). Relationships to BusinessCapability, Initiative, Application.

Step 20: Audit Compliance (A905)

  1. Verify that solutions meet their stated requirements
  2. Conduct gap analysis between committed scope and delivered capability
  3. Document compliance status and exceptions
  4. LeanIX mapping: Quality Seal workflow — move fact sheets from DRAFT through APPROVED. Flag BROKEN_QUALITY_SEAL when changes invalidate prior approval.

Deliverables

Macroscope Artifact A-Code Format Template Description
Enterprise Context A140 Markdown templates/enterprise-context-template.md Organizational structure and strategic context
Business Capability Map A200 CSV + Markdown Use LeanIX object-catalog-schema.csv Hierarchical capability map (L1-L4)
Application Portfolio A250 CSV + Markdown Use LeanIX application-catalog-template.csv System inventory with lifecycle and fit assessment
Architecture Orientation A230 Markdown templates/architecture-orientation-template.md Strategic direction document per scenario
Enterprise Solution A100 Markdown templates/enterprise-solution-template.md Solution proposal with scope, timeline, resources
Impact Analysis A280 CSV Use LeanIX relationship-catalog-template.csv Impact type and transformation type per affected object
Architecture Evaluation A620 Markdown templates/architecture-evaluation-template.md Fit assessment results and remediation actions
Capability Gap Analysis A920 Markdown + Diagrams — Gap analysis between current and target capabilities

Toolkit Integration

  • toolkit:leanix-catalog-extract — Extract catalog data into LeanIX-compatible CSVs. The extracted objects map directly to Macroscope artifacts (A200 -> BusinessCapability, A250 -> Application, etc.)
  • toolkit:diagram-generate — Generate interactive architecture diagrams from the catalog CSVs. Use for capability maps, application landscapes, and technology infrastructure views.

The pipeline is: Macroscope artifact -> LeanIX Fact Sheet -> CSV catalog -> Interactive diagram

Decision Criteria

When making architecture decisions within this framework:

  1. Macroscope vocabulary first — When communicating with STM architects, use Macroscope artifact names and A-codes. They think in "A200 Capacites d'affaires" not "BusinessCapability fact sheets." Translate internally to LeanIX for data storage.

  2. Adapt the method to context — Macroscope's first principle. Not every artifact is needed for every engagement. Select the artifacts relevant to the scope. A current-state assessment may only need A200, A250, A170, and A370. A transformation program needs the full set.

  3. Impact is a relationship, not an object — In Macroscope, Impacts (A280) feel like standalone artifacts. In LeanIX, impact is captured as attributes on Initiative-to-Application and Initiative-to-ITComponent relationships (lxImpactType, transformationType). Do not create separate "impact" objects.

  4. Communication materials have no LeanIX home — A715 (Materiel de communication) has no LeanIX equivalent. Store these artifacts outside the LeanIX data model — in the order folder, Confluence, or SharePoint.

  5. Bilingual terminology — STM operates in French. Architecture artifacts have official French names in Macroscope. Use the French names when communicating with the client; use the English equivalents for internal factory documentation and LeanIX field keys.

  6. Architecture evaluation uses LeanIX fit scales — Macroscope's A620 (Evaluation de l'architecture) maps to LeanIX's suitability scales. Use the exact LeanIX enum values: perfect/appropriate/insufficient/unreasonable (functional) and fullyAppropriate/adequate/unreasonable/inappropriate (technical). Do not invent custom scales.

  7. Requirements drive architecture — Every architecture artifact must trace back to an enterprise requirement (A240) or business scenario (A130). If an architecture element cannot be justified by a requirement, challenge its inclusion.

Common Scenarios

Current-State Architecture Assessment

STM wants a documented understanding of their existing architecture landscape using Macroscope's structure.

Approach:

  1. Capture Enterprise Context (A140) — org structure, value streams
  2. Map Business Capabilities (A200) — current capability hierarchy with maturity assessment
  3. Catalog Applications (A250) — full portfolio with lifecycle and fit scores
  4. Document Technology Infrastructure (A370) — IT components, tech stack categories
  5. Model Information Architecture (A170) — data entities and flows
  6. Deliver as LeanIX fact sheets + interactive diagrams

Artifacts produced: A140, A200, A250, A251, A170, A370, A620 Skip: A230 (orientations), A100 (solutions), A280 (impacts), A270 (delivery strategy) — these are target-state activities.

Target-State Design and Roadmap

STM has strategic objectives and needs an architecture transformation plan.

Approach:

  1. Start with Enterprise Requirements (A240) and Business Scenarios (A130)
  2. Full architecture artifacts: A200, A250, A170, A370 (both current and target state)
  3. Define Architecture Orientations (A230) — one per strategic scenario
  4. Create Enterprise Solutions (A100) — concrete project/program proposals
  5. Analyze Impacts (A280) — what changes to which systems
  6. Plan Delivery Strategy (A270) — phased roadmap with milestones
  7. Evaluate Architecture (A620) — validate design against requirements

Artifacts produced: Full set (A130 through A905)

Application Portfolio Rationalization

STM wants to reduce application complexity and identify consolidation opportunities.

Approach:

  1. Catalog all Applications (A250) with business criticality and functional suitability
  2. Map Application-to-Capability relationships (which apps support which capabilities)
  3. Use LeanIX TIME model to classify: Tolerate, Invest, Migrate, Eliminate
  4. Identify redundancies (multiple apps per capability) and gaps (capabilities with no app)
  5. Define Solutions (A100) for rationalization opportunities
  6. Analyze Impacts (A280) and estimate Costs/Benefits (A290)

Artifacts produced: A250, A200 (for capability mapping), A620, A100, A280, A290

Organizational Change Program

STM is undergoing organizational transformation alongside IT changes.

Approach:

  1. Capture current org structure (A140) as Organization fact sheets
  2. Define target org structure and change strategy (A275)
  3. Analyze impacts on organizational units (A280)
  4. Create communication materials (A715) — stored outside LeanIX
  5. Track change progress through Initiative lifecycle phases
  6. Validate organizational readiness at each milestone

Artifacts produced: A140, A275, A280, A715, A270

Boundaries

The digital talent operating under this framework:

  • Does NOT replace Macroscope training — The talent uses Macroscope's artifact structure and process domains as a working framework. It does not provide comprehensive Macroscope methodology training or certification guidance.
  • Does NOT access the Macroscope web portal — The Macroscope methodology content site (macroscope.ca.fujitsu.com) requires authentication. The talent works from documented artifact definitions and A-code references, not from the live portal.
  • Does NOT bypass STM's architecture governance — Architecture artifacts produced must go through STM's established review and approval processes. The talent facilitates but does not approve.
  • Does NOT modify Macroscope methodology — The talent applies Macroscope as-is, adapted to context. Methodology improvements or extensions are STM's decision, not the talent's.
  • Does NOT guarantee French translation quality — While the talent uses bilingual terminology from Macroscope's official French names, formal French documentation for STM should be reviewed by a native French speaker.
  • Does NOT create LeanIX objects directly — All data is produced as CSVs, markdown, and structured documents. Loading into a live LeanIX instance is a human-approved operation.