How We Help Organizations Structure Their Architecture

⏱ 21 min read

Most enterprise architecture is too abstract to be useful and too political to be honest.

That’s the problem.

A lot of architecture teams say they are “aligning business and technology,” but what they actually produce is a pile of diagrams, a bloated standards catalog, and a governance process that slows down delivery without improving decisions. They create architecture theater. Nice slides. Weak outcomes. ARB governance with Sparx EA

We take a different view.

When we help organizations structure their architecture, we are not trying to make the architecture function look sophisticated. We are trying to make the organization easier to change, safer to scale, and harder to break. That means architecture has to become operational. It has to shape decisions in funding, platform design, security boundaries, data movement, integration patterns, and ownership. If it doesn’t do that, it’s just decoration.

So the simple version, early and clear: we help organizations structure enterprise architecture by defining clear domains, decision rights, technology guardrails, target states, and delivery mechanisms that work in real life. Not in the slide deck. In the actual bank, insurer, retailer, manufacturer, or public sector environment where systems are old, politics are real, and nobody gets a greenfield.

That sounds obvious. It isn’t. Most organizations still organize architecture around artifacts instead of decisions.

And that’s why they struggle.

Architecture structure is not an org chart problem. It’s a decision problem.

Let’s start with the thing people often get wrong.

When leaders say, “We need to structure our architecture better,” they usually mean one of four things:

1. We don’t know who decides what.
2. Our platforms are inconsistent.
3. Teams deliver fast but create a mess.
4. We have standards, but nobody follows them.

These are not documentation problems. They are structure problems. And structure in architecture means:

• how business capabilities are mapped to systems
• how domains are defined
• how ownership is assigned
• how technology choices are constrained
• how exceptions are handled
• how target states are sequenced
• how governance is tied to delivery

That’s the real work.

In practical terms, we help organizations answer questions like:

• Which systems are strategic, and which are just legacy utilities we should contain?
• Where should event streaming with Kafka be used, and where is it overkill?
• How should IAM be centralized without making every delivery team wait three months?
• What belongs on cloud-native platforms, and what should remain where it is for now?
• Which architecture decisions are enterprise-level, and which should stay with product teams?

If you don’t answer those questions explicitly, the organization answers them accidentally. Usually through whoever shouts loudest, buys the tool first, or gets there before governance notices. EA governance checklist

That is not architecture. That is drift.

Our basic model: structure architecture around business domains, platform capabilities, and decision rights

We usually introduce a simple model first, because if the architecture structure can’t be explained simply, nobody will use it.

Here’s the short version.

We structure architecture across three layers:

That sounds standard. But the contrarian part is this: we do not treat these layers as separate worlds.

Too many organizations create an enterprise architecture team that talks in capability maps, a platform team that talks in Kubernetes and identity providers, and solution teams that just want to ship features. None of them really connect. Then leadership wonders why strategy and delivery feel disconnected. capability map template

The structure only works if the layers are tied together through actual decision paths. For example:

• business domain definition affects service ownership
• service ownership affects data ownership
• data ownership affects Kafka topic ownership and event design
• event design affects security controls and IAM patterns
• IAM patterns affect customer onboarding, fraud controls, and cloud deployment choices

That is architecture structure in real terms. Not boxes. Consequences.

What we actually do when we help an organization structure architecture

There’s usually a romantic idea that architects arrive, assess everything, design a future state, and then everyone follows the blueprint. That almost never happens. The real work is messier and more political.

Here’s how we usually approach it.

1. We identify where architecture decisions are currently being made

Not where the organization says they are made. Where they are actually made.

Sometimes it’s in a central architecture board. More often it’s in procurement, in a security team, in a cloud center of excellence, inside a dominant engineering group, or in a program manager’s risk log.

This matters because if decision rights are hidden, architecture governance becomes fake. You can publish standards all day long, but the real architecture will still be shaped elsewhere. architecture decision record template

2. We map business domains and capability ownership

We don’t start with applications. We start with business operating reality.

In a bank, for example, we might map domains such as:

• customer onboarding
• identity and access
• payments
• lending
• fraud and financial crime
• servicing
• collections
• finance and regulatory reporting

