Architecture Decisions: Designing Governance from the Ground Up
Projects
Architecture Decisions: Designing Governance from the Ground Up
SAP LeanIX helps enterprise architects map and govern complex IT landscapes. But there was no native way to capture why decisions were made. Teams kept Architecture Decision Records in Confluence, SharePoint, and spreadsheets, completely disconnected from the architecture they were documenting.
Goal
Bring Architecture Decision Records natively into LeanIX, giving enterprise architects a structured, flexible way to document, govern, and link decisions directly to their technology landscape.
Year
Client
SAP LeanIX
Role
Senior Product Designer (Design Owner)
(Impact)
From zero to platform-wide adoption in the months following GA.
The feature launched to General Availability in Q1 2025, following an Early Adopter Program with 23 enterprise customers including SAP SE, Deutsche Bahn, Mercedes-Benz, DHL, PwC, Nestlé, ALDI Süd, and MediaMarktSaturn.
The Amplitude data captures what happened after:
Signal | What the data shows |
|---|---|
Enterprise customers at GA | 1,300+ |
Unique users (Collaboration Tab) | Reached ~23,378 unique users post GA |
Weekly retention | ~70% |
Post-GA roadmap | 5 follow-on Architecture Decisions features released in Q2 2025. |
5 follow-on features shipped in Q2 2025 including Fact Sheet back-linking, diagram previews, and options comparison.
(The Context)
SAP LeanIX helps organizations map and govern their entire technology landscape. Architecture decisions are where that governance breaks down.
SAP LeanIX is an Enterprise Architecture Management (EAM) platform used by some of the world's largest organizations such as Deutsche Bahn, Mercedes-Benz, DHL, PwC, Nestlé, to manage complex IT landscapes and the relationships between them. Enterprise architects use it to understand what technology exists across their organization, what it does, and what it should become.
But there was a critical gap: while LeanIX gave architects visibility into what existed in their landscape, it had no native way to capture why decisions were made. Architecture Decision Records (ADRs), the documents that log the rationale, trade-offs, and context behind major technical choices, were being maintained entirely outside the platform. Teams were stitching together SharePoint lists, Confluence pages, email threads, and custom Fact Sheet workarounds, disconnected from the architectural context they were meant to govern.
When I joined Team Echo, I became the first and only designer dedicated to solving this problem.
(The Challenge)
Architects knew their landscape. They had no way to explain it.
ADRs are a mature practice. Every organization had their own format, tooling, and conventions. Yet none of it connected to LeanIX.
Key gaps:
Decisions scattered across Confluence, SharePoint, improvised Fact Sheet workarounds
No link between a decision and the architecture it affected
Governance was happening entirely outside the platform built to enable it
(Research & Strategy)
A specialized domain, no playbook, and a tight timeline.
Enterprise architects have strong conventions around ADRs and no patience for tools that ignore those conventions.
So, I immersed myself in the domain fast: reviewing existing session recordings, conducting desk research, and embedding directly into customer discovery to observe real workflows and ask behavioral follow-ups.
What the research revealed:
Overlapping structure: common sections appeared across every customer's ADR regardless of company or tooling
Diverging content: what went inside those sections varied significantly by organization
No universal format: but common building blocks could serve everyone
This gap between structure and content became the design principle that drove every decision that followed.
(Solution)
Answer the structural question before designing anything.
Should Architecture Decisions live in LeanIX's meta model as a new Fact Sheet type?
When asked, no one had a clear answer, so I assessed the risk. Touching the meta model meant:
cascading dependencies
Increased cost
Potential disruption to existing customer data at a scale disproportionate to what the feature needed to do.
Product Decision: In collaboration with the PM and EM, I recommended the optimal solution to build Architecture Decisions as a document artifact linking them to Fact Sheets.
Design Rational: I could use LeanIX's existing "Documents" concept as the structural foundation, which extended to other teams' modules
Preserved full value: contextual linking, structured content, searchability; all required features would be covered
Contained scope and dependencies keeping General Availability realease on track
The concept of "Documents" intrigued designers in other squads and had usable cases for their modules, driving design consistency overall.
Structured flexibility and the thinking behind it.
The research revealed a real tension:
half of customers needed strict templates,
the other half rejected anything rigid.
The answer wasn't a compromise. It was a more precise, deeper definition of the user problem.
With further user research, I realized that structure mattered at the section level. Content varied at the field level. Prescribing both would break the feature for too many users.
Core design decision: a modular component system.
Design decisions:
Rich-text as the primary component: a mental model users already have, zero learning curve.
Handles content diversity without custom solutions for every case
Additional components such as date pickers, user fields, status, references. All freely stackable.
Users compose what their process requires; the system doesn't impose one (but it does offer a best-practice template for those that need one.)
In simpler terms:
Every user gets the same building blocks. How they assemble them is up to them.
This shipped at GA and remains the core of the templates feature today.
Connect decisions to the architecture they affect without disrupting what already exists.
Linking Architecture Decisions to Fact Sheets was the feature's core value. But Fact Sheets were simultaneously undergoing a major layout redesign making this a coordination problem as much as a design one.
Design decisions:
Coordinated directly with the Fact Sheet lead designer to avoid conflicts mid-redesign
Kept integration footprint minimal: maximum value, minimum disruption
Back-linking from Fact Sheets → Decisions scoped as follow-on, shipped Q2 2025
(Constraints)
Shipping right mattered more than shipping everything.
The push was to build broadly and move fast. With those parameters, I advocated for a tighter MVP. In enterprise governance, a poorly considered feature creates serious trust debt that's hard to recover from.
Components designed but sequenced post-GA i.e. options comparison, diagram previews, both shipped in Q2 2025, validating the call.
Two practices that kept the team moving:
Co-design rituals with engineering: constraints surfaced early, no late-breaking blockers
Design system championship: I contributed LeanIX-specific patterns during the SAP Horizon migration, and led a navigational patterns workshop that shaped how users access the Documents module across the platform
(Future Opportunities)
The feature has data. The next step is making it intelligent.
With the advent of AI, opportunities to automate and streamline the module came into play. During the early conceptualization, I was already looking into the future landscape. Some of the main explorations included:
Decision surfacing: suggesting relevant past decisions when drafting a new one
Pattern recognition: surfacing recurring themes across the organization's landscape in order for Enterprise Architects to make holistic governance decisions
Governance health: flag decisions overdue for review and suggest recommended actions based on best practices
The infrastructure exists. The opportunity was in designing institutional memory with a point of view driven by existing data.
