# SAP LeanIX in Practice: The Architect's Guide — Inventory, Diagrams, and Reports

A practical, opinionated tutorial on using SAP LeanIX as a transformation accelerator in the architect's daily work — covering inventory (Fact Sheets, meta model, quality), diagrams (types, when to use, live vs static), and reports (question → data → decision). Uses Hohpe's Architecture Elevator as the connecting thread and a fictional insurer/bank scenario to make every concept concrete.

- URL: https://fernando.moretes.com/studies/sap-leanix-na-pratica-guia-do-arquiteto

- Markdown: https://fernando.moretes.com/studies/sap-leanix-na-pratica-guia-do-arquiteto/study.md?lang=en

- Type: Tutorial / Course

- Domain: Arquitetura Empresarial

- Date: 2026-07-17

- Tags: enterprise-architecture, leanix, transformation, portfolio-management, diagrams, reports, togaf, architecture-elevator

- Reading time: 13 min

---

Every senior architect has lived the scene: you have a pristine Visio diagram on your laptop, the CTO wants to know which systems are affected by the new regulation, and the IT manager swears application X was decommissioned last year — but it is still processing payments. The problem is not lack of documentation; it is lack of a living, trustworthy, navigable corporate map. That is exactly where SAP LeanIX fits — not as yet another drawing tool, but as the central repository of architectural truth connecting the business floor to the technical floor. This tutorial teaches how to use LeanIX with purpose: model the right inventory, pick the right diagram, read the right report — and turn all of it into real decisions.

## What You Will Learn

- What SAP LeanIX is and why it is a transformation accelerator, not a drawing tool
- How to structure the inventory: Fact Sheets, meta model, relations, hierarchies, completion score, and quality seal
- How deep to model — and what to deliberately leave out of LeanIX (where C4 and arc42 live)
- LeanIX diagram types, when to use each, and the difference between a live diagram and a static drawing
- How to read reports to answer real questions: portfolio, capability × application, functional/technical fit, lifecycle distribution, and roadmap
- LeanIX's three modules (APM, TRC, ARP) and how they complement each other in a transformation cycle

## The Architecture Elevator and the Living Corporate Map

Gregor Hohpe describes in *The Software Architect Elevator* the architect who must move between the penthouse — where business speaks in strategy, capabilities, and outcomes — and the engine room — where engineers speak in services, pipelines, and latency. The classic problem is that these two floors use different vocabularies and rarely meet. The architect is the elevator that translates one to the other.

LeanIX is the map that makes that journey possible without improvising every time. When the business asks 'which systems support Credit Origination?', the answer should not depend on you remembering off the top of your head or digging through spreadsheets. It should be on the map. When regulation requires knowing which technology components process customer data and what their lifecycle status is, that answer should also be on the map.

The accelerator thesis is simple: LeanIX does not eliminate architecture work — it eliminates *reconstitution* work. Without it, you spend 40% of your time discovering the current state before you can reason about the future. With it, you start from the living inventory and go straight to analysis. Ross, Weill, and Robertson in *Enterprise Architecture as Strategy* are explicit: capability-based transformation requires visibility into which applications deliver which capabilities — and that visibility must be maintained, not rebuilt for every project.

## SAP LeanIX — Modules, Glossary, and Scenario

