Five organisation-level patterns cover almost every mid-market integration decision: layered, segmented, cell-based, podular, and socio-technical/iterative. For most mid-market organisations wrestling with legacy systems and fragmented teams, cell-based architecture paired with a podular operating model gives the best balance of speed and control. Here's the quick verdict:
- Layered — simple to govern, but slows down as the organisation scales. Best for early-stage integration with a small IT team.
- Segmented — clear ownership by business domain, but risks duplicated effort. Best for organisations with distinct, semi-autonomous divisions.
- Cell-based — modular, reusable, built for change. Best for mid-market firms modernising legacy estates incrementally.
- Podular — decentralised delivery with shared standards. Best for organisations with mature engineering capability and a need for pace.
- Socio-technical/iterative — integration built around stakeholder buy-in, not just systems. Best for change-sensitive environments (mergers, culture shifts, regulated sectors).
Key Takeaways
Cell-based architecture combined with podular teams gives most mid-market organisations the best balance of modernisation speed and governance control.
| Point | Details |
|---|---|
| Match pattern to legacy shape | Heavy legacy debt favours cell-based; lighter estates can move straight to podular. |
| Adjust all three PPT elements | Changing technology without adjusting people and process wastes most of the gain. |
| Pilot before scaling | Test one pattern in one function for several weeks before committing budget. |
| Keep governance light | A federated registry and clear decision rights beat a heavyweight approval process. |
| Map before you build | Oakandnine's live organisational mapping shows real workflows before you choose a pattern. |
Table of Contents
- What are the main integration architecture patterns?
- What changes in people, process and technology for each pattern?
- How do you choose the right pattern for your organisation?
- What does a practical implementation roadmap look like?
- What does integration maturity actually look like?
- How does Oakandnine help you apply these patterns?
- Ready to pilot your integration approach?
- Sources
What are the main integration architecture patterns?
Each pattern answers a different organisational question: who owns what, how fast can we move, and how much risk are we prepared to carry during the transition.
Layered integration stacks capability in tiers, presentation, process, data, with each layer talking only to the one below it. It's the pattern most legacy-heavy organisations already have, whether they designed it deliberately or not.
- Pros: predictable governance, easy to audit, low skills barrier to entry.
- Cons: change in one layer ripples upward, slow to adapt, tends to concentrate decision rights in IT.
- Choose it when: your estate is small, your regulatory obligations are heavy, and pace of change is low.
Segmented integration divides the organisation by business domain, finance, HR, operations, each with its own integration boundary.
- Pros: clear accountability, less cross-team contention, easier to scope projects.
- Cons: duplicated logic across segments, harder to get a single view of the business, coordination costs rise as segments multiply.
- Choose it when: divisions genuinely operate as separate businesses with limited shared workflow.
Cell-based architecture breaks the organisation into self-contained cells, each owning a slice of functionality that can be built, deployed and reused independently. The WSO2 reference methodology for integration agility frames this as the natural target state for organisations progressing beyond layered or segmented setups, because cells let teams modernise legacy functions piece by piece rather than in one disruptive event.
- Pros: incremental modernisation, reusable components, decentralised ownership without chaos.
- Cons: needs disciplined API standards, initial setup cost is higher, easy to under-govern if left unchecked.
- Choose it when: you're modernising a brownfield estate and can't afford a full replatform.
Podular organises delivery teams (pods) around outcomes rather than technology layers, each pod owning a service end to end.
- Pros: fast delivery, strong ownership, less handoff friction.
- Cons: requires mature engineering skills, can fragment standards without a light governance layer.
- Choose it when: your teams already ship independently and need integration to match that pace.
Socio-technical/iterative integration treats the people and process side of the change as seriously as the technical build, running short cycles of design, pilot and feedback rather than a single cutover. Four integration patterns research from ECIS distinguishes this from "Big Bang" delivery: early stakeholder integration raises the odds of success but adds coordination complexity you need to plan for.
Pro Tip: Don't pick a pattern in isolation. Most mid-market organisations end up running two at once, cell-based for the technology estate, socio-technical for how change gets rolled out to people.
What changes in people, process and technology for each pattern?
The People, Process, Technology framework makes a blunt point: change one of the three without adjusting the other two, and you lose most of the benefit to friction. Here's what each pattern actually demands.
- Layered — People: IT retains most decision rights. Process: change requests move through a central queue. Technology: stable APIs between layers, minimal event-driven complexity.
- Segmented — People: domain leads gain decision authority. Process: SOPs diverge by segment, requiring translation at the edges. Technology: domain-specific data stores, shared identity and access layer.
- Cell-based — People: teams need API design skills, not just domain knowledge. Process: change cadence shortens to weekly or fortnightly releases. Technology: service contracts, event streams, and a lightweight registry of what each cell exposes.
- Podular — People: pods need product-owner style accountability. Process: governance shifts from approval gates to shared standards. Technology: self-service deployment pipelines.
- Socio-technical — People: named sponsors across functions, not just IT. Process: iterative cycles of design, pilot, and re-evaluation, as described in the ORGTECH integrated organisational and technology development study. Technology: built incrementally alongside the org design, never ahead of it.
Pro Tip: Run a two-week "shadow governance" test before committing, let a pilot pod operate under the new decision rights without formal sign-off, and see where friction actually shows up.
How do you choose the right pattern for your organisation?
Work through this in order:
- How much legacy debt do you carry? Heavy legacy points towards cell-based; light legacy opens up podular sooner.
- Where does your data gravity sit? If most data lives in one core system, segmented integration will create duplication, favour layered or cell-based instead.
- What's your regulatory exposure? Regulated functions need the traceability layered integration provides, even if other parts of the business move to cell-based.
- How fast does the business need to change? Slow, stable environments tolerate layered. Fast-moving markets need podular or cell-based.
- What skills do you actually have? Podular fails without engineering maturity across teams, not just in a central group.
Red flags that suggest a poor fit: a single vendor controls your core data model (blocks cell-based), one team holds all integration knowledge (blocks podular), or leadership wants decentralised delivery without funding a governance layer to match.
Before committing to scale, run a bounded pilot: one business function, one integration pattern, a four-to-six-week window, and a clear success metric agreed upfront.
What does a practical implementation roadmap look like?
A six-step path takes most mid-market organisations from decision to production without a disruptive Big Bang cutover.
- Assess — map current systems, decision rights and process bottlenecks. Two to three weeks.
- Design — choose the pattern (or combination) and define the target operating model.
- Pilot — implement in one function or business unit, with real users and real data.
- Iterate — revise based on pilot feedback; the ORGTECH project found these cycles of analysis, co-design and re-evaluation are what actually manage the human side of change.
- Govern — set the lightweight rules (API standards, decision rights, escalation paths) before scaling.
- Scale — extend to further functions, using the pilot's metrics as the baseline.
A typical mid-market pilot runs for several weeks; scaling across multiple functions usually takes a further few months. Effort and cost are driven mainly by data quality, the number of legacy systems involved, and how many teams need new decision rights.
Track a small set of metrics: process cycle time (before and after), error or escalation rate, adoption rate among target users, and hours saved per week. Keep the measurement simple, a spreadsheet tracking these four numbers weekly beats a dashboard nobody checks.
What does integration maturity actually look like?
Most organisations sit somewhere on a five-stage path, and knowing your stage tells you what to measure next.
| Stage | What's typical | What to measure |
|---|---|---|
| Siloed | Point-to-point connections, manual handoffs | Number of manual handoffs per process |
| EAI (layered) | Central integration layer, batch updates | Time to deliver a new integration request |
| API-driven | Reusable APIs, some self-service | Percentage of integrations reused vs rebuilt |
| Cell-based | Modular cells, teams own services | Time to modernise one legacy function |
| Continuous agility | Podular teams, event-driven by default | Lead time from idea to production |
A maturity model like WSO2's recommends podular teams as the organisational counterpart to cell-based technology, decentralising delivery while cells preserve reuse and standards.
Governance should stay light: a federated registry of who owns what, a small set of API standards, and clear decision rights for cross-cell changes. A centre-of-excellence works well early, when few teams have integration skills. Once three or more teams are shipping independently, a heavy CoE becomes the bottleneck it was meant to prevent.
How does Oakandnine help you apply these patterns?
Oakandnine builds a live model of your organisation rather than a static diagram, mapping people, process and systems together so the pattern you choose reflects how work actually happens, not how the org chart says it should.
- Live organisational mapping — see decision rights, workflows and system dependencies in one connected view.
- Integration orchestration — connect existing systems without a full replatform.
- Bottleneck detection — surface where handoffs stall before they become escalations.
- Real-time insights and alerts — flag process drift before it compounds.
Typical engagements start with a scoped pilot: one function, a handful of systems, measured against cycle time and escalation reduction over several weeks. Full case studies and client results are published as engagements complete.
The pattern matters less than the fit between pattern and organisation. A cell-based architecture bolted onto a team with no delivery capacity fails just as badly as a layered system forced onto a fast-moving business.
Ready to pilot your integration approach?
There's a lower-risk way to test a pattern before committing budget to a full rollout. A pilot with Oakandnine typically covers one business function, a defined set of systems, and a fixed measurement window, so you see real cycle-time and escalation data before deciding whether to scale.
A sample pilot brief you can adapt internally: two to three connected systems (say, HR and finance), a named sponsor from each function, and success metrics agreed upfront, cycle time reduction, fewer manual handoffs, faster reporting. Most pilots run within a fixed timeframe, with pricing scoped to the systems and functions involved rather than a blanket enterprise fee.
If you're weighing up a layered fix against something more structural, the fastest way to find out which fits is to map your organisation first. Visit Oakandnine to scope a pilot conversation and get a clear view of where your current integration approach is costing you time.
A brief note on what actually works
Two cautions worth carrying into any integration decision. First, don't lead with technology, organisations that pick a pattern before mapping decision rights end up retrofitting governance onto a system that wasn't built for it. Second, don't centralise decision-making faster than you build delivery capacity to match; a strong centre-of-excellence with no pods able to execute just creates a queue.
What works instead: short feedback loops (weekly, not quarterly), metrics visible to the whole team rather than locked in a leadership dashboard, and a named sponsor from outside IT for every pilot. Mid-market transformations succeed or stall on that last point more often than any technical decision.
Sources
- People, Process, Technology (PPT) — Prosci blog
- WSO2 reference methodology for integration agility (reference‑methodology.md)
- Integrated organisational and technology development (ORGTECH project) — Journal of Universal Computer Science