# SAP LeanIX na prática: o guia do arquiteto — inventário, diagramas e reports

Um tutorial prático e opinativo sobre como usar o SAP LeanIX como acelerador de transformação no dia a dia do arquiteto — cobrindo inventário (Fact Sheets, metamodelo, qualidade), diagramas (tipos, quando usar, vivo vs estático) e reports (pergunta → dado → decisão). Usa o 'Architecture Elevator' de Hohpe como fio condutor e um cenário fictício de seguradora/banco para tornar cada conceito concreto.

- 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=pt

- Type: Tutorial / Curso

- Domain: Arquitetura Empresarial

- Date: 2026-07-17

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

- Reading time: 13 min

---

Todo arquiteto sênior já viveu a cena: você tem um diagrama Visio impecável no seu laptop, o CTO quer saber quais sistemas vão ser afetados pela nova regulação, e o gerente de TI jura que a aplicação X foi descomissionada no ano passado — mas ela ainda processa pagamentos. O problema não é falta de documentação; é falta de um mapa corporativo vivo, confiável e navegável. É exatamente aí que o SAP LeanIX entra — não como mais uma ferramenta de desenho, mas como o repositório central de verdade arquitetural que conecta o andar do negócio ao andar técnico. Este tutorial ensina como usar o LeanIX com propósito: modelar o inventário certo, escolher o diagrama certo, ler o report certo — e transformar tudo isso em decisões reais.

## O que você vai aprender

- O que é o SAP LeanIX e por que ele é um acelerador de transformação, não uma ferramenta de desenho
- Como estruturar o inventário: Fact Sheets, metamodelo, relações, hierarquias, completion score e quality seal
- Até que nível modelar — e o que deliberadamente deixar fora do LeanIX (onde C4 e arc42 vivem)
- Os tipos de diagrama do LeanIX, quando usar cada um, e a diferença entre diagrama vivo e desenho estático
- Como ler reports para responder perguntas reais: portfolio, capacidade × aplicação, adequação funcional/técnica, ciclo de vida e roadmap
- Os três módulos do LeanIX (APM, TRC, ARP) e como eles se complementam num ciclo de transformação

## O Architecture Elevator e o mapa corporativo vivo

Gregor Hohpe descreve em *The Software Architect Elevator* o arquiteto que precisa transitar entre o penthouse — onde o negócio fala em estratégia, capacidades e resultados — e o engine room — onde engenheiros falam em serviços, pipelines e latência. O problema clássico é que esses dois andares usam vocabulários diferentes e raramente se veem. O arquiteto é o elevador que traduz um para o outro.

O LeanIX é o mapa que torna essa viagem possível sem improvisar a cada vez. Quando o negócio pergunta 'quais sistemas suportam Originação de Crédito?', a resposta não deveria depender de você lembrar de cabeça ou de vasculhar planilhas. Ela deveria estar no mapa. Quando a regulação exige saber quais componentes tecnológicos processam dados de clientes e qual o ciclo de vida deles, a resposta também deveria estar no mapa.

A tese do acelerador é simples: o LeanIX não elimina o trabalho de arquitetura — ele elimina o trabalho de *reconstituição*. Sem ele, você gasta 40% do tempo descobrindo o estado atual antes de poder raciocinar sobre o futuro. Com ele, você parte do inventário vivo e vai direto para a análise. Ross, Weill e Robertson em *Enterprise Architecture as Strategy* são explícitos: transformação baseada em capacidades requer visibilidade de quais aplicações entregam quais capacidades — e essa visibilidade precisa ser mantida, não reconstruída a cada projeto.

## SAP LeanIX — Módulos, Glossário e Cenário