- **APM Module:** Application Portfolio Management — application inventory, functional/technical assessment, portfolio rationalization
- **TRC Module:** Technology Risk & Compliance — IT components, lifecycle, obsolescence, technology standards, compliance
- **ARP Module:** Architecture & Road Map Planning — current and target architecture, initiatives, roadmaps, architecture decisions
- **Fact Sheet:** Atomic unit of the LeanIX inventory — a structured record for each entity (application, capability, component, etc.)
- **Meta Model:** Set of Fact Sheet types and allowed relations between them — configurable per tenant
- **Completion Score:** Percentage of mandatory fields filled in a Fact Sheet — indicator of inventory maturity
- **Quality Seal:** Manual approval by an owner that the Fact Sheet is correct and up to date — goes beyond completion score
- **Fictional scenario:** FinSecure (mid-size insurer/bank): 3 capabilities (Credit Origination, Payments, Customer Service), 5 apps (CreditCore, LoanLegacy, PayHub, PayLite, CRM360), 5 components (Oracle DB 19c, Java 11 LTS, Node 18, Redis 7,
- **SAP AI Agent Hub:** New layer on LeanIX to govern AI agents and LLMs — 2 of 6 capabilities GA; 4 planned Q3 2026. LeanIX MCP server already GA. (Not the focus of this tutorial.)

## Inventory: Fact Sheets, Meta Model, and How Deep to Model

The inventory is the foundation of everything. A Fact Sheet is the structured record of an architectural entity — an application, a business capability, a technology component, an interface, a data object, a vendor. Each type has its own fields (name, description, owner, lifecycle, tags) and can relate to other types. The difference between a **relation** and a **hierarchy** is subtle but critical: a hierarchy models composition (CreditCore *contains* the scoring module), while a relation models dependency or support (CreditCore *supports* the Credit Origination capability). Confusing the two produces a graph that is impossible to navigate.

In the FinSecure scenario, LeanIX's default meta model covers what is needed: Business Capability → Application → IT Component → Interface → Data Object. But the meta model is configurable — and the first governance decision is: adapt the minimum necessary. Every custom type you add is a type your team must maintain. TOGAF 10 calls this the *Architecture Repository*: you need enough depth to make decisions, not an exhaustive inventory.

The practical rule I use: model in LeanIX everything that needs to appear in a portfolio report or a landscape diagram. Leave out of LeanIX everything that is implementation detail — call sequences, API contracts, internal data models. Those live in C4 (Simon Brown) and arc42, which operate at the component and module level. LeanIX is the road map; C4 is the building's floor plan. Mixing both levels in the same repository is the fastest path to an inventory nobody trusts.

## Diagram 1 — Inventory Map: Capability → Application → Technology

Meta model view applied to the FinSecure scenario. Shows functional redundancy (CreditCore + LoanLegacy supporting the same capability) and the JBoss 4.2 component at End-of-Life. Each zone represents a Fact Sheet type.

### 🏢 Business Capabilities

- Originação de Crédito Credit Origination (external)
- Pagamentos Payments (external)
- Atendimento Customer Service (external)

### 📦 Applications

- CreditCore (active) (compute)
- LoanLegacy (redundant ⚠️) (compute)
- PayHub (active) (compute)
- PayLite (redundant ⚠️) (compute)
- CRM360 (active) (frontend)

### ⚙️ IT Components

- Oracle DB 19c (active) (data)
- Java 11 LTS (active) (compute)
- Node 18 (active) (compute)
- Redis 7 (active) (storage)
- JBoss 4.2 (🔴 End-of-Life) (security)

### Flows

- cap1 -> app1: supported by
- cap1 -> app2: supported by (redundant)
- cap2 -> app3: supported by
- cap2 -> app4: supported by (redundant)
- cap3 -> app5: supported by
- app1 -> tc1: uses
- app1 -> tc2: uses
- app2 -> tc5: uses (EoL!)
- app3 -> tc3: uses
- app3 -> tc4: uses
- app4 -> tc5: uses (EoL!)
- app5 -> tc1: uses

## LeanIX Diagram Types — When to Use Each
| Criterion | Type | What it represents | When to use | Live or static? | Scenario example |
| --- | --- | --- | --- | --- | --- |
| Application Landscape | Applications organized by business capability or organization | Executive portfolio view; identify redundancies; communicate transformation scope | Live — updates when Fact Sheets change | Show CreditCore + LoanLegacy both under Credit Origination | — |
| Business Capability Map | Business capability hierarchy with coverage or risk heat map | Align IT to business; prioritize investment; identify gaps and overlaps | Live — colored by Fact Sheet data (e.g., functional fit) | Functional fit heat map of FinSecure's 3 capabilities | — |
| Data Flow | Data flow between applications via interfaces, with labeled data objects | Analyze integrations; plan data migration; assess regulatory impact (LGPD/PCI) | Live — interfaces and relations come from Fact Sheets | Credit data flow between CreditCore, LoanLegacy, and Oracle DB | — |
| Roadmap / Target Architecture | Initiative timeline with As-Is, transition, and To-Be states per application | Plan and communicate transformation; sequence initiatives; show intermediate states | Live — based on initiatives and Fact Sheet lifecycles (ARP module) | Roadmap of 'Digital Platform 2026' initiative: decommission LoanLegacy and PayLite | — |
| Free Draw | Free canvas, can reference Fact Sheets as nodes or be entirely manual | Initial exploration; workshops; conceptual diagrams that do not yet have Fact Sheets | Static (or hybrid if nodes linked) — does not update automatically | Target architecture sketch before creating formal Fact Sheets | — |

## Live vs Static Diagrams: The Distinction That Matters

The most important distinction an architect needs to internalize about LeanIX diagrams is: **a live diagram is not a drawing — it is a query with a visual shape**. When you create an Application Landscape and drag CreditCore into the 'Credit Origination' cell, you are not drawing a box; you are declaring a relation in the inventory. If tomorrow someone updates CreditCore's Fact Sheet and changes its lifecycle to 'End of Life', the diagram reflects that automatically. This is what makes LeanIX different from PowerPoint, Visio, or Lucidchart for portfolio purposes.

Free Draw exists for the moments when you are still exploring — a discovery workshop, a target architecture sketch that does not yet have formal Fact Sheets. Use it consciously and with a deadline: if a Free Draw survives more than two weeks without becoming Fact Sheets, it becomes noise in the repository.

The three temporal views — **As-Is**, **transition**, and **To-Be** — are the heart of the ARP module and TOGAF 10. TOGAF calls these *Architecture States*: current, transition, target. In LeanIX, you model this by associating applications with initiatives with start and end dates, and the system automatically generates the view for any point in time. For FinSecure, this means: today (As-Is) we have CreditCore and LoanLegacy running in parallel; in March 2026 (transition) LoanLegacy enters decommissioning; in December 2026 (To-Be) only CreditCore exists. This temporal storytelling is what turns an inventory into a transformation argument.

## Diagram 2 — Data Flow: As-Is × To-Be (Credit Origination)

Comparison of the credit data flow before and after the 'Digital Platform 2026' initiative. As-Is: two redundant systems (CreditCore + LoanLegacy) write to the same Oracle DB via separate interfaces. To-Be: LoanLegacy decommissioned, flow consolidated in CreditCore with API Gateway.

### 📸 As-Is (hoje / today)

- Canal Digital Digital Channel (frontend)
- CreditCore (ativo / active) (compute)
- LoanLegacy (⚠️ redundante) (compute)
- Oracle DB 19c (dados de crédito) (data)
- JBoss 4.2 (🔴 EoL) (security)

### 🎯 To-Be (Dez 2026 / Dec 2026)

- API Gateway (novo / new) (edge)
- CreditCore (consolidado) (compute)
- Oracle DB 19c (dados de crédito) (data)
- Redis 7 (cache/eventos) (storage)

### Flows

- asis_gw -> asis_cc: IF-001: REST
- asis_gw -> asis_ll: IF-002: SOAP (legacy)
- asis_cc -> asis_db: IF-003: JDBC
- asis_ll -> asis_jb: EoL runtime
- asis_ll -> asis_db: IF-004: JDBC (duplicate)
- tobe_gw -> tobe_cc: IF-001: REST (consolidated)
- tobe_cc -> tobe_db: IF-003: JDBC
- tobe_cc -> tobe_q: cache / events

## Reports: From Question to Decision

A report without an associated decision is decoration. That is the rule I apply in every portfolio review. LeanIX offers configurable reports, and the discipline is always to start from three questions: *what decision do I need to make?* → *what data do I need for that?* → *which report exposes that data?*

**Portfolio Report (APM):** Question — 'Which applications are active, at what lifecycle phase, and with what functional/technical fit?' Required data — lifecycle, functional fit, and technical fit filled in application Fact Sheets. Decision enabled — prioritize which applications to invest in, maintain, or decommission. In FinSecure, this report immediately reveals that LoanLegacy has 'inadequate' functional fit and 'inadequate' technical fit (JBoss EoL), justifying decommissioning.

**Capability × Application Matrix:** Question — 'Which business capabilities are covered by which applications, and is there redundancy or a gap?' Required data — relations between Business Capability and Application Fact Sheets. Decision enabled — portfolio consolidation and budget allocation per capability. Here the CreditCore/LoanLegacy and PayHub/PayLite redundancy becomes visually obvious.

**Technology Lifecycle Distribution (TRC):** Question — 'Which technology components are at End-of-Life or End-of-Support, and which applications depend on them?' Required data — lifecycle of IT Component Fact Sheets and relations to Application Fact Sheets. Decision enabled — technology upgrade plan and risk management. JBoss 4.2 EoL affecting LoanLegacy and PayLite is the trigger for the modernization initiative.

**Initiative Roadmap (ARP):** Question — 'What is the sequence of planned changes, and what is the portfolio state at each milestone?' Required data — initiatives with dates, associated applications, and states (active/plan/end of life). Decision enabled — investment sequencing, board communication, and dependency management between projects.

## Hands-on: Building the FinSecure Inventory and Artifacts

1. **Step 1 — Review and adapt the meta model** — Go to Settings → Meta Model. Confirm that the default types (Business Capability, Application, IT Component, Interface, Data Object, Provider) cover the scenario. For FinSecure, do not add custom types at this stage — the default is sufficient. Define which fields are mandatory for the completion score: at minimum name, owner, lifecycle, and functional fit for Applications; name, owner, and lifecycle for IT Components.

2. **Step 2 — Create Capability Fact Sheets** — Create 3 Business Capability Fact Sheets: 'Credit Origination', 'Payments', 'Customer Service'. Define the hierarchy if needed (e.g., Payments > Domestic Payments, International Payments). Assign business owners — not IT owners. Capabilities are stable; do not update them with every system change. They represent the business 'what', independent of the technological 'how'.

3. **Step 3 — Create Application Fact Sheets** — Create 5 Application Fact Sheets: CreditCore, LoanLegacy, PayHub, PayLite, CRM360. For each, fill in: lifecycle (active/plan/end of life), functional fit (adequate/insufficient/inadequate), technical fit (adequate/insufficient/inadequate), owner (responsible team), and provider (vendor). LoanLegacy and PayLite get functional fit = 'inadequate' and technical fit = 'inadequate'. Relate each application to the capabilities it supports using the 'Add Relation → Business Capability' button.

4. **Step 4 — Create IT Components and relations** — Create 5 IT Component Fact Sheets: Oracle DB 19c, Java 11 LTS, Node 18, Redis 7, JBoss 4.2. For JBoss 4.2, set lifecycle = 'End of Life' and fill in the EoL date. Relate each component to the applications that use it via 'Add Relation → Application'. This step is what enables the TRC lifecycle distribution report — without the relations, the report is blind.

5. **Step 5 — Create Interfaces and Data Objects** — Create 4 Interface Fact Sheets (IF-001 to IF-004) with protocol type, frequency, and owner. Create 3 Data Object Fact Sheets: 'Credit Proposal', 'Payment Data', 'Customer Profile'. Relate interfaces to source and target applications, and to the data objects they carry. These Fact Sheets feed the Data Flow diagram and regulatory impact reports.

6. **Step 6 — Assess the portfolio and verify quality** — Access the Portfolio Report (APM) and check the completion score of each Fact Sheet. Fact Sheets below 70% need attention before any report is trustworthy. Use the Quality Seal to mark Fact Sheets reviewed and approved by the owner — the seal goes beyond the completion score: it indicates that a human has validated the content. Configure subscriptions so owners receive alerts when their Fact Sheets are modified.

7. **Step 7 — Create live diagrams** — Create an Application Landscape diagram grouping by Business Capability — the CreditCore/LoanLegacy redundancy appears immediately. Create a Business Capability Map with functional fit heat map — Credit Origination will be red because of LoanLegacy. Create a Data Flow diagram for the Credit Origination flow. All these diagrams are live: any change in Fact Sheets is reflected automatically.

8. **Step 8 — Model the initiative and roadmap** — In the ARP module, create the initiative 'Digital Platform 2026' with start date (Jan 2026) and end date (Dec 2026). Associate LoanLegacy and PayLite with the initiative with state 'end of life' from Dec 2026. Associate the API Gateway as a new application with state 'plan' from Mar 2026. The Roadmap diagram now automatically shows the three temporal states: As-Is, transition (Mar-Nov 2026), and To-Be (Dec 2026). Use this diagram to communicate to the board — not to the engineering team.

## Diagram 3 — Transformation Roadmap: Digital Platform 2026

Timeline of the 'Digital Platform 2026' initiative showing the three architectural states (As-Is, Transition, To-Be) for FinSecure applications. Based on the LeanIX ARP module.

### 📸 As-Is (Jan 2026)

- CreditCore active (compute)
- LoanLegacy active ⚠️ (compute)
- PayHub active (compute)
- PayLite active ⚠️ (compute)
- CRM360 active (frontend)

### 🔄 Transição (Mar–Nov 2026)

- CreditCore active (consolidating) (compute)
- LoanLegacy 🟡 phase-out (compute)
- PayHub active (consolidating) (compute)
- PayLite 🟡 phase-out (compute)
- API Gateway 🟢 plan→active (edge)

### 🎯 To-Be (Dez 2026 / Dec 2026)

- CreditCore active ✅ (compute)
- PayHub active ✅ (compute)
- CRM360 active ✅ (frontend)
- API Gateway active ✅ (edge)

### Flows

- r_ll_asis -> r_ll_tr: starts phase-out Mar/26
- r_pl_asis -> r_pl_tr: starts phase-out Mar/26
- r_cc_tr -> r_cc_tobe: consolidated Dec/26
- r_ph_tr -> r_ph_tobe: consolidated Dec/26
- r_apigw_tr -> r_apigw_tobe: active Dec/26
- r_ll_tr -> r_cc_tobe: migrated to
- r_pl_tr -> r_ph_tobe: migrated to

> **Best-Practice Precepts — Rules of Thumb:** **1. LeanIX is the map, not the territory.** It represents the portfolio; technical documentation lives in C4 and arc42. Never try to put sequence diagrams or API contracts in LeanIX.

**2. Start with the owner, not the data.** A Fact Sheet without an owner is a Fact Sheet without accountability — and without accountability, it rots. Define owners before publishing any Fact Sheet.

**3. Quality Seal > completion score.** A 100% filled Fact Sheet with wrong data is worse than a 70% one with correct data. The seal is the human signature that content has been validated.

**4. Adapt the meta model sparingly.** Every custom type is governance debt. If the default type serves with 80% fidelity, use the default.

**5. Model the To-Be before finishing the As-Is.** If you wait for the inventory to be perfect before starting to plan, you will never start. LeanIX supports partial states — use that.

**6. Link technology to business capabilities.** If JBoss 4.2 EoL is not related to a business capability, the risk is invisible to the board. The IT Component → Application → Business Capability chain is what turns technical risk into a business argument.

**7. Every report needs an associated decision.** Before creating a report, write the question it answers and the decision it enables. If you cannot, do not create the report.

> **Anti-Patterns That Destroy LeanIX's Value:** **❌ Treating LeanIX as a CMDB.** LeanIX is an architecture repository, not a configuration one. Do not try to register server instances, IPs, patch versions, or incident tickets. That belongs in the CMDB/ITSM.

**❌ Using LeanIX only as a drawing tool.** If you use LeanIX to make things look pretty and not to maintain a living inventory, you have an expensive Visio. The value is in the Fact Sheets, not the pixels.

**❌ Confusing Application with IT Component.** An application is a software system with a business purpose (CreditCore). An IT Component is an infrastructure or platform technology (Java 11, JBoss). Mixing the two breaks all lifecycle reports.

**❌ Overly detailed Fact Sheets.** If you are modeling fields that never appear in any report or diagram, you are wasting governance time. Less is more.

**❌ Copying the meta model without adapting.** The default meta model is a starting point, not a universal truth. But over-adapting is equally bad — every customization has a maintenance cost.

**❌ Ignoring owners and quality.** An inventory without owners is an inventory without a future. In six months, nobody knows who is responsible for anything.

**❌ Only modeling the As-Is.** A map of the current state without a target vision is a historical archive, not a transformation tool. TOGAF 10 is explicit: the architecture cycle requires current, transition, and target states.

**❌ Showing a report without an associated decision.** Reports without decisions become slideware. Always tie the report to the question and the decision before presenting.

> **My Senior Take: What Separates Good Use from Bad Use:** After more than 16 years in architecture — including financial-grade systems where portfolio visibility is not optional, it is regulatory — I have learned that tools like LeanIX fail for human reasons, not technical ones.

The biggest mistake I see is the architect who spends weeks building an impeccable inventory and then uses it to make pretty presentations for the IT committee. LeanIX is not for the IT committee — it is for the architect who needs to answer hard questions in real time. 'How many applications depend on JBoss 4.2 going EoL in March?' You should be able to answer that in 30 seconds, not two days.

The second mistake is thinking LeanIX replaces architectural thinking. It does not. It accelerates it. The difference between an architect who uses LeanIX as an accelerator and one who uses it as a passive repository is that the first starts from the inventory to reason about the future; the second updates the inventory after decisions have already been made — and then it is just retroactive documentation.

Hohpe's Architecture Elevator metaphor is precise here: LeanIX is the elevator panel. It shows which floor you are on, which floors exist, and which button to press. But who decides where to go — and why — is the architect. The tool does not make decisions; it makes decisions defensible with data.

Finally: invest in SAP Learning for formal training (the old Academy was shut down in February 2026 and migrated there). And keep an eye on the SAP AI Agent Hub — the ability to govern AI agents and MCP servers in the same repository where you already govern applications and components is, genuinely, a paradigm shift for the next two years.

## Verdict

SAP LeanIX is, today, the most mature tool available for the architect who needs to maintain a living corporate map and use it as a transformation accelerator. Its three modules (APM, TRC, ARP) cover the full cycle: inventory, assess technology risk, and plan the future. Live diagrams — linked to Fact Sheets — eliminate the classic problem of documentation that becomes stale within weeks. Reports, when used with discipline (question → data → decision), turn the inventory into a business argument.

But LeanIX is not magic. It is only as good as the quality of the inventory you maintain — and inventory quality depends on committed owners, a well-calibrated meta model, and a culture where updating the Fact Sheet is part of the change process, not an optional post-project task.

What LeanIX does not do: it does not replace C4 for component diagrams, does not replace arc42 for software decision documentation, and does not replace the architect's thinking. It is Hohpe's elevator panel — not the architect pressing the buttons.

For those starting out: build the minimum viable inventory (capabilities + applications + critical components), wire the relations, configure the owners, and use the Portfolio Report and Capability Matrix before anything else. That alone justifies the tool investment. The rest comes with maturity.

## References

- [SAP Help Portal — SAP LeanIX](https://help.sap.com/docs/leanix)
- [SAP Learning — SAP LeanIX (substituto da LeanIX Academy, desligada em 28/02/2026)](https://learning.sap.com/courses/sap-leanix)
- [SAP LeanIX — Architecture and Road Map Planning (ARP)](https://help.sap.com/docs/leanix/ea/sap-leanix-architecture-and-road-map-planning)
- [SAP — AI Agent Hub](https://www.sap.com/products/artificial-intelligence/ai-agent-hub.html)
- [SAP LeanIX — MCP Server for SAP LeanIX Solutions](https://www.leanix.net/en/blog/mcp-server-for-sap-leanix-solutions)
- [Hohpe, Gregor — The Software Architect Elevator (O'Reilly, 2020)](https://architectelevator.com/book/)
- [Ross, Jeanne W.; Weill, Peter; Robertson, David C. — Enterprise Architecture as Strategy (Harvard Business Review Press,](https://www.hbs.edu/faculty/Pages/item.aspx?num=22491)
- [Brown, Simon — The C4 Model for Software Architecture](https://c4model.com/)

## Case sources

- [SAP Help Portal — SAP LeanIX](https://help.sap.com/docs/leanix)
- [SAP Learning — SAP LeanIX](https://learning.sap.com/courses/sap-leanix)
- [SAP LeanIX — Architecture and Road Map Planning](https://help.sap.com/docs/leanix/ea/sap-leanix-architecture-and-road-map-planning)
- [SAP — AI Agent Hub](https://www.sap.com/products/artificial-intelligence/ai-agent-hub.html)
- [SAP LeanIX — MCP server para soluções LeanIX](https://www.leanix.net/en/blog/mcp-server-for-sap-leanix-solutions)
- [Gregor Hohpe — The Software Architect Elevator](https://architectelevator.com/book/)
- [Ross, Weill & Robertson — Enterprise Architecture as Strategy](https://www.hbs.edu/faculty/Pages/item.aspx?num=22491)
- [Simon Brown — The C4 model for software architecture](https://c4model.com/)
- [The Open Group — TOGAF Standard, 10th Edition](https://www.opengroup.org/togaf)
- [arc42 — Documentação de arquitetura de software](https://arc42.org/)