Jan Bosch is a research center director, professor, consultant and angel investor in start-ups. You can contact him at jan@janbosch.com.

4 May

DevOps, DataOps, MLOps – the number of different “Ops” combinations seems to have exploded over the last year or so. There are manifestos, meetups, lots of blog posts and research articles about these various approaches.

In order to get clear on terminology, I think it’s good to define what we’re talking about. So, first, DevOps is a set of practices that combines software development (Dev) and information technology operations (Ops) with the aim to shorten the system development life cycle and provide continuous delivery with high software quality (Wikipedia). The intent is to combine agile software development practices with continuous deployment in order to have a constant flow of new functionality and resultant value delivery to customers. Also referred to as continuous deployment, new functionality can be rolled out whenever it’s ready, the effects measured and the feedback used to inform the next (rapid) cycle of development.

DataOps is an automated, process-oriented methodology, used by analytic and data teams, to improve the quality and reduce the cycle time of data analytics (Wikipedia). Although this sounds very different from DevOps, in most product companies, it’s tightly interconnected with the products deployed in the field. Consequently, the data analytics is primarily focused on R&D teams that need to know if the intended outcomes of their development efforts are indeed accomplished as part of the continuous deployment pipeline.

Finally, MLOps is a practice for collaboration and communication between data scientists and operations professionals to help manage the production machine learning (or deep learning) life cycle (Wikipedia). Whereas traditionally, data scientists would develop a model based on a data set and then move on with their lives, currently in many systems, ML/DL models are constantly evolving due to changes to the data or new algorithmic insights and need to be deployed frequently as well. Once deployed, they need to be monitored to ensure that models that perform better in training also perform better during operations.

In an earlier column, I presented the HoliDev model (see figure). Each of the “Ops” matches with one of the three types of development that’s ongoing. The surprising thing, of course, is that “Ops” for all these stands for “operations” and the key is to remember that for any system, product or solution, there’s only one operations function taking care of it. So, Dev, Data and ML all have to integrate with the same Ops.

The HoliDev model

Concluding, whatever “Ops” you’re working on, it all has to come together in the same operations and consequently, you’ll need to work in cross-functional teams to ensure that you’re reaching the desired outcomes. The important takeaway is, though, that if an activity delivers value to customers, it deserves being done often. Only unimportant tasks are done yearly or even less frequently. So, reflect on this: for all the value-adding activities and processes in your organization, how can you increase the cycle time and create your own “Ops” setup where it matters the most?