- **Módulo APM:** Application Portfolio Management — inventário de aplicações, avaliação funcional/técnica, racionalização de portfólio
- **Módulo TRC:** Technology Risk & Compliance — componentes de TI, ciclo de vida, obsolescência, padrões tecnológicos, compliance
- **Módulo ARP:** Architecture & Road Map Planning — arquitetura atual e alvo, iniciativas, roadmaps, decisões de arquitetura
- **Fact Sheet:** Unidade atômica do inventário LeanIX — um registro estruturado para cada entidade (aplicação, capacidade, componente, etc.)
- **Metamodelo:** Conjunto de tipos de Fact Sheet e relações permitidas entre eles — configurável por tenant
- **Completion Score:** Percentual de campos obrigatórios preenchidos num Fact Sheet — indicador de maturidade do inventário
- **Quality Seal:** Aprovação manual por um owner de que o Fact Sheet está correto e atualizado — vai além do completion score
- **Cenário fictício:** FinSecure (seguradora/banco médio): 3 capacidades (Originação de Crédito, Pagamentos, Atendimento), 5 apps (CreditCore, LoanLegacy, PayHub, PayLite, CRM360), 5 componentes (Oracle DB 19c, Java 11 LTS, Node 18, Redis 7,
- **SAP AI Agent Hub:** Frente nova sobre LeanIX para governar agentes de IA e LLMs — 2 de 6 capacidades GA; 4 previstas Q3 2026. MCP server do LeanIX já GA. (Não é o foco deste tutorial.)

## Inventário: Fact Sheets, metamodelo e até onde modelar

O inventário é a fundação de tudo. Um Fact Sheet é o registro estruturado de uma entidade arquitetural — uma aplicação, uma capacidade de negócio, um componente tecnológico, uma interface, um objeto de dados, um fornecedor. Cada tipo tem campos próprios (nome, descrição, owner, lifecycle, tags) e pode se relacionar com outros tipos. A diferença entre **relação** e **hierarquia** é sutil mas crítica: uma hierarquia modela composição (CreditCore *contém* o módulo de scoring), enquanto uma relação modela dependência ou suporte (CreditCore *suporta* a capacidade Originação de Crédito). Confundir os dois produz um grafo impossível de navegar.

No cenário FinSecure, o metamodelo padrão do LeanIX cobre bem o necessário: Business Capability → Application → IT Component → Interface → Data Object. Mas o metamodelo é configurável — e a primeira decisão de governança é: adapte o mínimo necessário. Cada tipo customizado que você adiciona é um tipo que sua equipe precisa manter. TOGAF 10 chama isso de *Architecture Repository*: você precisa de profundidade suficiente para tomar decisões, não de um inventário exaustivo.

A regra prática que uso: modele no LeanIX tudo que precisa aparecer num report de portfólio ou num diagrama de landscape. Deixe fora do LeanIX tudo que é detalhe de implementação — sequências de chamadas, contratos de API, modelos de dados internos. Esses vivem no C4 (Simon Brown) e no arc42, que operam no nível de componente e módulo. O LeanIX é o mapa rodoviário; o C4 é a planta baixa do edifício. Misturar os dois níveis no mesmo repositório é o caminho mais rápido para um inventário que ninguém confia.

## Diagrama 1 — Mapa de Inventário: Capacidade → Aplicação → Tecnologia

Visão do metamodelo aplicado ao cenário FinSecure. Mostra redundância funcional (CreditCore + LoanLegacy suportam a mesma capacidade) e o componente JBoss 4.2 em End-of-Life. Cada zona representa um tipo de Fact Sheet.

### 🏢 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)

### Fluxos

- cap1 -> app1: suportada por
- cap1 -> app2: suportada por (redundante)
- cap2 -> app3: suportada por
- cap2 -> app4: suportada por (redundante)
- cap3 -> app5: suportada por
- app1 -> tc1: usa
- app1 -> tc2: usa
- app2 -> tc5: usa (EoL!)
- app3 -> tc3: usa
- app3 -> tc4: usa
- app4 -> tc5: usa (EoL!)
- app5 -> tc1: usa

## Tipos de Diagrama do LeanIX — Quando Usar Cada Um
| Critério | Tipo | O que representa | Quando usar | Vivo ou estático? | Exemplo no cenário |
| --- | --- | --- | --- | --- | --- |
| Application Landscape | Aplicações organizadas por capacidade de negócio ou organização | Visão executiva de portfólio; identificar redundâncias; comunicar escopo de transformação | Vivo — atualiza quando Fact Sheets mudam | Mostrar CreditCore + LoanLegacy ambos em Originação de Crédito | — |
| Business Capability Map | Hierarquia de capacidades de negócio com heat map de cobertura ou risco | Alinhar TI ao negócio; priorizar investimento; identificar gaps e sobreposições | Vivo — colorido por dados dos Fact Sheets (ex.: functional fit) | Heat map de adequação funcional das 3 capacidades da FinSecure | — |
| Data Flow | Fluxo de dados entre aplicações via interfaces, com objetos de dados rotulados | Analisar integrações; planejar migração de dados; avaliar impacto regulatório (LGPD/PCI) | Vivo — interfaces e relações vêm dos Fact Sheets | Fluxo de dados de crédito entre CreditCore, LoanLegacy e Oracle DB | — |
| Roadmap / Target Architecture | Linha do tempo de iniciativas com estados As-Is, transição e To-Be por aplicação | Planejar e comunicar transformação; sequenciar iniciativas; mostrar estados intermediários | Vivo — baseado em iniciativas e lifecycles dos Fact Sheets (módulo ARP) | Roadmap da iniciativa 'Plataforma Digital 2026': descomissionar LoanLegacy e PayLite | — |
| Free Draw | Canvas livre, podendo referenciar Fact Sheets como nós ou ser completamente manual | Exploração inicial; workshops; diagramas conceituais que ainda não têm Fact Sheets | Estático (ou híbrido se nós linkados) — não atualiza automaticamente | Esboço de arquitetura alvo antes de criar os Fact Sheets formais | — |

## Diagramas vivos vs estáticos: a distinção que importa

A distinção mais importante que um arquiteto precisa internalizar sobre diagramas no LeanIX é: **diagrama vivo não é um desenho — é uma query com forma visual**. Quando você cria um Application Landscape e arrasta CreditCore para a célula 'Originação de Crédito', você não está desenhando uma caixa; você está declarando uma relação no inventário. Se amanhã alguém atualizar o Fact Sheet do CreditCore e mudar seu lifecycle para 'End of Life', o diagrama reflete isso automaticamente. Isso é o que torna o LeanIX diferente de PowerPoint, Visio ou Lucidchart para fins de portfólio.

O Free Draw existe para os momentos em que você ainda está explorando — um workshop de descoberta, um esboço de arquitetura alvo que ainda não tem Fact Sheets formais. Use-o conscientemente e com prazo: se um Free Draw sobrevive mais de duas semanas sem virar Fact Sheets, ele se torna ruído no repositório.

As três visões temporais — **As-Is**, **transição** e **To-Be** — são o coração do módulo ARP e do TOGAF 10. O TOGAF chama de *Architecture States*: current, transition, target. No LeanIX, você modela isso associando aplicações a iniciativas com datas de início e fim, e o sistema gera automaticamente a visão de qualquer ponto no tempo. Para a FinSecure, isso significa: hoje (As-Is) temos CreditCore e LoanLegacy em paralelo; em março de 2026 (transição) LoanLegacy entra em fase de descomissionamento; em dezembro de 2026 (To-Be) só CreditCore existe. Esse storytelling temporal é o que transforma um inventário em argumento de transformação.

## Diagrama 2 — Data Flow: As-Is × To-Be (Originação de Crédito)

Comparação do fluxo de dados de crédito antes e depois da iniciativa 'Plataforma Digital 2026'. As-Is: dois sistemas redundantes (CreditCore + LoanLegacy) escrevem na mesma base Oracle via interfaces separadas. To-Be: LoanLegacy descomissionado, fluxo consolidado em CreditCore com 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)