Then we look at where these domains are fragmented across systems, teams, and processes. This is usually ugly. One domain spread across six apps, three vendors, two integration styles, and no clear owner. Very normal. Very expensive.

3. We separate strategic platforms from incidental technology

Everything cannot be strategic. If you treat everything as a core architectural concern, nothing gets governed well.

We help organizations identify which shared capabilities truly need enterprise-level consistency. Usually this includes things like:

• IAM
• cloud landing zones
• integration and eventing
• observability
• data governance foundations
• network and security controls
• developer platform standards

Then we define guardrails and ownership around those. Not around every possible tool.

4. We define target states with transition logic

This is where many architecture teams fail. They produce a target state with no credible path from here to there.

We care a lot about transition architecture:

• what changes first
• what remains stable
• where coexistence is required
• what technical debt is tolerated temporarily
• which dependencies are business-critical

A target state without transition logic is fantasy. Architects should stop pretending otherwise.

5. We embed architecture into delivery and governance

Architecture only works when it is part of portfolio planning, solution design, funding, and engineering controls.

That means:

• architecture principles linked to investment decisions
• reference patterns linked to delivery templates
• standards linked to automated controls where possible
• exception processes that are fast and visible
• architecture reviews focused on risk and fit, not ceremony

This is the practical end of architecture. The part that matters.

The mistake many architects make: they confuse standardization with structure

This one comes up constantly.

An organization sees inconsistency. Different cloud patterns. Different API standards. Different IAM implementations. Different integration tools. So the architecture team responds with standardization. More standards, more review gates, more templates.

Sometimes that helps. Often it makes things worse.

Why? Because inconsistency is not always caused by lack of standards. It is often caused by poor structural design:

• unclear domain boundaries
• shared systems with conflicting demands
• no ownership for data
• central teams bottlenecking delivery
• duplicated platforms because nobody trusted the first one
• governance that catches issues too late

In other words, the problem isn’t just that teams made different choices. The problem is the organization gave them no coherent architecture environment in which to make good choices.

That’s why we focus first on structure.

A healthy architecture structure allows some local variation while preserving enterprise coherence. That’s the sweet spot. Uniformity is not the goal. Interoperability, security, resilience, and manageable change are the goals.

This is one of those contrarian points that some architecture teams resist. They want consistency because consistency feels controlled. But too much forced consistency creates shadow IT, workarounds, and fake compliance. Teams will tell governance what it wants to hear, then build what they need anyway.

Better to define the few things that really must be consistent, and be ruthless about those. Then allow freedom elsewhere.

How this applies in real architecture work

Let’s make this concrete.

In real architecture engagements, the work usually lands in a few recurring areas.

1. Domain ownership and application rationalization

Organizations often have dozens or hundreds of applications that evolved around projects, vendors, mergers, and local business needs. Nobody designed the portfolio as a whole. It just happened.

We help structure this by asking:

• Which business domain does each application serve?
• Is it a system of record, system of engagement, or utility?
• Who owns the business capability and the data?
• What should be consolidated, wrapped, replaced, or left alone?

This changes architecture from “we have too many apps” into a clear structural roadmap. TOGAF training

For example, in a bank, customer identity may exist in:

• CRM
• digital banking platform
• branch onboarding platform
• fraud engine
• IAM directory
• marketing systems

That is not just a data quality issue. It is an architectural ownership issue. If there is no clear master identity model and no agreed domain ownership, everything downstream suffers: onboarding, KYC, fraud checks, authentication, consent, support, analytics.

The architecture response cannot just be “implement MDM” or “add APIs.” Those are tools, not structure.

2. Kafka and event-driven architecture

Kafka is a good example of where architecture structure matters more than technology enthusiasm.

Many organizations adopt Kafka because it is modern, scalable, and widely used. Fine. But Kafka by itself does not solve enterprise integration. In fact, used badly, it creates a durable mess very quickly.

Common mistakes:

• using Kafka as a replacement for all integration
• publishing events without domain ownership
• no event versioning strategy
• no topic lifecycle management
• turning internal database changes into enterprise events
• letting every team create topics with no naming or governance model
• no clarity on canonical vs domain-specific events

We help organizations structure event architecture around domains and ownership first.

