Enterprise architecture that settles who owns what, before you build.
Enterprise architecture consulting gives you a decided landscape.
Whether you run ServiceNow, SAP, Salesforce or a landscape that grew one project at a time, this is the work that makes every later decision cheaper.
What is enterprise architecture?
Enterprise architecture is the discipline of aligning an organization's systems, data and capabilities with its business strategy as a coherent whole, not one project at a time. The focus is what the business needs to achieve, not IT infrastructure alone. Governed by standardized frameworks like TOGAF and IT4IT, it answers four questions.
The discipline works in five layers, and the layers are useful because problems announce themselves at a particular one.
Business Architecture
The capabilities and value streams the organization needs, independent of any software. Order management is a capability. The system you run it in is not.
It is not solution architecture.
A solution architect designs one system for one set of requirements. An enterprise architect decides what the whole estate should be, and those decisions have to still be right for the project that starts in eighteen months, which is why the recorded rationale matters more than the diagram.
It is not process design either.
Process design decides how one piece of work should flow. Enterprise architecture decides what the landscape those processes run on should be.
What do you get out of enterprise architecture work?
Enterprise architecture work turns recurring arguments into recorded decisions. Platform choices become defensible, integrations get simpler to specify, and the next project starts from an answer instead of a debate.
Projects start from a decision, not a discussion
Boundaries, ownership and capability allocation are documented, so scoping begins where it used to end.
Integration gets cheaper to specify and safer to change
The pattern follows from how each system is classified, so interfaces get designed once instead of negotiated per project.
Platform and license decisions become defensible
Capability allocation is agreed before a contract is signed, so you buy what the landscape needs and can show the board why.
Duplication becomes visible, and decommissioning becomes possible
A portfolio mapped to capabilities shows what two systems are doing at once, which is the first step to running one.
Your data is ready for AI and for audit
Clear ownership for each object is what lets an AI agent, and an auditor, act on the right record.
Change stops being re-litigated
Every decision carries its rationale, so a new team inherits the reasoning instead of reopening it.
This pays for itself when…
Named artifacts, not a directional slide pack
You get decisions your business and technology people make together, each recorded with its rationale: which capability sits in which system, which system is authoritative for each business object, where the boundaries are, what gets decommissioned, what has to be built. The consultant leaves, the decisions and the reasoning stay. On contracted design work these are the deliverables, with acceptance criteria attached.
A capability map
The capabilities your organization needs, how they relate, and which ones the landscape supports today. Every later investment case starts from it.
An application portfolio
Every application in scope, mapped to the capabilities it serves, so overlap, gaps and decommissioning candidates are visible rather than suspected.
A data and information layer overview
How information actually moves between systems and which system owns each object. This is where portfolio optimization starts, because you cannot simplify what you cannot trace.
An identity and key strategy
The identifiers the landscape depends on, such as customer, contact, product and subscription, and how they reconcile across systems.
A diagram nobody can trace back to a decision is decoration.
Bring us the boundary your projects keep re-arguing and we will show you what it looks like decided, recorded and held.
Most landscapes were never designed. They accumulated.
A tool arrived with a project, another with an acquisition, a third because one team needed something quickly. Each decision was reasonable on its own. Together they produce an estate where two systems hold the same customer, nobody can say which is right, and every new requirement starts with an argument. Four patterns show up almost every time.
Capabilities are not mapped to what the business needs
Nobody can say which capabilities the landscape supports today, or where the same one is served twice, so every investment case starts by rediscovering the estate you have already paid to build.
Applications are connected, not integrated
Interfaces accumulate one project at a time, without a shared integration pattern. Systems sync data no single system clearly owns, so reconciliation never ends and each new interface costs more than the last.
No end-to-end ownership of an application
There are diagrams and many responsible people, but no application owner keeping the artifacts current and the application used as designed. Decisions get taken again because nobody holds them.
The platform decision gets made backwards
A product is selected, then the landscape is bent to fit it. Capability allocation happens after the license is signed, which is the most expensive order to do it in.
Every project re-arguing the same boundary?
We decide it with you once, and write it down.
What is enterprise architecture management, and when do you need it?
What is it?
Enterprise Architecture Management (EAM) is the continuous governance practice that ensures the IT landscape measurably and efficiently supports the business strategy. While EA is the blueprint, EAM enforces, financially manages and sustains it in everyday operations.
What does it do?
EAM operationalizes the "handshake" between strategy and execution. It establishes the framework within which Solution Architecture can build tailored solutions decentrally and rapidly, without plunging the entire organization into chaos.
Where does it go wrong?
Many organizations invest in EAM tooling, governance boards and repository maintenance before they have done the actual enterprise design work. You end up managing what exists rather than steering toward what should exist, with governed processes but no governing decisions.
Do we need a tool?
Dedicated EAM platforms like ServiceNow Enterprise Architecture are powerful: structured repositories, capability mapping, dependency visualization and lifecycle management. But a tool solves a documentation and governance problem, not a decision problem. Prove the discipline first. If ServiceNow is already in your stack, start there, it is capable enough to carry early EAM maturity. But invest in the design work before you invest in the platform to hold it.
EAM without enterprise architecture is administration.
Enterprise architecture without EAM is a whiteboard that fades.
Most integration complexity is an unanswered ownership question, written in code.
Every application in a landscape plays one of three roles, and the role determines the integration pattern, not the other way around. Get the classification right and interfaces become specification work instead of negotiation.
System of record
The one system whose version of a business object is treated as correct when systems disagree.
Finance for invoices · product master for pricing · identity provider for identity
System of engagement
What users and customers interact with: portals, mobile apps, service desks. They move fast and must not be tightly coupled to the record systems behind them.
API gateways or integration hubs keep the record system stable while this layer iterates
System of insight
Consumes data from both, typically in high volume and asynchronously, to produce analytics, predictions, or operational intelligence.
It reads and derives. It does not own.
Strict, synchronous operations and governed write access.
Speed and loose coupling.
Throughput and tolerance for latency.
"Single source of truth" implies one system holds everything, which is almost never the right design.
The precise term is system of record. The German equivalent is führendes System.
The classification dictates the pattern. Wire them the wrong way around and you get complexity that looks technical but is really an unanswered ownership question, written in code.
Related: ServiceNow Integrations.
Negative boundaries prevent more work than positive ones create.
Most architecture documents say what each system does. Very few say what each system is explicitly not responsible for, which is where the expensive ambiguity lives. So we write the negative boundaries down as standardized artifacts with the same weight as capability allocations or system-of-record definitions: documented, rationale attached, governed through the same decision log.
The marketing platform is not responsible for pipeline control, quoting or order processing.
One sentence like that, recorded as a formal architecture decision with its reasoning attached, removes more integration debate than all the positive scope statements around it.
We record where ServiceNow is not the right place for mass event brokering, the digital twin or the native EDI gateway, and where the existing enterprise service bus, data platform and EDI gateway should stay exactly where they are.
A workflow platform is a system of action, not a replacement for every system it touches, and that position is a named deliverable, not an opinion.
The most useful line in an architecture document is often the one that says no.
Who may see what is architecture, not configuration.
Access gets treated as a build-phase detail and then becomes the reason a go-live slips. We shape it with the architecture instead: least privilege, roles rather than named users, an additive role model, and attribute-based access where entity, region or assignment group constrains what a person sees. These are architecture decisions, governed through the same decision log as everything else.
Business roles
The roles people hold, designed with the business architecture.
Enforcement layer
Applies them at table, field and record level.
Service accounts
What integrations use. They are not people and should never inherit a person's rights.
All standardized artifacts, all rationale attached.
We look at what you already have before we quote you for more.
A lot of architecture spend is a second attempt at work that already exists in a state nobody trusted. So on review engagements the sequence is deliberate.
Read the existing process documentation, backlog, architecture decisions and current platform state
Separate what can be reused as it is, what needs sharpening, and what is a genuine gap
List the decisions still outstanding
Estimate the effort actually required
Recommend jointly, business and technology together, whether to proceed at all
If it proceeds, requirements get classified into four words that have very different costs, and most estimates blur them. Each classification becomes a standardized artifact with its rationale, not a line in a spreadsheet.
On design work we are required to document the recommended system of record and the integration boundary with the rationale, including where an existing system or another supplier's product is the better answer for you.
Senior architects, and no layer between you and them.
The value is not framework knowledge, which is published and free. It is facilitating the conversation between business and technology that most organizations struggle to hold: getting the right people on one canvas, structuring the design across the layers, and making sure decisions are taken rather than deferred.
The people who scope the work do the work
No account layer, no handover to a team you have not met. The architect in your workshop is the architect on your engagement.
Senior practitioners, from first workshop through go-live
Founder experience runs to 20+ and 18+ years in platform and business operations, and those are the people facilitating the design with you, not presenting slides.
We implement what we design
We build the commercial, customer service, field service and portfolio side of ServiceNow. An architecture written by people who have never delivered inside it tends to be optimistic in specific, predictable places. Our artifacts are shaped by what survives implementation.
Independence is written into the contract
We are obliged to document where another product is the better answer. That is a term of business, not a value.
Architecture is where those multiply or fail to. A landscape collaboratively designed to fit the strategy makes every later decision cheaper.
See what your next project could start from.
The first conversation is not a proposal. We look at your current documentation, your open decisions and the state of your estate, and tell you whether enterprise design work is the right spend or whether something cheaper solves your actual problem.
Questions we get asked.
What is the difference between enterprise architecture and solution architecture?
›
Scope, lifespan and who sits at the table. Solution architecture is classic IT solution design: one system, one set of requirements, one technical answer. Enterprise architecture is collaborative design: business strategists, domain experts and architects shaping the organization's capabilities, data and technology landscape together, using standardized frameworks. Both are needed. The failure mode is letting a series of good solution decisions add up to an estate nobody deliberately chose.
Do we need an enterprise architecture tool?
›
Probably later than the vendors suggest. Platforms like ServiceNow Enterprise Architecture are strong at maintaining a model and governing change, but they cannot make a decision that has not been taken. If nobody can say which system is authoritative for the customer record, a tool documents the ambiguity rather than resolving it. Prove the design discipline first, then licence a platform once you know what you are holding.
Do we need enterprise architecture work yet?
›
Not always, and we will tell you in the first conversation. If you run a small number of applications with clear ownership, the honest answer is not yet. If the real problem is one process nobody has designed, Business Process Consulting and Design is the cheaper answer. If you have a target architecture and nobody will decide, that is a decision-rights problem and Operating Model Design is the right conversation. A landscape model no project is obliged to follow changes nothing, so the one we design with you is the one your projects consult.
Do we need TOGAF or ArchiMate for this?
›
A formal framework helps when several people have to read the same model over several years, and it is overhead when the real deliverable is four decisions. We use TOGAF's layered model where it earns its place and collaborative design languages where the conversation spans business and technology. We agree the modelling standard with you at the start, and would rather produce a small model your projects must follow than a complete one nobody consults.
Is ServiceNow's Enterprise Architecture product the same thing as this?
›
No. ServiceNow sells a product called Enterprise Architecture that supports architecture management inside the platform. This service is the consulting discipline: deciding what the landscape should be across whatever systems you run, including the ones that are not ServiceNow. The two can meet, because a landscape decision needs somewhere to live afterwards, and if ServiceNow is already in your stack it is a strong candidate. But buying the product does not produce the decisions.
How does AI change the architecture decision?
›
It raises the cost of unclear data ownership. AI that acts across systems needs to know which record is authoritative and what it is allowed to do, so the ambiguity a human colleague works around becomes a governance problem. We design for ServiceNow and Claude together: ServiceNow orchestrates the workflow and holds the governance, Claude brings the intelligence that reads, reasons and drafts across the landscape. The architecture decides where each one acts, which records it may touch, and which system of record it answers to. The questions do not change. They get asked earlier, answered more precisely, and governed through the same standardized artifacts as every other architecture decision.