### Fluxos

- asis_gw -> asis_cc: IF-001: REST
- asis_gw -> asis_ll: IF-002: SOAP (legado)
- asis_cc -> asis_db: IF-003: JDBC
- asis_ll -> asis_jb: runtime EoL
- asis_ll -> asis_db: IF-004: JDBC (duplicado)
- tobe_gw -> tobe_cc: IF-001: REST (consolidado)
- tobe_cc -> tobe_db: IF-003: JDBC
- tobe_cc -> tobe_q: cache / eventos

## Reports: da pergunta à decisão

Um report sem uma decisão associada é decoração. Essa é a regra que aplico em toda revisão de portfólio. O LeanIX oferece reports configuráveis, e a disciplina é sempre partir de três perguntas: *qual decisão preciso tomar?* → *qual dado preciso para isso?* → *qual report expõe esse dado?*

**Portfolio Report (APM):** Pergunta — 'Quais aplicações estão ativas, em que fase do ciclo de vida e com que adequação funcional/técnica?' Dado necessário — lifecycle, functional fit e technical fit preenchidos nos Fact Sheets de aplicação. Decisão habilitada — priorizar quais aplicações investir, manter ou descomissionar. Na FinSecure, esse report revela imediatamente que LoanLegacy tem adequação funcional 'inadequate' e adequação técnica 'inadequate' (JBoss EoL), justificando o descomissionamento.

