Why one team owning everything—from design to operations—can undermine infrastructure excellence

Let’s start with a scenario many of us might recognise (or perhaps tolerate): You’re working in a hypothetical organisation where the entire infrastructure lifecycle—from architecture and design, through procurement and build, all the way to operations and support—is managed by one single unit. Sounds efficient, right? One team, one chain of command, one budget. But as we’ll explore, this setup often breeds hidden inefficiencies, risk accumulation, and missed potential for strategic value.

The “one-unit” model and why it seems attractive

In this model, the infrastructure team is responsible for everything:

• They design the network, data centres, cloud/on-premise mix, security, storage, and compute.
• They budget for it, procure hardware/software, hire vendors, and integrate systems.
• They then hand off (or sometimes keep) operations: monitoring, patching, support, and incident management.
• They may also report to one senior leader (CIO/CTO) and use a single budget envelope.

On paper, this seems clean: single accountability, minimal hand-offs, one org chart. For smaller organisations, this may work. But as scale, complexity, regulatory demands, hybrid architectures, and cloud models increase, this monolithic model starts to crack.

The gaps that emerge when engineering+design+operations are lumped together

Here are several concrete issues you’ll see when one unit tries to cover end-to-end without specialised, segregated roles for architecture, engineering/design, and budgeting/portfolio governance:

1. Lack of long-term standards and architecture governance: When the same team both designs and operates, it tends to optimise for “what works now” rather than “what sustains for tomorrow”. Without a dedicated architecture function setting technology standards and anticipating lifecycle replacement, you get a patchwork environment: multiple vendors, inconsistent configurations, variable security postures. Research shows that infrastructure architecture standards are best managed via a central architecture team with governance and inter-unit coordination.
2. Budgeting and cost visibility suffer: If engineering/design and operations budgeting are embedded in the same unit, you often lose visibility into investment vs. run-cost trade-offs. Because build and run are not clearly separated, you may budget for ‘everything’ but lack insight into which infrastructure is business-critical, which is legacy drift, and which should be sunset. The “plan-build-run” model described by McKinsey & Company shows that when functions are technology-tower-based, there is duplication and costs creep.
3. Engineering/design capability gets crowded out by operational firefighting: When one team handles both, operations (incidents, support, maintenance) often dominate—the architecture/design agenda slides to the back seat. Innovation, future-proofing, performance tuning, and standardisation become lower priorities.
4. Siloed technical stacks and vendor lock-in proliferate: Because the team may default to “what we can deploy fastest” rather than “what fits into a long-term architecture,” you end up with heterogeneous stacks. This multiplies support burden, integration complexity, and cost. Standardisation pays off: the literature states that organisations benefit from architecture teams that define standards and manage their enforcement.
5. No independent check on whether design decisions align with business strategy: If the unit designing infrastructure also controls its own operations and budget, there’s less incentive or structural mechanism for independent challenge: Are we investing in the right platform for future growth? Are we choosing the right cloud/on-prem mix? Are we making the right trade-offs between CapEx and OpEx? Without separate architecture/portfolio governance, those questions often remain unasked.

Why you should have a dedicated unit for Infrastructure Architecture & Standardisation

Given these gaps, here’s why I strongly recommend organisations establish a separate unit (or chapter) charged solely with infrastructure architecture, design standards, technology standardisation, and long-term platform planning:

• This unit defines the technology standards, reusable platforms, reference architectures, vendor-strategy roadmap, and lifecycle governance.
• It works across delivery, build, and run teams: it does not own day-to-day operations, but governs them.
• It sets and enforces standards, e.g., “All compute platforms will fit into our hybrid-cloud reference model,” “Network security must follow our standard micro-segmentation architecture,” or “All storage refreshes must align with our modular rack design and vendor pricing strategy.”
• It aligns infrastructure strategy with business strategy and translates business needs (scale, global expansion, regulatory changes) into technology platform choices.
• It ensures budgeting is forward-looking: distinguishing capital investments for growth/refactoring vs operational costs for running existing platforms.

