If there is one thing that has struck me from my journey optimizing the software delivery process of a traditional enterprise and the feedback I get from the people that are involved in the DevOps community – the majority working in agile contexts – it is that traditional enterprises work very differently from the modern high-performing companies.

I have already largely discussed this topic in a previous post where I took this difference as a given and simply wondered if we could apply the patterns that make these modern companies so successful also to the traditional enterprises.

Here is a slide from my DevOpsDays London talk that summarizes their differences:

In this post I will take it one step further and ask the question why they are so different in the first place. And, if this difference is only “cultural” rather than “genetic”, whether it is possible to transform the traditional enterprises to modern ones, instead of awkwardly trying to squeeze these successful patterns (I’m talking about agile, DevOps and CD here) in to them.

Value add vs utility

A comment of Steve Smith on my blog led me to an interesting article by Martin Fowler in which he refers to another interesting article by Ross Pettit. Both posts give an indication on a possible root cause for this difference. The argument goes that IT projects should best be split up in two distinct categories: projects that add value and projects that merely provide a utility. The main difference between the two is that the value adding projects aim to strategically differentiate the company over its competitors and are therefore critical for its overall success. Utility projects aim to deliver functions that are needed for the company to run its business but that are not directly related to its success.

According to the articles, both types of projects must be treated in a very different way: value adding projects must deliver the best possible result (these are where you should put your money) and utility projects must deliver the cheapest possible result that gets the job done. The underlying reasoning is that if you do a value adding project slightly better you will get a considerably higher gain and if you do a utility project a lot better you will get a very small gain.

And because of their different nature also the IT side of both types of projects must be managed very differently: value adding projects are all about agility and time-to-market: if you can be the first one to deliver a new function (or “get it right”) you will have an edge over your competitors. Utility projects are all about reducing risks and increasing stability: you don’t want the function to break because then it will cost you a lot of money but you are OK that it works just good enough.

In the end it’s the CEO who decides which projects are value adding (or strategic) and which ones are utility, keeping in mind that projects can move from one category to the other over time, e.g. a function that was initially considered strategic may be switched to a utility if it turns out that the competition has closed the gap. The articles estimate that between 70 and 95% of all projects in a company is utility.

Traditional enterprises have more utility

OK, back now to our initial question: what does all this have to do with our search for the root causes of the differences between traditional and modern companies?

I think there are several interesting points here:

1. Traditional companies are obviously a lot older than modern ones so they have had plenty of time to grow several layers of “value adding turned into utility” software, each layer representing a different period in the past. This software will most probably not have decent support for automation of testing, deployment etc. (although this may be different for the current state-of-the-art software that will be utility in a couple of years).
2. Modern companies probably have more modern utility packages that may provide better support for automated testing and deployment, have a lightweight decoupled architecture and decent integration points. Traditional companies will probable depend mainly on old packages that lack all of this fancy stuff.

My main take-away point from the articles is that traditional companies have considerably more utility software than modern ones, more to the 95% than to the 70%, and in addition this utility software is older and has therefore less support for automation.

If we want to modernize the traditional enterprise the big question now becomes what should we do with all this utility software? Should we still try to automate its software delivery process? As we just saw one of the properties of utility software was that we should keep it low cost because it doesn’t bring us any noteworthy strategic advantage. Then maybe we should just leave utility software out of the equation – accepting a low and painful change rate for them – and concentrate instead on value adding software?

I can’t say.

One last remark on this topic: it looks to me that we will likely see the inverse process happening with the modern companies of today becoming the traditional ones of tomorrow, built on technologies that will not support out of the box whatever new requirements will be state-of-the-art in the future and they as well will end up with a large stack of “old” utility software. (Note to the ruby, nodejs and go developers: enjoy your status of cool kids while you can because in a couple of years we will all look down to you as old-school developers :-))

Shortcomings of the model

This simple metaphor of utility and value has not been able to give us a definitive answer so far. Maybe it just doesn’t account for the complex reality that we are faced with when looking for our answers? Maybe we should look to extend its model or replace it with a better one, and see what this gives?

I have found a number of important shortcomings that I would like the new model to take into account.

