Agent Instructions: LeanIX

For use by digital talents deployed with the LeanIX framework Based on: framework-guide-template.md

How to Apply This Framework

LeanIX uses a catalog-driven approach: start by inventorying what exists, then relate objects to each other, then analyze the resulting landscape. This is the opposite of top-down architecture — you build understanding from concrete data upward.

Step 1 — Extract/Create Object Catalog

Inventory all IT objects from available sources. Use toolkit:leanix-catalog-extract to automate extraction from code repositories, documents, or interviews.

Sources to mine:

Existing CMDB exports, asset inventories, or spreadsheets
Code repositories (scan for applications, services, technology dependencies)
Architecture documents, wiki pages, or Confluence spaces
Stakeholder interviews (for business context, ownership, criticality assessments)
Contract and license databases (for vendor and cost information)

For each application, capture at minimum:

Name and description
Lifecycle status (Plan, Phase In, Active, Phase Out, End of Life)
Business criticality (Mission Critical, Business Operational, Business Critical, Administrative Service)
Technical fit (Fully Adequate, Adequate, Insufficient, Unreasonable)
Host platform and deployment model
Business owner and technical owner
Department/organizational unit

For each IT component, capture at minimum:

Name, version, and vendor
Technology category (Database, Middleware, Framework, Operating System, etc.)
Lifecycle status and end-of-support date
Applications that depend on it

Output: Application catalog CSV and Technology catalog CSV using the templates in templates/.

Step 2 — Define Relationships Between Objects

Once objects are cataloged, map how they connect:

Application-to-Application: Which applications integrate with each other? What data flows between them? What interfaces exist?
Application-to-IT Component: What technologies does each application use? (Database, middleware, framework, hosting platform)
Application-to-Business Capability: Which business functions does each application support?
Application-to-User Group: Who uses each application?
IT Component-to-Provider: Who supplies each technology?

Output: Relationship catalog CSV using the template in templates/.

Step 3 — Analyze Portfolio

With the catalog and relationships in place, perform structured analysis:

Application Portfolio Analysis (TIME Model):

Plot applications on the Business Criticality vs. Technical Fit matrix
Classify into quadrants: Tolerate, Invest, Migrate, Eliminate
Identify applications with high business criticality but low technical fit (urgent migration candidates)
Identify applications with low criticality and low fit (elimination candidates)

Technology Lifecycle Analysis:

Identify all IT components at Phase Out or End of Life status
Map which applications depend on end-of-life technologies (risk exposure)
Flag technology monocultures (single vendor/product dependency)

Business Capability Coverage:

Map which capabilities are supported by multiple overlapping applications (redundancy)
Map which capabilities have no application support (gaps)
Identify capabilities supported only by end-of-life or low-fit applications (risk)

Step 4 — Identify Rationalization Opportunities

Based on the analysis, identify actionable opportunities:

Consolidation: Multiple applications serving the same business capability that could be merged
Retirement: Applications with no active users, no business criticality, or superseded by other systems
Migration: Applications on end-of-life technology that need re-platforming
Investment: Mission-critical applications with inadequate technical fit that need modernization
Standardization: Technology components that could be consolidated to reduce vendor sprawl

For each opportunity, document: the affected objects, the recommended action, the expected benefit, the estimated effort (relative sizing), and any dependencies or risks.

Step 5 — Create Transformation Roadmaps

Sequence the identified opportunities into a phased roadmap:

Quick wins — Low-effort retirements and consolidations with immediate cost savings
Risk reduction — Migrate applications off end-of-life technologies
Strategic investments — Modernize mission-critical applications
Long-term transformation — Platform migrations, cloud adoption, major re-architecture

Use toolkit:diagram-generate to create visual roadmaps and architecture diagrams from the catalog CSVs.

Deliverables

Deliverable	Format	Template	Description
Application Catalog	CSV	`templates/application-catalog-template.csv`	Complete inventory of applications with lifecycle and assessment data
Technology Catalog	CSV	(embedded in application catalog as IT Components)	Inventory of technology components with lifecycle status
Initiative Catalog	CSV	`templates/initiative-catalog-schema.csv`	Programs and projects (A100/A230 deliverables) with status, effort, and program hierarchy
Objective Catalog	CSV	`templates/objective-catalog-schema.csv`	Strategic objectives and PSO hierarchy (A240 deliverable) — maps Orientation → Objectif → Stratégie → Chantier
Relationship Catalog	CSV	`templates/relationship-catalog-template.csv`	All relationships between cataloged objects
Fact Sheet Reports	Markdown	`templates/fact-sheet-template.md`	Detailed documentation for individual applications or technologies
Portfolio Analysis	Markdown + Diagrams	—	TIME model analysis, technology risk assessment, capability mapping
Rationalization Recommendations	Markdown	—	Prioritized list of opportunities with effort estimates
Transformation Roadmap	Markdown + Diagrams	—	Phased plan for executing rationalization
Architecture Diagrams	HTML (interactive)	Generated via `toolkit:diagram-generate`	Visual landscape diagrams generated from catalog CSVs

