Simplify! - Part 6
Accidental complexity on a company level
Simplify! – Part 6
In the previous post of this series, we looked at post-industrial markets and digital transformation as external market-based drivers that create pressure on companies and their IT departments. We also have seen how not understanding these drivers usually leads to counter-productive responses that ultimately make things worse instead better.
Especially, not understanding post-industrial markets and digital transformation is the root cause for many measures that we will discuss in the upcoming posts of this series. Those measures brought IT in the place where it is right now, being overly complex with lots of accidental complexity.
But before we look at those measures, we first need to understand two more drivers of accidental complexity (and a lot of additional problems). In contrast to post-industrial markets and digital transformation these are internal drivers, i.e., they are located inside the companies.
The two drivers are:
- Not understanding IT in itself, particularly the nature of software
- Not understanding the role, IT has today
These two drivers tend to reinforce the effects of the two external drivers that we discussed in the previous post. Therefore, we should discuss them, too. 1
Not understanding IT
In the previous post, we saw that most companies are still stuck with an industrial mindset facing post-industrial challenges: efficiency-thinking trying to address uncertain effectiveness.
What makes things worse is the fact, that most companies – especially the decision makers – neither understand IT in itself nor its role today. Starting with the first aspect, most decision makers do not understanding IT and how “maintain” IT, especially software which in most places is the essence of IT. Most of them still think in manufacturing metaphors, comparing software development to shop floor production.
I already discussed in an earlier blog post that this comparison is plain nonsense. Software development is pure product design. The design is completed after the last line of code is written. Still, a lot of decision makers discuss “shop floor software development” – which leads to a lot of wrong conclusions.
This kind of thinking especially inhibits to understand that software – in contrast to most tangible products – always needs to be changed after its initial production to keep its value. If you believe that software is a product you manufacture, and your software development process should resemble a shop floor production process, you completely neglect
- that you do not simply sell that piece of software, but are affected by it across its whole lifecycle.
- that you need to change the “product” over and over again – usually more than 80% of the overall costs of a software accrue after its initial release.
- that the software you produce will be fed into the software development process over and over again. All corners you cut in this iteration will affect the software development process negatively in all future iteration, i.e., you pay the price for cutting the corner now and you will pay it many times.
If you neglect this, you typically enforce a lot of accidental complexity by trying to reduce “software production” costs, which results in negative effects (also from a commercial perspective) that will hit you – and no one else – multiple times.
A factor that makes it hard for most people to understand software is its invisibility. I discussed that in detail in a former post. While the invisibility dilemma makes it more comprehensible, I do not think it can serve as a general excuse for not understanding software.
Personally, I think that it is essential to understand the topics you decide about not only superficially if you do not want to create unnecessary harm with the decisions you make. Unfortunately, as IT and especially software and its specialties often are not understood at all, a lot of bad decisions are still made. 2
Not understanding the role of IT
Another reinforcing effect is that most decision makers also do not understand the role of IT today. IT often is still considered a mere cost center. I discussed in quite some detail in this post that this point of view does not make any sense anymore today 3. IT is not only the business nervous system. IT also enables or delimits today how fast and good a company can adapt to new market demands. And with the ongoing digital transformation, IT also becomes an integral part of the business offerings.
Yet, seeing IT as a cost center means trying to cut costs all the time, trying to avoid investments, trying to squeeze the last bits of efficiency out of it. This leads to several negative effects, e.g.:
- Slow, often counterproductive budgeting processes, impeding required investments to keep the IT landscape in shape and enabling adaption to new needs. I will discuss this topic and its negative effects in more detail in the next post.
- Depriving IT from decision authority (and budgets), making sure that the people who understand IT and its problems cannot address the problems they see.
- Pressing for quick and dirty solutions to save a few Euros, increasing accidental complexity and subsequent costs a lot.
- Maximizing utilization of IT employees, leading to extremely high response times, which in turn reinforces the pressure for quick and dirty solutions, driving accidental complexity. 4
- Prohibiting replacement of solutions that reached the end of their lifecycle, hoping to save a few more Euros, multiplying the cumulated complexity of the IT landscape. I will discuss this topic in more detail in a later post of this series.
- Standardizing the heck out of IT, removing the last bit of resilience and making it highly fragile with respect to any unexpected situation including unanticipated changes.
And so on. In the end, the wrong decisions made due to not understanding IT and its role often drove IT into the state of expensive immobility. Ironically, the persons who tend to complain loudest about this undesirable state of IT often are the same persons who made the decisions that lead to the state – due to not understanding IT and its role.
Blindly copying concepts
As we have already seen in the previous post, not understanding vital drivers combined with the pressure to respond to it often leads to blindly copying concepts that promise relief from the pressure. Yet, blindly copying a concept without really understanding it and its implications usually tends to make things just worse.
A little example: Some of the hyper-scalers ran into problems that were completely specific to them and they figured out that they could solve their problems by adopting microservices. As this architectural style was successful for them and they tend to have very fast and nimble IT departments, traditional enterprises became curious picking it up.
Additionally, as with modularization approaches in the past, also for microservices the story was told that introducing them would amortize quickly due to reusability. This story perfectly fitted the industrial mindset of cost-cutting and many enterprises picked microservices up – completely neglecting that they need to pay a high price for creating and running distributed applications.
While the hyper-scalers were willing to pay that price to solve their unique problems, regular enterprises simply lack all prerequisites to do so – in terms of people skills, experience, building and maintaining the required infrastructure as well as orders of magnitude more complex applications, and more.
So, in the end most regular enterprises usually ended up (or will end up) multiplying their accidental complexity without creating additional value – just because they did not understand IT (actually what the consequences of distributed systems are).
This was just a little example. I will discuss this topic in depth in one the next posts of this series.
Improving the situation
As we have seen, not understanding IT and its role is another root cause for the current state of IT and its excessive complexity 5. And again, we need to ask:
What can we do to improve the situation?
Basically, this leads to the same discussion and measures as in the previous post. Thus, I keep it short here:
- Help the affected people to understand IT better, especially the particularities of software, and that many conceptions derived from comparing software development to industrial production do not apply and tend to backfire.
- Help the affected people to understand the role of IT today better, that treating it as a mere cost center tends to backfire heavily today.
- Stop hiding complexity. IT is a lot more complex than most people living outside of IT imagine. Do not reduce complex trade-offs to a few simple bullet points. Try to explain things in a comprehensible way, but complexity is complexity stays complexity. Be fair to the decision makers and make it transparent. 6
- Aim for a continuous improvement process as big changes at once tend to overstrain the people affected and thus lead to a lot of resistance.
In the end, you cannot really separate the effects of not understanding post-industrial markets and digital transformation from the effects of not understanding IT and its role. They all influence and reinforce each other and in combination are the root cause for many bad decisions. Therefore also the countermeasures are basically the same – helping to understand, not hiding complexity, improving in many small steps.
Go for multiple governance models
I would like to add one more measure here that I left out in the last post because it became too long already. This is abandoning the “one size fits all” mentality with respect to IT governance models. Usually, IT is run and controlled using a single governance model. Also usually, the model is aligned with the part of IT that is most mission-critical – which are the existing core systems as they are the systems that run the current value streams of a company.
While not being completely wrong, this approach has some severe shortcomings. It assumes that all products and IT systems are subject to the same external drivers and forces, i.e., usually settled business models, slowly changing demands and processes – which means a focus on stability and efficiency while the response times regarding new ideas are of lesser importance.
Unfortunately, this is not the case for all IT systems. Some systems support products (or are products – thinking in terms of the digital transformation) that are not mature yet, that need a lot of experimentation or a focus on fast expansion. If you force the core systems’ governance model on those systems, you will end up with a lot of negative effects, accidental complexity being one of them.
Therefore, it makes sense to push for multiple governance models, as I already sketched it in the post regarding the different modes of IT. Again, this will not be an easy discussion, but I think it is worth it. 7
This post basically complemented the previous post. While the previous post described the effects of not understanding the post-industrial markets and digital transformation, this post discussed the effects of not understanding IT in itself and today’s role of IT. The first ones are effects driven by not understanding external forces. The second ones are effects driven by not understanding relevant foundations internally.
Together they form the predominant root cause of many wrong decisions that in a large part brought IT in the place where it is right now, being overly complex with tons of accidental complexity. Therefore it is important to understand them, how they affect IT and lead to increased accidental complexity.
As I already wrote in the previous post, it is very hard to change these root causes. Still, they provide such a big lever that we must not stop trying.
Another measure is working with different governance models for different types of IT systems as this, among other effects, creates an environment that helps to avoid a lot of accidental complexity.
In the next part I will dive deeper into the project level, starting with bad budgeting processes and other drivers that lead to accidental complexity on the requirements side. So, stay tuned …
Very likely there are more drivers on the company level that cause an increase of accidental complexity. Still, as not understanding IT and its role have such a big negative effect, I decided to focus on these two drivers. ↩︎
In one of his typical snarky discussions with an imaginary person “X”, Simon Wardley once suggested that for better business-IT alignment it would be a great idea to make an IT person the CEO. His reasoning basically was that the complexity of almost any business domain can be picked up in relatively short time (usually less than 3 years), but it takes at least 10 years (usually longer) to understand IT in the same depth. If I recall some of the discussions I had with decision makers – often being IT decision makers – I must admit that Simon’s snarky comment does not seem too far fetched. ↩︎
Unfortunately, I also see quite some IT departments that still behave like a mere cost center. While I think that such a behavior is a serious issue, discussing it is outside the scope of this post. Probably I will come back to it in a future post. ↩︎
If you do not understand how high utilization leads to long cycle times, I recommend reading “The Principles of Product Development Flow” by Donald Reinertsen. ↩︎
In the previous post, we had identified not understanding the consequences of post-industrial markets and digital transformation is another significant root cause for many of the wrong decisions that lead to ever-growing (accidental) complexity in IT. ↩︎
Not everyone will like you for making complexity transparent as it complicates decision making. My personal recommendation: do not fall for the pressure. Be sympathetic, but do not hide the complexity. Your fairness is to provide the decision makers with all relevant information required to make an informed decision. This also includes the complexity of IT and solution trade-offs. If decision makers do not want to recognize the complexity, it is their decision – and their responsibility. ↩︎
The book “Lean Enterprise” by Jez Humble, Joanne Molesky and Barry O’Reilly also provides a lot of good ideas and insights regarding the multiple governance models topic. ↩︎
Share this post