Of course, DevOps got there first. The realisation that technology processes and organisational models were rapidly becoming outdated by the rise of Agile required a holistic solution to how to develop better, and quicker.
The result was a seismic shift in not just what got done, but also why it was done. The focus of DevOps on scaleable, repeatable, safe infrastructure elevated senior engineers to a strategic role, and put technology on the front foot as digital transformation became a ‘thing’.
More latterly organisations have started to look at operationalising other aspects of digital, both within the production and beyond.
The addition of ‘Ops’ to a discipline can in many ways be seen to be a badge of ‘coming of age’. Design Ops is becoming a common term among design leaders. Research Ops has begun to gain traction. Marketing Ops is a couple of years old now at least. And last year was named the ‘Year of DataOps’ (think there’s space to have another one).
Looking across, and above
While the evolution of these individual disciplines from execution to operationalisation is great to see, at the moment there seems little to connect them. There’s not much in the middle.
This poses a challenge to the leaders within the individual disciplines, as it can create mini siloes — something we’re all trying to avoid. It’s also problematic to teams trying to put in place a professional development framework, digital employee value propositions, or simply more efficient recruitment.
We’re also missing the formal connection to the disciplines beyond the digital heartlands. These are crucial to the long-term ability for digital to change organisations themselves — culturally and structurally. My experience has been that the systems-thinking approach that an Ops model brings has applications beyond digital.
Visualising the Digital Ops model
Digital Ops is a superset of the existing ops domains. Each domain is of course still valid on its own (and there could be additional domains).
By thinking about the structure and subdomains of Digital Ops as well as those of the domains themselves we can begin to understand the relationship between domains.
For instance, the research ops model uses both qualitative and quantitative data, though with a focus on the former. The data ops model by contrast is focused on quant data, though qual isn’t specifically excluded and will often be a complementary dataset.
We can also use the model to compare the structure of the different models. Where the Research Ops model has an understandable focus on the practice of doing research, DevOps (the most mature of the domains) focuses more on the conditions that should be in place for development to be successful.
The digital boundary
The model suggests a boundary around what is digital, and what isn’t. My experience has been that as organisations mature digitally they start to question how relevant this boundary really is:
- Why are we only measuring the cost of sale for digital marketing, and not offline?
- Couldn’t we apply the digital design library to non-digital marketing?
- How can we integrate digital insights into our wider voice of the customer research?
Each organisation will have its own take on this. Some may choose to blur the boundaries for all domains, some for none. I don’t think there’s a ‘right’ way of doing this — but questioning the relevance of the boundary is a useful step in an organisation’s digital maturity.
Time allowing, I’m going to do some more work exploring the interconnections between the different operational domains, and comparing the different models. Watch this space for more.