**Matriz Capacidade × Aplicação:** Pergunta — 'Quais capacidades de negócio estão cobertas por quais aplicações, e há redundância ou gap?' Dado necessário — relações entre Business Capability e Application Fact Sheets. Decisão habilitada — consolidação de portfólio e alocação de budget por capacidade. Aqui a redundância CreditCore/LoanLegacy e PayHub/PayLite fica visualmente óbvia.

**Distribuição por Ciclo de Vida de Tecnologia (TRC):** Pergunta — 'Quais componentes tecnológicos estão em End-of-Life ou End-of-Support, e quais aplicações dependem deles?' Dado necessário — lifecycle dos IT Component Fact Sheets e relações com Application Fact Sheets. Decisão habilitada — plano de atualização tecnológica e gestão de risco. JBoss 4.2 EoL afetando LoanLegacy e PayLite é o gatilho para a iniciativa de modernização.

**Roadmap de Iniciativas (ARP):** Pergunta — 'Qual é a sequência de mudanças planejadas, e qual o estado do portfólio em cada marco?' Dado necessário — iniciativas com datas, aplicações associadas e estados (active/plan/end of life). Decisão habilitada — sequenciamento de investimento, comunicação com o board e gestão de dependências entre projetos.

## Hands-on: construindo o inventário e os artefatos da FinSecure

1. **Passo 1 — Revisar e adaptar o metamodelo** — Acesse Settings → Meta Model. Confirme que os tipos padrão (Business Capability, Application, IT Component, Interface, Data Object, Provider) cobrem o cenário. Para a FinSecure, não adicione tipos customizados nesta fase — o padrão é suficiente. Defina quais campos são obrigatórios para o completion score: no mínimo nome, owner, lifecycle e functional fit para Applications; nome, owner e lifecycle para IT Components.

2. **Passo 2 — Criar os Fact Sheets de Capacidade** — Crie 3 Business Capability Fact Sheets: 'Originação de Crédito', 'Pagamentos', 'Atendimento'. Defina a hierarquia se necessário (ex.: Pagamentos > Pagamentos Domésticos, Pagamentos Internacionais). Atribua owners de negócio — não de TI. Capacidades são estáveis; não as atualize a cada mudança de sistema. Elas representam o 'o quê' do negócio, independente do 'como' tecnológico.

3. **Passo 3 — Criar os Fact Sheets de Aplicação** — Crie 5 Application Fact Sheets: CreditCore, LoanLegacy, PayHub, PayLite, CRM360. Para cada um, preencha: lifecycle (active/plan/end of life), functional fit (adequate/insufficient/inadequate), technical fit (adequate/insufficient/inadequate), owner (time responsável), e provider (fornecedor). LoanLegacy e PayLite recebem functional fit = 'inadequate' e technical fit = 'inadequate'. Relacione cada aplicação às capacidades que suporta usando o botão 'Add Relation → Business Capability'.

4. **Passo 4 — Criar IT Components e relações** — Crie 5 IT Component Fact Sheets: Oracle DB 19c, Java 11 LTS, Node 18, Redis 7, JBoss 4.2. Para JBoss 4.2, defina lifecycle = 'End of Life' e preencha a data de EoL. Relacione cada componente às aplicações que o utilizam via 'Add Relation → Application'. Esse passo é o que habilita o report de distribuição por ciclo de vida do TRC — sem as relações, o report fica cego.

5. **Passo 5 — Criar Interfaces e Objetos de Dados** — Crie 4 Interface Fact Sheets (IF-001 a IF-004) com tipo de protocolo, frequência e owner. Crie 3 Data Object Fact Sheets: 'Proposta de Crédito', 'Dados de Pagamento', 'Perfil de Cliente'. Relacione interfaces às aplicações de origem e destino, e aos objetos de dados que transportam. Esses Fact Sheets alimentam o diagrama Data Flow e os reports de impacto regulatório.

6. **Passo 6 — Avaliar o portfólio e verificar qualidade** — Acesse o Portfolio Report (APM) e verifique o completion score de cada Fact Sheet. Fact Sheets abaixo de 70% precisam de atenção antes de qualquer report ser confiável. Use o Quality Seal para marcar Fact Sheets revisados e aprovados pelo owner — o seal vai além do completion score: indica que um humano validou o conteúdo. Configure subscriptions para que owners recebam alertas quando seus Fact Sheets forem modificados.