For example:

• Payments domain owns payment lifecycle events
• Customer domain owns customer profile and consent events
• Fraud domain consumes selected events but does not redefine them
• Integration platform team owns Kafka platform operations and standards
• Security and IAM define service identity, access policies, and encryption controls

That sounds basic. But most failures in event-driven architecture happen because the organization skipped this structural work and jumped straight to cluster deployment.

Kafka needs architecture discipline. Without it, you get event sprawl, duplicated semantics, hidden coupling, and impossible-to-govern data movement.

3. IAM as enterprise architecture, not just security tooling

IAM is one of the clearest examples of architecture structure showing up in real life.

A lot of organizations still treat IAM as a security implementation detail. It is not. It is a core enterprise architecture capability because it shapes:

• customer experience
• workforce productivity
• application integration
• zero trust controls
• cloud platform access
• auditability and compliance
• merger and acquisition integration

When we help structure architecture, IAM usually becomes a shared enterprise capability with clear layers:

• identity sources and authoritative records
• authentication services
• authorization models
• federation patterns
• privileged access controls
• service identities for APIs and workloads
• cloud access governance

The mistake architects make is either over-centralizing IAM or under-architecting it.

Over-centralized IAM becomes a bottleneck. Every team depends on one central queue.

Under-architected IAM becomes chaos. Every app invents its own model, and then security tries to retrofit control later.

A better structure is centralized policy and platform foundations, with decentralized consumption through standard patterns.

That is what good architecture looks like in practice: not one team doing everything, but one architecture model enabling many teams to do the right thing consistently.

4. Cloud architecture and platform boundaries

Cloud is another area where structure matters more than slogans.

The phrase “move to cloud” is not architecture. It’s barely a strategy. The real questions are:

• which workloads belong where
• what platform capabilities should be standardized
• how teams consume cloud safely
• where data gravity and latency matter
• how IAM, networking, observability, and cost controls are enforced
• what level of abstraction the platform team provides

Some organizations centralize cloud too much. They create a giant platform team that becomes the only way to deploy anything. Delivery slows, teams get frustrated, and exceptions multiply.

Others decentralize too early. Every team creates its own landing zone, IAM model, monitoring setup, and CI/CD conventions. Then six months later leadership discovers there are twelve ways to do logging and nobody can explain the security posture. EA for cloud migration

We usually recommend a middle path:

• centralize cloud foundations
• standardize guardrails
• offer paved roads
• allow controlled variation at the workload level
• define clear escalation and exception paths

Again, architecture structure is about decision rights and boundaries, not just technical standards.

A real enterprise example: restructuring architecture in a retail bank

Let’s walk through a realistic example.

A mid-sized retail bank had grown through acquisition. It had:

• three digital channels
• multiple customer identity stores
• separate lending and servicing platforms
• fragmented IAM
• point-to-point integrations plus some Kafka adoption
• cloud migration underway, but uneven
• architecture governance seen as slow and mostly theoretical

Leadership’s complaint was simple: “We are spending heavily on technology but still cannot change fast enough.”

Classic situation.

What we found

At first glance, the bank looked like it had an architecture problem of inconsistency. But the deeper issue was structural fragmentation.

Business domain issues

• Customer onboarding was split across branch, call center, and digital teams
• Lending decisions and lending servicing were treated as one domain even though they had very different change patterns
• Fraud was partly embedded in channels and partly centralized
• No clear owner for customer consent and identity lifecycle

Platform issues

• IAM was split between workforce identity, customer identity, and application authentication with little coordination
• Kafka existed as a platform, but event ownership was unclear
• Cloud landing zones existed, but each program had negotiated exceptions
• API standards were published but not tied to delivery controls

Governance issues

• Architecture board reviewed solutions too late
• Exceptions were common and rarely retired
• Standards were broad but not prioritized
• Solution architects spent more time formatting review packs than solving design problems

Very normal. Also very fixable.

What we changed

We did not start by redrawing every system. We restructured the architecture operating model first.

1. Defined domain architecture boundaries

We separated the bank into clear business and technology domains:

• Customer and Identity
• Onboarding and KYC
• Payments
• Lending Origination
• Lending Servicing
• Fraud and Financial Crime
• Channels
• Enterprise Platforms