Toolkit Integration

toolkit:leanix-catalog-extract — Use this to extract catalog data from code repositories, documents, or interviews into standardized Object and Relationship CSVs. This is the primary data capture tool.
toolkit:diagram-generate — Use this to generate interactive architecture diagrams (HTML) from the catalog CSVs. Supports landscape views, data flow diagrams, and integration maps.

The pipeline is: Extract (catalog-extract) → Analyze (manual/guided) → Visualize (diagram-generate).

Decision Criteria

When making assessments and recommendations within this framework, apply these principles:

Data Quality Drives Confidence

Recommendations are only as good as the data behind them. Always flag data quality issues.
If a Fact Sheet is missing key fields (owner, lifecycle status, business criticality), do not make definitive recommendations about it — flag it for data enrichment first.
When confidence is low, present findings as hypotheses to validate rather than conclusions.

Business Criticality Drives Priority

Mission-critical applications always get analyzed first and get the most thorough assessment.
Never recommend retiring or eliminating a mission-critical application without extensive justification.
When two opportunities compete for attention, prioritize the one affecting higher-criticality applications.

Lifecycle Status Drives Urgency

End-of-Life technologies create security and support risk — these drive urgent action.
Phase Out technologies are scheduled but not yet urgent — plan proactively.
Active technologies with no end-of-support concerns are lowest priority for change.

Cost of Change vs. Cost of Inaction

For each recommendation, consider both the cost of making the change and the risk/cost of doing nothing.
Small, frequent improvements (evolutionary) are generally preferred over large, risky transformations (revolutionary).

Common Scenarios

Application Portfolio Rationalization

The most common scenario. The organization has accumulated applications over years of organic growth, acquisitions, and tactical decisions. They need to understand what they have, identify redundancies, and plan consolidation.

Approach: Full catalog extraction → portfolio analysis (TIME model) → identify consolidation and retirement candidates → build phased rationalization roadmap.

Technology Lifecycle Management

The organization needs to track which technologies are approaching end-of-life and plan migrations before support lapses create security risks.

Approach: Technology catalog with lifecycle dates → identify end-of-life components → map application dependencies → plan migration waves.

Cloud Migration Assessment

The organization wants to move workloads to the cloud and needs to assess which applications are cloud-ready, which need re-architecture, and which should stay on-premises.

Approach: Application catalog with hosting and architecture details → assess cloud readiness (6R model: Rehost, Replatform, Repurchase, Refactor, Retire, Retain) → group into migration waves → build migration roadmap.

M&A Integration

Two organizations are merging and need to rationalize their combined IT landscapes. Both sides need to be cataloged, overlaps identified, and a consolidated target architecture defined.

Approach: Catalog both landscapes independently → merge catalogs → identify overlapping capabilities and redundant applications → define target architecture → plan integration roadmap.

CMDB Population

The organization needs to build or enrich a Configuration Management Database. LeanIX catalog methodology provides a structured approach to gathering the data.

Approach: Extract catalog data from all available sources → validate and enrich with stakeholders → export in CMDB-compatible format → load into CMDB tool.

Boundaries

The digital talent operating within this framework must observe these boundaries:

Does NOT make retirement or investment decisions. The talent provides analysis and recommendations. Humans make the final call on whether to retire, invest in, migrate, or tolerate an application.
Does NOT directly modify production CMDB. The talent produces CSV exports and recommendations. Loading data into a production CMDB is a human-approved operation.
Does NOT access live LeanIX instances. The talent works with exported data, documents, and code — not with the LeanIX SaaS platform directly. If the client has a LeanIX instance, the talent works with data exported from it.
Does NOT assign business criticality unilaterally. Business criticality is a business judgment. The talent can propose criticality ratings based on available evidence, but these must be validated by business stakeholders.
Does NOT guarantee completeness. A catalog is always a snapshot. The talent flags known gaps and areas of uncertainty rather than presenting incomplete data as complete.
Does NOT prescribe specific vendor products. Rationalization recommendations focus on capabilities needed, not specific products to purchase. Product selection is a separate decision process.