7. **Passo 7 — Criar diagramas vivos** — Crie um Application Landscape diagram agrupando por Business Capability — a redundância CreditCore/LoanLegacy aparece imediatamente. Crie um Business Capability Map com heat map de functional fit — Originação de Crédito ficará vermelho por causa do LoanLegacy. Crie um Data Flow diagram para o fluxo de Originação de Crédito. Todos esses diagramas são vivos: qualquer mudança nos Fact Sheets se reflete automaticamente.

8. **Passo 8 — Modelar a iniciativa e o roadmap** — No módulo ARP, crie a iniciativa 'Plataforma Digital 2026' com data de início (Jan 2026) e fim (Dez 2026). Associe LoanLegacy e PayLite à iniciativa com estado 'end of life' a partir de Dez 2026. Associe o API Gateway como nova aplicação com estado 'plan' a partir de Mar 2026. O Roadmap diagram agora mostra automaticamente os três estados temporais: As-Is, transição (Mar-Nov 2026) e To-Be (Dez 2026). Use esse diagrama para comunicar ao board — não ao time de engenharia.

## Diagrama 3 — Roadmap de Transformação: Plataforma Digital 2026

Linha do tempo da iniciativa 'Plataforma Digital 2026' mostrando os três estados arquiteturais (As-Is, Transição, To-Be) para as aplicações da FinSecure. Baseado no módulo ARP do LeanIX.

### 📸 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)

### Fluxos

- r_ll_asis -> r_ll_tr: inicia phase-out Mar/26
- r_pl_asis -> r_pl_tr: inicia phase-out Mar/26
- r_cc_tr -> r_cc_tobe: consolidado Dez/26
- r_ph_tr -> r_ph_tobe: consolidado Dez/26
- r_apigw_tr -> r_apigw_tobe: ativo Dez/26
- r_ll_tr -> r_cc_tobe: migrado para / migrated to
- r_pl_tr -> r_ph_tobe: migrado para / migrated to

> **Preceitos de boas práticas — regras de bolso:** **1. O LeanIX é o mapa, não o território.** Ele representa o portfólio; a documentação técnica vive no C4 e no arc42. Nunca tente colocar diagramas de sequência ou contratos de API no LeanIX.

**2. Comece pelo owner, não pelo dado.** Um Fact Sheet sem owner é um Fact Sheet sem responsabilidade — e sem responsabilidade, ele apodrece. Defina owners antes de publicar qualquer Fact Sheet.

**3. Quality Seal > completion score.** Um Fact Sheet 100% preenchido com dados errados é pior do que um 70% com dados certos. O seal é a assinatura humana de que o conteúdo foi validado.

**4. Adapte o metamodelo com parcimônia.** Cada tipo customizado é dívida de governança. Se o tipo padrão serve com 80% de fidelidade, use o padrão.

**5. Modele o To-Be antes de terminar o As-Is.** Se você esperar o inventário estar perfeito para começar a planejar, nunca vai começar. O LeanIX suporta estados parciais — use isso.

**6. Ligue tecnologia a capacidades de negócio.** Se o JBoss 4.2 EoL não estiver relacionado a uma capacidade de negócio, o risco é invisível para o board. A cadeia IT Component → Application → Business Capability é o que transforma risco técnico em argumento de negócio.

**7. Todo report precisa de uma decisão associada.** Antes de criar um report, escreva a pergunta que ele responde e a decisão que ele habilita. Se não conseguir, não crie o report.

> **Anti-padrões que destroem o valor do LeanIX:** **❌ Tratar o LeanIX como CMDB.** O LeanIX é um repositório de arquitetura, não de configuração. Não tente registrar instâncias de servidor, IPs, versões de patch ou tickets de incidente. Isso pertence ao CMDB/ITSM.

**❌ Usar o LeanIX só como ferramenta de desenho.** Se você usa o LeanIX para fazer bonito e não para manter o inventário vivo, você tem um Visio caro. O valor está nos Fact Sheets, não nos pixels.

**❌ Confundir Application com IT Component.** Uma aplicação é um sistema de software com um propósito de negócio (CreditCore). Um IT Component é uma tecnologia de infraestrutura ou plataforma (Java 11, JBoss). Misturar os dois quebra todos os reports de ciclo de vida.