This sounds simple, but it changed ownership discussions immediately. For the first time, there was clarity on who owned customer profile, consent, authentication touchpoints, and lifecycle events.

2. Clarified enterprise platform capabilities

We designated a small set of enterprise platforms requiring tight architecture control:

• IAM
• Kafka/event streaming
• API management
• cloud landing zones
• observability
• data governance services

Each platform got:

• a product owner
• an architecture owner
• a reference pattern set
• a service consumption model
• a backlog tied to delivery demand

That last part matters. Shared platforms without product thinking become architecture monuments.

3. Reframed Kafka usage

The bank had been using Kafka partly as integration middleware and partly as a strategic event backbone. That ambiguity was causing confusion. integration architecture guide

We defined:

• domain event ownership
• topic naming and lifecycle rules
• event contract standards
• security controls for publishers and consumers using IAM-integrated service identities
• criteria for when Kafka was appropriate versus API or batch

This reduced pointless event proliferation and improved trust in the platform.

4. Re-architected IAM around capabilities, not tools

Instead of debating vendors endlessly, we structured IAM into capability layers:

• customer identity
• workforce identity
• privileged access
• machine/service identity
• authorization services
• federation and trust
• audit and governance

This let different implementation components coexist while still moving toward a coherent target state.

5. Changed governance from review-heavy to decision-focused

We replaced giant architecture review packs with lightweight checkpoints tied to delivery stages:

• early domain fit and platform alignment
• security and IAM pattern choice
• integration and data movement review
• production readiness against guardrails

Fewer meetings. Better decisions. Less theater.

The results

Within 12 months:

• duplicate onboarding integration work was reduced significantly
• IAM patterns for customer-facing applications became consistent
• Kafka topic creation dropped in volume but improved in quality
• cloud deployments aligned more closely to standard landing zones
• architecture exceptions became visible and time-bound
• solution teams engaged architects earlier because the process was actually useful

This is what architecture structure should do. It should reduce ambiguity, improve delivery quality, and give the organization a more coherent path to change.

Not magically. Not perfectly. But materially.

Common mistakes architects make when trying to structure architecture

Let’s be blunt here. Architects create a lot of their own problems.

Mistake 1: Starting with frameworks instead of operating reality

TOGAF, Zachman, capability models, reference architectures — these all have their place. But if you start with the framework instead of the organization’s actual delivery pain, you will build an elegant model nobody uses. building capability maps

Frameworks are tools. They are not the work.

Mistake 2: Drawing target states that ignore transition cost

Architects love end-state diagrams. They are tidy. Real enterprises are not.

A target state that requires ten concurrent transformations, major data migration, process redesign, IAM overhaul, and cloud platform maturity all at once is not a strategy. It’s a wish.

Mistake 3: Treating shared platforms as purely technical

Kafka, IAM, cloud platforms, API gateways, observability stacks — these are not just technical assets. They are organizational capabilities. If they are not funded, owned, and operated like products, they decay or get bypassed.

Mistake 4: Confusing governance with architecture

A review board is not architecture. A standards repository is not architecture. A compliance checklist is definitely not architecture.

Governance should support architecture decisions, not replace them.

Mistake 5: Over-centralizing decisions

Some enterprise architects secretly want every meaningful decision to pass through them. That is not control. That is fragility.

The right model is centralized direction for a small set of critical concerns, with decentralized execution inside clear guardrails.

Mistake 6: Underestimating data and identity

Many architecture teams still focus too much on applications and infrastructure, and not enough on identity and data ownership. That’s backwards. In modern enterprises, identity and data flows shape everything.

Mistake 7: Failing to define what “good” looks like

Architecture principles are usually too vague:

• reuse before buy
• cloud first
• API first
• security by design

Fine. But what do these actually mean in a solution decision?

We help organizations define measurable architecture outcomes:

• reduced domain duplication
• standard IAM adoption rates
• event contract quality
• cloud guardrail compliance
• platform consumption patterns
• exception aging and retirement

If you cannot observe architectural improvement, you probably aren’t improving it.

The uncomfortable truth: some architecture should remain messy for a while

