The Age-Old IT vs OT Debate: Who gets the Keys to Your OSS?

For decades, organisations have argued over whether IT or operations (OT) teams should control the OSS environment, as though it’s a binary decision. Giving one team control of an OSS may appear to create clear accountability.

But, like so much in OSS, the decision is far more nuanced. Ask who owns your OSS and you might hear the name of a department (though it might be a different name depending on who you ask).

However, ask who selects the OSS product, controls its configuration, governs its data, approves changes and owns the operational outcome, and the answer becomes much less clear.

That’s because OSS ownership isn’t a single responsibility, and the most appropriate demarcation point may change depending on the system, process or decision involved.

Inventory data, for example, is a key building block on which many other OSS systems and processes depend, making its governance a particularly important consideration. Fulfilment and assurance introduce their own questions about configuration authority, process control and operational accountability.

Rather than asking whether IT or OT should hold all the keys, organisations need to decide which keys exist, who should hold each one and what happens when responsibilities overlap or fall through the gaps.

.

Why isn’t IT vs OT a binary decision?

The Generic Data Flows diagram below helps to illustrate why there’s rarely one obvious boundary between IT, OT, systems teams and network teams.

The diagram shows

1. The TMN Pyramid as a background concept to build the story around
2. Assurance information moving upwards from network events and alarms towards enriched problems, incidents and notifications
3. Fulfilment moves in the opposite direction, translating service orders into network provisioning commands and work orders
4. Inventory sits between these flows and receives information from discovery, as well as manual, automated or scripted design / planning / capacity / asset-lifecycle inputs. This makes inventory data an important dependency for many related systems and operational processes.

The diagram doesn’t prescribe an organisational structure, but it does highlight the problem with treating IT versus OT as a single horizontal line. The appropriate boundary may be different for the application platform, its data, its configuration, its workflows and the operational outcome it supports.

.

Where do organisations draw the line?

Different organisations divide OSS responsibilities in different ways.

In one model, IT selects, hosts, secures and maintains the OSS platform, while operations configures and uses it.

In another, a central OSS team owns the applications, while network-domain teams own the technology-specific data, models, rules and configurations.

Some organisations divide responsibility according to the technology stack. Others organise around end-to-end processes such as assurance, fulfilment or inventory management. Some use a federated model in which platform, process, domain and data owners each hold part of the responsibility.

Data can be a difficult demarcation point, as OT would have all the operational knowledge and context of what the OSS data means, whilst IT manages data science, backups, migration, data fix and more.

Each model has strengths and weaknesses. Centralising control can improve consistency, security and lifecycle management, but it can also separate decision-making from the people who best understand the network. Distributing control can improve speed and domain alignment, but may create configuration drift, duplicated capabilities or inconsistent data practices.

The better question isn’t simply, “Should IT or OT own the OSS?” It’s, “Which responsibilities are we assigning, and what knowledge, authority and risk are attached to each one?”

.

What does “owning the OSS” actually mean?

Ownership can refer to many different things:

• Selecting and procuring the product
• Funding it and managing its lifecycle
• Hosting, administering, securing, patching and upgrading it
• Configuring service models, rules, workflows and integrations
• Designing data models (eg network hierarchy models, templates, etc)
• Controlling network-facing configuration
• Using the system from day to day
• Defining and governing its data
• Approving and validating changes
• Remaining accountable for service and network outcomes

These responsibilities don’t necessarily belong to the same team.

For example, the team that administers an inventory platform may not have the domain knowledge to define network-resource models. The team that understands those models may not have the authority or ability to set enterprise data standards. The people who use the inventory every day may identify data-quality problems, but lack the access or resources to correct their causes.

Who defines which inventory data is authoritative? Who owns the reconciliation rules? Who decides how intended state and observed state should be handled when they don’t match? Who’s accountable when poor inventory data causes a fulfilment failure or slows an assurance investigation?

Those questions show why application ownership and data ownership shouldn’t be treated as the same thing.

.

Do the same boundaries work for every OSS subsystem?

The right division of responsibility may also change across inventory, assurance, fulfilment and orchestration.

Inventory raises questions about data authority, modelling standards, discovery, reconciliation and data quality.

Assurance raises different questions. Who controls telemetry collection, event rules, alarm enrichment and correlation logic? Who decides when a network event becomes an operational incident? Who’s responsible for the speed and quality of the response?

Fulfilment introduces another set of responsibilities. Who defines service intent? Who owns the workflow and automation logic? Who approves network-facing changes? Who validates that the requested service outcome was achieved?

Orchestration may span all of these domains, creating further questions about who owns the end-to-end process when several teams control individual steps.

That’s why a responsibility model that works for one OSS subsystem may not work for another. The required knowledge, authority and operational risk aren’t always the same.

.

What happens when the boundaries are wrong?

Poorly defined demarcation points can create duplicate tools, configuration drift, conflicting sources of truth and unclear change-control processes.

They can also create teams that are accountable for outcomes but lack the authority to make changes, or teams that have broad system access without enough operational knowledge to understand the consequences.

In inventory, unclear responsibility can lead to poor data quality that affects fulfilment, assurance, planning, reporting and orchestration. In assurance, it can slow incident detection and resolution. In fulfilment, it can create order fallout, manual workarounds and failed network changes.

An OSS platform can be technically healthy while the operational data and processes around it remain totally ineffective.

.

So, who should get which keys?

Senior leaders shouldn’t begin with the organisation chart, outcomes and allocation of activities to be completed.

What’s the OSS capability expected to achieve? Which decisions need to be made? Who has the knowledge to make them? Who has the authority to act? Who owns the relevant data? Who can validate the operational result?

Responsibilities can be shared, but accountability needs to remain clear. Platform administration might sit with IT, operational configuration with a network-domain team and data governance with a cross-functional authority. However, somebody still needs to remain accountable for the end-to-end outcome.

IT and OT don’t necessarily need the same keys, and neither team needs every key. What matters is that the organisation identifies the different keys, assigns each deliberately and makes the hand-offs unmistakable.

This definitive page on Ops Model Design might also prove helpful.

I’d also love to hear your thoughts. Do you have any stories to share about what’s worked (or not) for you in the past?