**❌ Fact Sheet detalhado demais.** Se você está modelando campos que nunca aparecem em nenhum report ou diagrama, você está desperdiçando tempo de governança. Menos é mais.

**❌ Copiar o metamodelo sem adaptar.** O metamodelo padrão é um ponto de partida, não uma verdade universal. Mas adaptar demais é igualmente ruim — cada customização tem custo de manutenção.

**❌ Ignorar owners e qualidade.** Um inventário sem owners é um inventário sem futuro. Em seis meses, ninguém sabe quem é responsável por nada.

**❌ Só modelar o As-Is.** Um mapa do estado atual sem visão de destino é um arquivo histórico, não uma ferramenta de transformação. O TOGAF 10 é explícito: o ciclo de arquitetura requer estados atual, transição e alvo.

**❌ Mostrar report sem a decisão associada.** Reports sem decisão viram slideware. Sempre amarre o report à pergunta e à decisão antes de apresentar.

> **Minha visão sênior: o que separa quem usa bem de quem usa mal:** Depois de mais de 16 anos em arquitetura — incluindo sistemas financeiros onde a visibilidade de portfólio não é opcional, é regulatória — aprendi que ferramentas como o LeanIX falham por razões humanas, não técnicas.

O maior erro que vejo é o arquiteto que passa semanas construindo um inventário impecável e depois o usa para fazer apresentações bonitas para o comitê de TI. O LeanIX não é para o comitê de TI — é para o arquiteto que precisa responder perguntas difíceis em tempo real. 'Quantas aplicações dependem do JBoss 4.2 que entra em EoL em março?' Você deveria conseguir responder isso em 30 segundos, não em dois dias.

O segundo erro é achar que o LeanIX substitui o pensamento arquitetural. Ele não substitui. Ele acelera. A diferença entre um arquiteto que usa o LeanIX como acelerador e um que o usa como repositório passivo é que o primeiro parte do inventário para raciocinar sobre o futuro; o segundo atualiza o inventário depois que as decisões já foram tomadas — e aí ele é só documentação retroativa.

A metáfora do Architecture Elevator de Hohpe é precisa aqui: o LeanIX é o painel do elevador. Ele mostra em qual andar você está, quais andares existem e qual botão apertar. Mas quem decide para onde ir — e por quê — é o arquiteto. A ferramenta não toma decisões; ela torna as decisões defensáveis com dados.

Por fim: invista no SAP Learning para o treinamento formal (a antiga Academy foi desligada em fevereiro de 2026 e migrou para lá). E fique de olho no SAP AI Agent Hub — a capacidade de governar agentes de IA e servidores MCP no mesmo repositório onde você já governa aplicações e componentes é, genuinamente, uma mudança de paradigma para os próximos dois anos.

## Veredicto

O SAP LeanIX é, hoje, a ferramenta mais madura disponível para o arquiteto que precisa manter um mapa corporativo vivo e usá-lo como acelerador de transformação. Seus três módulos (APM, TRC, ARP) cobrem o ciclo completo: inventariar, avaliar risco tecnológico e planejar o futuro. Os diagramas vivos — ligados aos Fact Sheets — eliminam o problema clássico de documentação que fica desatualizada em semanas. Os reports, quando usados com disciplina (pergunta → dado → decisão), transformam o inventário em argumento de negócio.

Mas o LeanIX não é mágica. Ele é tão bom quanto a qualidade do inventário que você mantém — e a qualidade do inventário depende de owners comprometidos, metamodelo bem calibrado e uma cultura onde atualizar o Fact Sheet é parte do processo de mudança, não uma tarefa opcional de pós-projeto.

O que o LeanIX não faz: ele não substitui o C4 para diagramas de componente, não substitui o arc42 para documentação de decisões de software, e não substitui o pensamento do arquiteto. Ele é o painel do elevador de Hohpe — não o arquiteto que aperta os botões.

Para quem está começando: construa o inventário mínimo viável (capacidades + aplicações + componentes críticos), ligue as relações, configure os owners, e use o Portfolio Report e a Capability Matrix antes de qualquer outra coisa. Isso já justifica o investimento na ferramenta. O resto vem com a maturidade.

## Referências

- [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/)

## Fontes do caso

- [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/)