Discuss
The people involved — stakeholders and areas that take part in the dynamic in question — come together to examine a layer, a domain, a subdomain.
How to apply the framework
Clara/EA doesn't start with a ready-made model brought in from outside. It starts blank — even when the company already exists — and evolves through successive, spiral cycles, until layers, domains, entities, processes and relationships are understood the same way by the people who live the operation.
The starting point
No ready-made model from another company is imported, and no generic template is filled in. Clara/EA is built together with the people who live the operation — this applies equally to mapping a company that already exists and to discussing the creation of a new one.
In defensive use, the blank page is deliberate: even where documentation already exists, the work starts from zero so the model reflects the real operation, not what was written down years ago. In greenfield use, the blank page is literal — the layers are defined before any system is built, serving as a blueprint for growth.
"The most important thing isn't filling in a template. It's building, with the right people in the room, a shared understanding of what the company is."
The method
Clara/EA isn't applied in a single sequence of steps from start to finish. It's applied through several successive iterations — in a spiral — that sweep through the layers repeatedly, each pass reviewing and deepening what the previous one had already raised.
The people involved — stakeholders and areas that take part in the dynamic in question — come together to examine a layer, a domain, a subdomain.
The discussion pursues one thing only: that everyone sees the entities, processes and relationships of that layer the same way — not the opinion of whoever speaks loudest.
Everything that is understood in common is recorded — today, in EA/CMDB. Not to bureaucratize the conversation, but so the next iteration starts where this one left off, not from zero.
With every new turn of the spiral, what was already recorded is reviewed in light of what was learned afterward — and adapted when necessary. That's why the model is evolutionary, not final.
The cycle repeats layer by layer, domain by domain — each pass faster than the last, because it starts from what was already validated, not from zero.
Where business meets technology
When the work reaches IT architecture, the starting point isn't a list of existing systems. It's the business architecture already mapped: IT domains and subdomains are identified by analyzing products and services and the processes involved in their lifecycle — because solutions exist to support those processes, not the other way around.
It's this chain — not the technical inventory — that determines how systems should be grouped and integrated.
Drawing convention
The same convention works for any industry — the Market Cases prove it. On the left, the domains facing customers. In the center, the domains born from the product's lifecycle, in the order it is structured, sold and settled. On the right, the external-source domains — what feeds the business. At the bottom, the support and management domains, common to any product.
← Customers
Digital channels
App, online banking and Open Finance APIs
Service
Branches, call center and chat
Relationship
Onboarding and KYC, segmentation and offers
Products and lifecycle
Origination pipelines
Application, credit analysis, approval levels, formalization
Products and services
Accounts, cards, credit, investments and insurance
Financial settlement
Instant payments, wire transfers, bills, clearing and cards
External sources →
Funding and treasury
Fundraising, ALM and liquidity management
Market infrastructure
Payment systems, exchanges, registries and card networks
Bureaus and partners
Credit bureaus, correspondents and data providers
Base
Support and management
Management
Risk, compliance and MIS
Accounting, tax and regulatory
Statutory accounting, taxes and regulatory filings
Administrative
HR, procurement and legal
Illustrative example inspired by the banking sector — it does not reflect the real architecture of any specific organization.
Maturity model
Five levels to assess where a company stands — and where the method takes it, iteration after iteration.
Decisions made under pressure, without an explicit model. When architecture exists, it lives in a few people's heads.
First mappings recorded, isolated by area. There is still no shared view between business and technology.
Layers and domains consistently mapped, with a repeatable method and a living repository.
Business and technology share the same view in a graph. The impact of a change is analyzed before it happens.
Architecture evolves in short cycles, with intention. The company changes by decision, not by reaction.
The goal isn't rigidity — it's the capacity to change with intention and speed. Where is your company today?
In closing
Each turn of the spiral leaves the company closer to shared understanding and higher on the maturity model. To facilitate this process, or to see where everything gets recorded, read on.