To start with, the original model assumes that a competitive advantage can only be reached through value adding projects. But many companies use low-cost as their competitive advantage. And in mature markets there is very little opportunity to explore new territory so consistently finding competitive advantages there may prove to be very difficult. All this makes that the strategic focus will be more on finding ways to efficiently run utility projects as well as on finding the best sales and marketing guys to differentiate your product. On the other extreme, value adding projects don’t always have the intention to lead to a direct competitive advantage: some companies have a big R&D department which is all about adding value on the long run but is not necessarily a strategic differentiator at the current moment.

Secondly, an important fact is not taken into account: value added projects may have critical dependencies on the “value add turned utility” projects. These last projects were there first and therefore represent the core of the application landscape. So they too should be kept in a modern, releasable state. But exactly because many of the younger projects depend on them they should focus on avoiding risk. Because of their maturity they have less need for flexibility and time-to-market but instead could take a more steady path of evolution, which resonates well with risk-aversion (especially taking into account their low-automation context).

Layers of software by age, similar to the geologic layers of the earth, and their dependencies, indicated by the dashed lines:

Finally, the articles make the implicit assumption that value adding projects are all about trying to find ways to innovate, in an attempt to keep an edge over the competition. I believe that there a many markets where this is not the case. Markets with high entrance barriers or that favor monopolistic behavior are examples where added value remains stable for longer periods. I argue that these “mature” value adding projects could as well be treated as “value add turned utility” projects. Because they are so similar it would be hard anyway to draw a line between them.

Introducing a new category

In the new model I’m going to introduce a category “core” that represents the “value add turned utility” and “mature value added” projects, while the new value added category is now limited to the evolutive value adding projects:As with the other two categories, this core category also has a very specific nature and must therefore be treated in its own way. Compared to value adding projects the core projects have more dependencies and should therefore focus more on risk-aversion. As they are more mature they have less need for creative ad hoc thinking and quick time-to-market. They are less likely to deliver high returns so cost effectiveness should also get a bigger focus. For these reasons they may be a better fit for process-centric approaches like ITIL and CMMi (one of the two M’s stands for … maturity) than the value added projects.

On the other hand they are too important to be merely considered utility projects and be left over to the destructive forces of cost efficiency and out-sourcing. Killer features get the attention of your customers but if you don’t have a high-quality application around it they will not get you very far.

Once we have accepted that each category is indeed best off getting a dedicated treatment, we should think about how to make the value adding and the core projects co-exist with each other, considering how interdependent they are. Similar to how value adding projects can put a high pressure on the ops side to deliver their features to production, the same can happen to the core projects whenever the value adding projects need them to implement features they depend on. And this issue will remain, even if both project types are independent from each other in terms of infrastructure, project methodology, technology choices, compliance, release process, etc.

Another attention point is how we should handle the transition from value add to core and when exactly this should happen during the coming to age of the project. In rigid corporate environments these are non-trivial problems to solve, especially if there is a big gap between how these two types of projects are managed.

DevOps for mature IT

At the moment DevOps is focused on the evolutive value add category which is only a small subset of all projects. There is another very important category, the core one, that has its own specific treatment. As it represents the bulk of the applications in traditional enterprises and a considerable percentage in even the modern ones, its software delivery process also deserves our full attention. We should therefore try to improve it by means of the three levels of DevOps: communication, process and automation. But this time we should use the context of these core projects as the starting point. Maybe we should even create a special flavor of DevOps for this category? Let us call it “DevOps for mature IT”!

While writing this post I learned that traditional enterprises don’t only use core/utility projects and modern companies don’t only use value adding ones. No, they use both project types, but just in varying degrees. So whatever solution we come up with to improve the software delivery process of a company should therefore support both value adding and core projects, including the integrations between the two.

Wrap up

We have started with the question why traditional enterprises are so different from modern ones. We have looked at a simple though powerful model that splits up projects into utility and value add ones and have concluded that traditional enterprises have more utility than modern ones.

But the model was not conclusive as to how to treat these utility projects. We found some shortcomings which we then solved by extending the model with a core category. We concluded that this category is characterized by mature and interdependent applications that are critical for the success of the company. Therefore its software delivery process also needs our full attention. But because its context is so different from the value adding category we should create a special flavor of DevOps for it which we called “DevOps for mature IT”.