When assessing approaches to complex transformation projects, an emerging view is that the business should lead, often holding final decision authority across the full transformation effort. The intent is understandable; outcomes should drive investment, not the other way around. But in practice, that position often collides with a harsher reality: when your systems are architecturally entangled, every “business-led” decision becomes an IT crisis. The reverse is also true: every IT stabilization effort feels like it is blocking the business.
Two shorthand terms first. BSS (Business Support Systems) here refers to systems like Customer Relationship Management (CRM), Configure Price Quote (CPQ), and Commercial Order Management (COM). OSS (Operations Support Systems) refers to “Back Office” or operational systems such as inventory, provisioning, and Service Order Management (SOM). These acronyms come from the Telecommunications Industry, but the same patterns often show up across Media, Energy, Hi-Tech, Med-Tech, and other equally complex industries. The connective tissue is complexity: anywhere systems have grown tangled over time.
Before we look deeper into the reasons for this potential control struggle, it is important to ask a few direct questions:
- When product or commercial teams change an offer, does the work effort have cascading repercussions across BSS (CRM, CPQ, COM) and OSS (inventory, provisioning, SOM) systems in ways nobody can fully predict?
- When IT stabilizes a platform or fixes integration behavior, does the business still get surprised by fallout, delays, or “we can’t launch that until…”?
- Are teams ever tempted to explain missed dates and rising frustration as “culture” or “alignment,” when the deeper pattern is everything touches everything?
If any of that sounds familiar, we might not be dealing with a motivation problem first. The culprit is more likely embedded in the architecture itself, with roots in a lack of separation of concerns that lets decisions in one domain reshape the behaviour of another.
The argument here is not that the business should abdicate strategy. It is that debating who “leads” is a distraction until boundaries are real. What matters is not a hierarchy as much as shared outcomes, clear domain ownership, and interfaces that stop constant mutual disruption.
When architecture makes every change someone else’s problem
In complex BSS and OSS environments, often those built on applications that have been stitched together by ecosystem vendors with heavy integration logic, constant data syncing is the norm. This is where improper separation of concerns shows up as an operational reality: product truth, order processing logic, fulfillment state, and billing configurations get duplicated, partially synchronized, or reconciled late. Changes that look small on a roadmap (“add a bundle,” “run a promotion,” or “bulk equipment upgrade”) propagate through layers that were never designed to accommodate change.
In that world, change on the business side carries real cost for IT, and change on the IT side also carries real cost for the business. That is not a failure of “culture” or “alignment.” It is architectural coupling showing up as organizational friction.
By instinct, transformation teams push back because it helps them manage risk. Timelines slip because regression testing and integration cycles balloon. Legacy platforms become load-bearing because replacing one thing has myriad implications across the ecosystem. All of this gets framed as resistance and alignment. In reality, architectural entanglement is what turns any suggestion of collaboration into caution.
Why “business in charge” scares IT when the architecture is entangled
If the business is formally “in charge” while the stack is tightly coupled, IT is asked to absorb liability without containment. A priority is not just a requirement, it is a cascade of work across systems, integrations, and operations. IT is not irrational to flinch; they are estimating the cost.
That is why cooperation matters: it works better when accountability matches control. If business decisions keep reshaping IT’s domain because the architecture has no separation of concerns, “partnership” collapses into finger-pointing when releases go wrong.
What “good” looks like: disentangle, then empower
The remedy is not two silos operating as if they do not need each other. It is disentanglement with explicit collaboration:
- Own domains, not each other’s work. Commercial and customer-facing truth should live in a well-defined commercial layer; technical and service fulfillment truth should live where it belongs, with clear rules for where each source of truth lives and how changes are staged. As a simple example, we have repeatedly seen commercial product catalogs expose technical attributes to CSRs (customer service reps), overwhelming them and generating fallout downstream in the OSS layer.
- Master data and rules where they belong. Duplicated validation and “fix it in the integration layer” are warnings that separation failed. Integration should connect domains, not hide contradictory logic. In that same architecture, the commercial catalog itself lived in the OSS layer, forcing repeated heavyweight syncing to push commercial configurations into every system that needed it, including the CRM.
- Interfaces, not accidents. When boundaries are explicit, a change is something that can be readily scoped, tested, and communicated, and has predictable outcomes.
Done well, business and IT still argue about priorities. That is healthy. What changes is the kind of argument: trade-offs (speed, cost, risk, customer impact), not uncertainty about what a change might break elsewhere.
Of course, none of this is easy. Nobody replaces an entangled architecture in one release. It happens incrementally, one piece at a time, over years, while the business keeps running and customers keep being served. That is the actual job.
Shared goals without shared chaos
This is also where classic program discipline pays off. Goals, mobilization, documentation, governance, and change management are all part of what “business-led” thinking correctly emphasizes, and they still matter. What changes is that they work best as a joint operating model, not as one function overriding another.
A practical pattern:
- Joint outcomes that include operability: a release is not a success if the business and IT cannot both iterate independently afterward.
- Early feasibility as a strategic input, not late-stage pushback. Technical constraints shape what can be realistically achieved.
- Governance with decision rights for where domains meet: who decides when commercial definitions and service definitions disagree, and how do you stop “temporary” exceptions from becoming permanent coupling?
The one-line thesis
Arguments about who should “lead” often ignore the real issue: a tangled architecture forces business and IT into each other’s way. Cooperation becomes workable when separation of concerns is achieved, so each side can lead its own domain with clarity, align on shared objectives, and meet at boundaries.
If that pattern sounds familiar, the more useful question is not who leads, but where in your own architecture does change on one side still carry unpredictable cost on the other? That is usually where the real work starts: disentangle first, then empower each side to lead its own domain with clarity.
If that resonates, reach out to Ateko to continue the conversation.
