Martyn Coupland

In this post, we look at XOps, the catch all term for the movement of combining different disciplines together with operations.

This is day 6/100 in the 100 Days of DevOps series.

XOps is a general catch all term that describes the adoption of other forms of operations both inside and outside of technology. In this context, DevOps is really just the tip of the iceberg.

DevOps is just the beginning, you can also include BizOps, FinOps, AIOps, and MarketingOps as a start, but the term XOps covers more than just the ones listed here. These are all cross-functional efforts as DevOps is, but do organizations really need all of them, even some of them or is the movement more of a hype?

One thing we can all agree on is that organizations are at their own stage of maturity, the factors for this include their size, age, industry, technical adoption, budgets, and of course culture.

Organizations are increasingly needing the benefits of what these different kind of operation models provide; some organizations will implement as much of them as possible and some will implement what they need and even manipulate the processes and level of adoption to best fit with their organization.

This does not mean that the results will be any different depending on the factors previously mentioned, as with DevOps, what the key element in all of these models have in common is the focus on value, that is something which is unique to each organization.

Where did XOps begin?

Some people believe that XOps is just a hype, one that will blow away and that much of what is proposed is relabeling of what already exists. You can say the same about DevOps as well, but it is the way that practices within DevOps are brought together and not left fragmented that delivers the real value to organizations.

Like DevOps, most of the types of operation models will look at the acceleration of process and improvement of quality when it comes to what they deliver. For example in DataOps, this would be data, and analytical insights into operations performance for AIOps.

Those that believe XOps is overhyped, believe that the risk is that fragmentation is created by the different groups which are involved. This fragmentation further dilutes the faster value that is created and creates a level of extra bureaucracy.

Agility is at the core of Xops as since the turn of the last millennium, business leaders have been aware that their organizations need to be more agile in order to stay competitive in their industry.

Agile practices which form part of XOps have been around for some time and have surfaced further up the business stack for some time. Sadly, some leaders take the view that agility will equal the ability to do more with less.

How to approach XOps

Let’s look at an example approach to XOps. The objective is to transform what is currently a monolithic application into a microservice architecture. Additionally, the migration process should be automated along with separate environments for production, UAT, and test.

The primary identity should be managed by the DevOps team, this allows you to manage users and groups as well as third party services and applications. This approach advocates collaborative culture.

To further make resources modular, the team generates container-based modules for multiple resources, stacks are then broken down making them scalable and ensuring that deployment is easier.

Maintenance and debugging with this approach become simpler for development teams as well, and automated processes help enhance code quality. Role based access control ensures secure authentication and authorization.

The deployment of centralized systems for logging and monitoring allows views of performance, availability, and security on centralized dashboards. These help provide cost effectiveness and improve the performance of the application.

Up next

In the next post, day 7 in the series, we are looking at implementing DevOps in your organisation.