Research supports this model: “Crafting the optimal model for the IT architecture organisation” shows that organisations benefit from a function that defines reusable assets, shared patterns, and an enterprise-wide architecture language. Without it, infrastructure decisions become tactical, fragmented, and short-sighted.

Example of a real-world organisation doing it right

One actual example: a large regulated organisation (for confidentiality reasons not named) migrated to a “plan-build-run” infrastructure organisation design. The “plan” function required management and product management of infrastructure services. The “build” function did platform engineering and deployment. The “run” function performed operations. This enabled more transparent budgeting, fewer silos, and faster deployment of integrated services across technology domains.

Another example: many banking and financial services firms have carved out a central Enterprise Architecture/Infrastructure Architecture team that sets standards across the business units. At the same time, business-unit IT operations manage implementation and runtime support.

The human side: bridging engineering, operations, and strategy

Let’s shift from organisational charts to people, because ultimately this is about humans, not boxes. If you are the leader of an infrastructure function and you find that your team is constantly firefighting—deploying new sites, patching servers, responding to incidents—yet you rarely have time to design the “platform of the future”, then you likely need architecture separation. Conversely, if the architecture/design team is too distant from operations, you risk producing beautiful standards that nobody implements.

The sweet spot: a design/architecture team that is connected to operations (via metrics, accountability, dashboards) but distinct from it in its mission. The architecture group becomes the steward of technology standardisation, lifecycle planning, and vendor strategy; the operations group remains the executor of safe, secure, cost-efficient run-time. Engineering/design teams focus on building new capabilities and delivery.

So, what should you do (if you’re advising or working in infrastructure)?

Here’s your to-do list:

• Assess current structure: Who designs technology? Who budgets it? Who runs it? Are those the same team or separate?
• Map your gaps: Are you facing duplicated vendor/supplier contracts, heterogeneous stacks, high support costs, or a lack of a roadmap?
• Define an architecture unit: Charter a team (or chapter) whose purpose is to define technology standards, architecture governance, vendor strategy, platform lifecycle, and budget roadmap.
• Separate budgeting and accountability: Give this architecture unit authority over vendor standards and long-term investment decisions; operations own cost control and service delivery.
• Create metrics and incentives: Set architecture KPIs (e.g., % of infrastructure deployed via standard reference architecture, % of legacy platforms retired, vendor consolidation ratio) and make operations report to service-delivery KPIs (uptime, cost per user, mean time to repair).
• Ensure collaboration: Architecture must work with (not above) engineering and operations. Joint forums, standards adoption reviews, shared dashboards.
• Communicate to stakeholders: Business leadership must understand: standardised infrastructure doesn’t mean “slow” or “limited” — it means “built for scale, cost-efficient, future-ready”.

Final thought

In a business era driven by agility, cloud, regulatory complexity, and global scale, infrastructure is no longer a cost-centre; it’s a strategic asset. Organisations that treat it as a tactical, one-team job risk accumulating debt, duplication, and fragility. By establishing a dedicated architecture/standardisation function, you not only reduce inefficiency and risk — you unlock the possibility that infrastructure becomes an enabler of growth, not just a back-office utility.

If your organisation’s infrastructure team is juggling design, build, operations, budgeting, and vendor management all at once, take a step back. You might just find that the best way to move faster is to insert the right specialist unit in the chain.

Looking forward to your thoughts—do you see this in your own environment? Where is the biggest bottleneck between design and operations in your infrastructure organisation?

Footnotes / References:

1. Effective management of information systems architecture standards: an intra-organization perspective. ResearchGate.
2. Using a “plan-build-run” organisational model to drive IT infrastructure objectives. McKinsey & Company.
3. Crafting the optimal model for the IT architecture organisation. McKinsey & Company.