Here’s a contrarian thought that experienced architects usually understand and inexperienced ones hate: not all mess should be cleaned up immediately.

Some legacy systems are ugly but stable. Some duplicated capabilities are temporary but strategically useful. Some manual controls are acceptable until a platform matures. Some cloud migrations should wait. Some IAM consolidation should be sequenced carefully because the business risk of getting it wrong is too high. cloud architecture guide

Architecture maturity is partly about knowing where to tolerate imperfection.

This is where real architect judgment matters. Not every inconsistency is a crisis. Not every standard deserves enforcement. Not every modernization move is wise just because it sounds modern.

You do not get points for replacing a stable core process with a fashionable distributed design that increases operational complexity and weakens auditability.

Especially in banking.

Architecture is not about making the estate look modern. It is about making the enterprise more viable.

What good architecture structure looks like

By the time architecture is well-structured, you can usually see a few clear characteristics.

Clear ownership

Business domains, data, platforms, and exceptions all have named owners.

Simple decision paths

Teams know which decisions they can make, which require alignment, and how to get exceptions quickly.

Shared capabilities treated as products

IAM, Kafka, cloud foundations, and observability are consumable services, not vague central functions.

Lightweight but real governance

Architecture controls focus on material risks and strategic fit, not endless review rituals.

Transition states are explicit

The organization knows what is target, what is tolerated, what is legacy, and what is being retired.

Architecture connected to delivery

Reference patterns, backlog planning, funding decisions, and engineering controls all reinforce the architecture.

That’s the point. Architecture should be felt in execution, not just seen in diagrams.

Final thought

If an organization’s architecture is unclear, the business pays for it everywhere: slower delivery, duplicated platforms, security gaps, brittle integrations, IAM confusion, cloud sprawl, and endless arguments about standards.

So when we help organizations structure their architecture, we are not trying to produce a prettier enterprise repository. We are trying to create a system of decisions and ownership that helps the enterprise change with less friction and less risk.

That means being practical. Sometimes blunt. Sometimes unpopular.

Because good architecture is not the art of describing complexity. It is the discipline of reducing unnecessary complexity without lying about what remains.

And yes, that is harder than making slides.

FAQ

1. What does it mean to structure enterprise architecture?

It means defining how architecture is organized across business domains, shared platforms, solution delivery, governance, and decision rights. In practice, it clarifies ownership, standards, target states, and how delivery teams make technology decisions.

2. How is enterprise architecture structure different from governance?

Governance is the control mechanism. Architecture structure is the design of ownership, boundaries, platforms, and decision models. Good governance supports that structure. Bad governance tries to replace it with meetings and checklists.

3. Where should organizations start: applications, business capabilities, or technology platforms?

Usually with business domains and capability ownership, then shared platforms, then application rationalization. Starting with applications alone often leads to local optimization and misses the structural causes of complexity.

4. How do Kafka and event-driven architecture fit into enterprise architecture?

Kafka should be treated as a shared integration and event platform with clear domain ownership, security controls, lifecycle policies, and usage criteria. It is not a universal replacement for APIs, batch, or operational workflows.

5. Why is IAM such an important part of enterprise architecture?

Because IAM affects customer journeys, workforce access, cloud controls, API security, auditability, and operational risk. It is not just a security toolset. It is a foundational enterprise capability that shapes how systems and people interact across the estate.

Frequently Asked Questions

What is enterprise architecture?

Enterprise architecture is a discipline that aligns an organisation's strategy, business processes, information systems, and technology. Using frameworks like TOGAF and modeling languages like ArchiMate, it provides a structured view of how the enterprise operates and how it needs to change.

How does ArchiMate support enterprise architecture practice?

ArchiMate provides a standard modeling language that connects strategy, business operations, applications, data, and technology in one coherent model. It enables traceability from strategic goals through business capabilities and application services to the technology platforms that support them.

What tools are used for enterprise architecture modeling?

The main tools are Sparx Enterprise Architect (ArchiMate, UML, BPMN, SysML), Archi (free, ArchiMate-only), and BiZZdesign Enterprise Studio. Sparx EA is the most feature-rich option, supporting concurrent repositories, automation, scripting, and integration with delivery tools like Jira and Azure DevOps.