TL;DR
- Dependencies — not tools — define how fast an organization can change
- Standardized core systems (CRM, billing, ERP) reduce complexity but can create systemic risk
- Capability-based decomposition enables autonomy and limits harmful dependencies
- Speed is an architectural outcome, shaped by boundaries, ownership, and governance
Most organizations believe their speed is determined by:
- Technology choices
- Team capacity
- Budget
- Tooling
In reality, something else has far more influence:
Dependencies.
Who depends on whom.
Which systems rely on which data.
Which teams must coordinate to deliver value.
This is the hidden architecture that controls your pace of change.
And in many organizations, it is shaped by a few central platforms.
Often: one CRM, one billing system, and one ERP.
Dependencies Are Architecture — Whether You Design Them or Not
Every organization has an architecture.
Some design it deliberately.
Others let it emerge through:
- Historical decisions
- Vendor lock-in
- Emergency fixes
- Local optimizations
In both cases, dependencies form the real structure of the enterprise.
They determine:
- Who can move independently
- Who must ask for permission
- Where change gets stuck
And they rarely appear in official diagrams.
Why Dependencies Kill Momentum
Unmanaged dependencies create friction everywhere.
1. Slow Delivery
When many teams must align to release one feature, velocity collapses.
Planning becomes negotiation.
2. Fragile Systems
Changes ripple across platforms.
Small updates become high-risk deployments.
3. Bottlenecks and Gatekeepers
A few critical systems or teams become unavoidable chokepoints.
Everything waits.
4. Innovation Paralysis
Experimentation becomes expensive.
Failure becomes dangerous.
So teams stop trying.
The Platform Dependency Trap
Over time, the same patterns repeat.
Shared Core Systems
One CRM.
One billing platform.
One ERP.
One integration hub.
Used by everyone.
Owned by no one.
Centralized Data Ownership
All analytics depend on one team.
All insights wait in one queue.
Platform Without Product Thinking
“Internal platforms” with no roadmap, funding, or accountability.
Integration Spaghetti
Point-to-point connections multiplied over years.
No one fully understands the landscape.
What started as simplification becomes structural complexity.
Why Organizations Choose One Core Platform Per Domain
The rationale is usually sound.
Organizations aim for:
- Cost efficiency
- Data consistency
- Process standardization
- Easier compliance
- Operational simplicity
Across customer, revenue, and operations.
From a governance perspective, this looks like maturity.
And in many contexts, it is.
At first.
Standardization Solves Real Problems
It is important to be clear:
Choosing one CRM, one billing system, and one ERP is often the right decision.
Standardization reduces several very real forms of complexity.
It Reduces Technical Fragmentation
Fewer platforms mean:
- Fewer integrations
- Fewer data models
- Fewer interfaces
- Fewer security surfaces
This lowers operational risk.
It Simplifies Governance
With unified core systems:
- Policies are easier to enforce
- Compliance is easier to audit
- Controls are easier to maintain
This matters in regulated environments.
It Improves Data Quality
Clear systems of record reduce:
- Duplicate customers
- Conflicting invoices
- Inconsistent financial reporting
Trust in data increases.
It Enables Scale Efficiency
Shared platforms enable:
- Centralized operations
- Shared support
- Volume-based vendor leverage
Cost per transaction decreases.
In many organizations, consolidation is a necessary step toward maturity.
Why Decompose by Capabilities
If dependencies define speed, then capability design defines structure.
Decomposing the enterprise by business capabilities is one of the most effective ways to manage complexity.
Capabilities represent:
- What the organization does
- Independent of systems
- Stable over time
- Owned by the business
They form a natural foundation for architecture.
Capabilities Create Clear Boundaries
- Responsibilities are explicit
- Ownership is clear
- Interfaces are intentional
This reduces accidental coupling.
Capabilities Enable Autonomous Change
Domains can evolve independently.
Local change stays local.
Capabilities Connect Strategy to Delivery
Strategy becomes:
- Capability investments
- Roadmaps
- Platform decisions
Without losing meaning.
Capabilities Support Platform Decoupling
CRM, billing, and ERP become service providers.
Not power centers.
When Standardization Becomes a Strategic Constraint
Over time, new realities emerge.
Everything Depends on Everything
Products, channels, and markets become tied to the same backbone.
Innovation Must Fit the Core
If it doesn’t, it waits.
Or dies.
Customization Explodes
Exceptions multiply.
Standardization erodes silently.
Vendor Lock-In Increases
Strategic freedom decreases.
Negotiation power weakens.
The platforms start shaping strategy.
Dependencies vs. Capabilities
One of the most common mistakes is confusing:
Capability ownership with system ownership.
Capabilities are end-to-end.
Systems are assets.
When capabilities depend on too many platforms, autonomy disappears.
And speed follows.
How High-Performing Organizations Manage Dependencies
Fast organizations are dependency-aware.
1. Make Dependencies Visible
Map:
- Systems
- Data
- Integrations
- Teams
Continuously.
2. Design for Loose Coupling
- APIs and events
- Stable contracts
- Clear domains
Change becomes local.
3. Align Architecture and Operating Model
Ownership is unambiguous.
Coordination is minimized.
4. Run Platforms as Products
CRM, billing, and ERP have:
- Owners
- Roadmaps
- Funding
- Metrics
5. Govern Dependencies Explicitly
Ask:
- Does this create new lock-in?
- Can it be reversed?
- Who owns the impact?
A Pattern I’ve Seen Repeatedly
Organizations start with:
“One system per domain.”
They end with:
“One backbone controlling everything.”
Each project adds:
- Integrations
- Exceptions
- Dependencies
Until change becomes surgery.
The Architect’s Real Responsibility
Architecture is not about diagrams.
It is about shaping dependencies.
Every decision answers:
- Who can move?
- Who waits?
- Who decides?
- Who carries risk?
If you don’t decide, the organization will.
Practical Starting Points
Map Critical Dependency Chains
Across value streams, platforms, and teams.
Find Structural Bottlenecks
Where work consistently waits.
Reduce One Major Dependency at a Time
Target the biggest constraint.
Strengthen Contracts
Stabilize interfaces and data semantics.
Predictability builds trust.
Speed Is an Architectural Outcome
Organizations don’t become slow by accident.
They become slow through unmanaged dependencies.
Often embedded in core platforms.
Speed comes from:
- Clear boundaries
- Intentional coupling
- Accountable ownership
- Thoughtful governance
That is architecture’s real impact.
If your transformation feels stuck, look at your dependencies. They usually tell the real story.