Arnie, Danny and the Problem with Our OSS Digital Twins
We invest heavily in production environments (aka Arnie) and in reactive network fault-fix measures. Most OSS teams think of non-prod (aka Danny) as somewhere to
One of my favourite OSS books, that isn’t an OSS book at all, is Insanely Simple: The Obsession That Drives Apple’s Success by Ken Segall
Ken worked alongside Steve Jobs in the early days of Apple and cites many of the principles that drove its success.
That triggered a thought:
What are the core principles that underpin OSS/BSS?
In most industries, including OSS, there are a million things that you think you have to understand and memorise, but are they simply combinations of a few core principles? If so, what are those core principles of OSS that everything else builds upon?
This article is an attempt, most likely incorrect and/or incomplete, but a fun exercise in distillation into the core principles of OSS.
Like all of these thought experiments I play with from time to time, I’d love to get your feedback, to correct, to refine, to reinvent and to generally just help to generate a better version of what I’m currently thinking.
If we strip OSS back far enough, I don’t think the foundations are inventory, assurance, fulfilment, orchestration, planning, fault, performance and so on. Those are merely product categories we created around recurring combinations of a much smaller number of primitives.
My reduction would be:
OSS exists to maintain an actionable understanding of a network (and services) [a digital twin of the network], determine how reality differs from intent and safely move reality towards intent
Almost everything else can be derived from that
Before an OSS can do anything, it needs to distinguish one thing from another
A network is fundamentally a collection of identifiable entities:
This sounds trivial, but an extraordinary amount of OSS complexity comes from identity resolution.
Is PE01-MEL, mel-pe-001, serial number XYZ123 and EMS object 74219 the same thing as any of them??
Hence:
Discovery, reconciliation, federation, data integrity / audits, duplicate detection and many other concepts are all manifestations of the entity / identity problem.
Identity tells us that something exists, but then….
State tells us:
State is never simply “true”. It is an observation of truth at a particular point in time.
Every OSS is therefore maintaining some approximation of:
Entity + state + timestamp
That has enormous implications for inventory accuracy, telemetry, caching, event processing and more.
A list of network entities / objects isn’t particularly useful for most important use-cases.
OSS becomes powerful when it understands:
A relates to B which depends on C which supports D
Telco networks tend to have much more relationship sophistication than IT infrastructure, so Network Inventory tools are often much more complex than traditional CMDBs.
Telco networks need to model relationships through the sample 5G stack from east-to-west (across domains) and from south-to-north (up the hierarchy).
These relationships can be:
This is why I increasingly think the network is fundamentally a graph.
Topology, inventory, service impact, root-cause analysis, path computation, capacity planning and digital twins are all applications of the same underlying principle:
Understand the graph of relationships between things
Those first three describe reality. They give us:
Things + their state + their relationships
But an OSS needs something to compare reality against, which brings us to perhaps the most important principle:
Networks don’t merely have state
They have intended situation or state
For example:
Intent can appear as:
A huge amount of OSS is simply the management of the gap between:
Planned, desired and observed state (more on this later)
This is why I think the classic OSS domains are actually much more closely related than their product categories imply
An OSS needs evidence about reality
That evidence comes from:
All of these are variations on one operation:
Observe reality
Fault management and performance management look like different disciplines mainly because one historically collected events and the other collected counters. Conceptually, they’re both observation systems and can be amalgamated.
The harder problem is determining:
What should I believe from the observations I receive?
Once you have Observed, Planned and Desired state OSS becomes a comparison problem
The difference might be:
Different OSS disciplines simply give these differences different names:
But underneath them all is essentially:
Something isn’t how we expected it to be
Once the OSS understands that there’s an unexpected difference, it needs mechanisms for rectifying it.
An action could be:
Again, these appear very different in traditional OSS architectures:
Provisioning, activation, orchestration, workflow, remediation and workforce management are all different implementations of the same underlying primitive (action / change).
This is the principle that older OSS architectures frequently under-emphasise
Issuing an action isn’t enough
You need to:
That creates the fundamental OSS loop:
Model ? Observe ? Compare ? Decide ? Act ? Verify ? Repeat
And suddenly we have:
Many of these are modern buzz-words. However, they’re not fundamentally new concepts, just increasingly sophisticated implementations of the same closed-loop concept.
I wouldn’t call these separate OSS functions. They’re more like the physics governing the system
Networks are continuously changing
So OSS isn’t really modelling:
“What is the network?”
It is modelling:
“What was believed about the network at time T?”
This is why event sequencing, temporal topology, audit trails / logs, change history and versioning matter so much
The amount of integration within OSS/BSS is often difficult to fathom. Multiple systems inevitably claim different versions of reality so reconciliation becomes necessary.
Therefore every OSS architecture eventually confronts the reconciliation challenge:
What is the authoritative source of this fact?
That creates systems of record, federation, ownership boundaries and reconciliation rules. Making things even more complicated, Authority might belong to different sources for different attributes of the same object
A particularly important principle for next-generation OSS, where networks, systems and associated data are all far more dynamic and autonomous. Data integrity is simply more important with the more widespread use of autonomy and agentic control mechanisms. They rely on algorithms rather than human intuition, so we need to ensure the data being used has trustworthy provenance.
OSS data shouldn’t merely say:
port.status = ACTIVE
It should increasingly say something closer to:
port.status = ACTIVE
source = EMS
observed = 37 seconds ago
confidence = 0.998
It becomes especially important once AI agents become increasingly responsible for operational decisions.
Networks can’t transition arbitrarily between states
Every action is constrained by:
Planning, orchestration and optimisation are therefore largely:
Finding valid state transitions within the defined constraints
| OSS discipline | What it really is |
|---|---|
| Inventory | Persisting entities, state and relationships |
| Discovery | Observing entities, state and relationships |
| Reconciliation | Comparing competing representations of state |
| Fulfilment | Moving network state towards service intent |
| Activation | Executing state transitions |
| Orchestration | Coordinating constrained state transitions across domains |
| Assurance | Detecting divergence between expected and observed behaviour |
| Fault management | Observing exceptional state changes |
| Performance management | Observing state over time |
| RCA | Traversing relationships to explain observed differences |
| Service impact | Traversing dependencies from resource state to service/customer state |
| Capacity management | Predicting future constraint violations |
| Planning | Designing a future desired state |
| Configuration management | Managing desired versus actual configuration state |
| Workflow | Coordinating sequences of actions |
| Digital twin | Executable representation of entities, states, relationships, constraints and behaviour |
| Autonomous network | Automated Observe ? Compare ? Decide ? Act ? Verify loop |
| AI agent | A new mechanism for deciding which state transition should occur |
| MCP | A machine-readable mechanism through which agents can observe and act |
That’s why so many supposedly different OSS platforms start looking remarkably similar when you look underneath their terminology and modern buzzwords.
If I had to teach someone only three ideas about OSS, I’d teach them these:
1. There are three versions of the network
2. Almost every OSS problem is caused by differences between those three
3. Almost every OSS capability exists either to understand those differences or eliminate them
What do you think? Have I missed, or fluffed, any of the fundamental laws?
What would you change?
We invest heavily in production environments (aka Arnie) and in reactive network fault-fix measures. Most OSS teams think of non-prod (aka Danny) as somewhere to
Telecom architects often jump to the conclusion that more capability means better performance. Add another feature, another platform, another integration, another automation layer and the
As Daniel Priestley articulates well here, the disposable lighter is an extraordinary example of capitalism doing what capitalism does best – thousands of tiny improvements
No two OSS projects are the same. One might have a different vendor stack, another a completely different organisational structure, another a different operating model