In the first post, I talked about the communication gap in enterprise software: too many stakeholders, too many languages, too many documents — and no shared source of truth.
In the second post, I argued that enterprise software does not need to be bespoke everywhere. Like nature, it can be composed from a surprisingly small set of well-understood building blocks.
But this raises the next, very practical question:
How do we document an entire enterprise solution without drowning in complexity?
Think of a platform that manages the full policy lifecycle. Sales, onboarding, underwriting, servicing, billing, claims. Hundreds of scenarios. Thousands of edge cases. If we try to model everything in one go — even with a tool that offers an “infinite canvas” — we fail before we start. Not because the tools are bad, but because humans are.
This is where a hierarchical, top-down approach becomes essential.
At the very top, we don’t model behavior yet. We simply name the big things the platform exists to do: onboarding customers, underwriting risk, administering policies, managing payments, handling claims. Nothing more. Just the landscape.
Each of these areas is still far too large to reason about in one model. So we keep drilling down. Take policy administration and servicing. That alone breaks naturally into areas like lifecycle management, policy changes, coverage and benefits, customer servicing, documents, financial adjustments, and exceptions.
Drill further. Policy changes become contractual vs. technical. Contractual changes become coverage, benefits, sums insured. And eventually — after several levels — we reach something that finally fits into a human working memory.
Something like: “Guaranteed sum insured increase without underwriting.”
This is the moment where modeling becomes productive. Anything above this level is too vague. Anything below risks fragmentation. But here, we can bring the right people into a room — product, business, underwriting, tech, operations — and model the behavior together using EventModeling. Not a hypothetical flow, but what actually happens, including rules, side effects, data, and decisions.
Crucially, the model does not live in isolation. Each modeled process is linked directly from its position in the process hierarchy. And the hierarchy links back from the model. The tree becomes the index of the enterprise, and each EventModel becomes a deeply explored chapter.
Everyone bookmarks the same entry point. No more guessing where documentation lives. No more parallel truths. No more “tribal knowledge.” Just one navigable structure that grows branch by branch, as the platform grows. This is not documentation as an afterthought. It is documentation as scaffolding — something you build first, then climb as high as you need.
And once you have that scaffolding, predictability, alignment, and reuse stop being aspirations. They become properties of the system.
A Quiet Shift in Governance and Compliance
One interesting side effect of this approach is how it changes the conversation around governance and compliance.
Instead of governance being something that happens after the fact — reviews, approvals, audits, controls layered on top — it becomes embedded in the structure itself. When every meaningful business capability has a clearly defined place in the process hierarchy, and every non-trivial change is backed by an explicit EventModel, there is far less room for ambiguity.
Compliance teams no longer have to reverse-engineer intent from code or fragmented documents. Auditors don’t have to dig into Jira ticket or to infer behavior from screenshots, Sharepoint or Confluence documents or PDFs. The “why” and the “what” of the system are already there, visible and traceable.
Even better, governance stops being a gatekeeper function. It becomes navigational. You can point to a branch in the tree and say: this is the scope, these are the scenarios, this is where decisions are made. Discussions become concrete, focused, and dramatically shorter.
In that sense, good governance is no longer enforced. It emerges naturally from a system that was designed to be understood.
List of related posts:
- Post 1: We lack a shared language and blueprint
- Post 2: We can work with a small set of repeatable building blocks
- Post 3: this one
Originally published on LinkedIn (2026-01-03): https://www.linkedin.com/pulse/from-common-language-living-map-enterprise-gabriel-n-schenker-argae
