About Inertia in Corporate Software

When you’re passionate about software, it can get really frustrating to notice how corporate customers are sometimes suffering from software inertia. You talk to them about all those wonderful technologies that you’ve come to master, all those innovative solutions you can offer… and they tell you that they’re looking for AS/400 developers, or people with 10+ years of experience with EJB’s. As a consulting company, it can be tempting to give in to that kind of request. As a software consultant, I always feel like it’s my duty to improve the level of information of the person I’m talking to, and be a little more aggressive.

Why so much inertia?

There are a lot of factors that play a role in this situation, proportions varying depending on the company and its history. An important one is certainly vendor lock-in. Old-school software vendors like Microfost, IBM, Oracle, Serena and others have become masters in selling big expensive licenses for their tools. Their strategy is not based on the quality of what they’re selling, but on things like their long-time reputation, the belief that when the price is high then it cannot be bad, the coherence principle (you never question your own decision when it requires a big sacrifice from you) and so-called integrated offers: operating system + development environment, reporting+collaboration, tools+methodology. And they always add something exclusive to the mix so that switching to another vendor is as hard as it can be.

Very often combined with vendor lock-in is the belief that coherence lies in unity, that if you go for everything Microsoft or everything IBM, you’ll never have to make big decisions again. Whenever there is a new need in your software infrastructure, you’ll just take what your “preferred partner” has to offer for that, and you will end up with choosing tools not because they are the best at what they do, but only because they integrate nicely with what you already have.

Another dangerous quest is the one of the silver-bullet technology, the tool/architecture/methodology that will solve all of your problems today and tomorrow. Once again, big software vendors have traditionally played an important role in sustaining this myth, abusing buzzwords and repackaging old offers in new shiny boxes. And what’s even worse is that very interesting principles have been completely perverted because of this quest for the one technology that will solve all problems. Unfortunately, like most myths, this one was born in laziness and experience shows you that it’s very important to characterize each problem in order to always choose the right tool for the job.

Another motivation for sticking with your current infrastructure is to capitalize on your expertise. With time, your people start to master your infrastructure, know its weaknesses, learn how to work around them. All this experience is definitely precious and it is for me the first good reason to maintain a certain level of inertia. That and the fact that all this internal knowledge can make you save some budget on training as people can train one another and as you can build your own knowledge base.

Last but not least, there is a very important aspect, that is not always admitted explicitly, but is usually very present in big old companies: fear of chaos. IT in general and software in particular are very dynamic fields, and this trend has been accentuated by the Internet in the past decade. Combine that with the fact that most young IT professionals have a tendency to play with the newest toys on the market, and you quickly notice that things can get a little out of control when people try to incorporate immature technologies and then move backwards when they realize the cost of this immaturity in terms of maintainability, durability, integration, training and so on. This fear is perfectly understandable, but as always it’s the extreme response to this fear that can have dangerous effects.

What are the problems?

The first issue that comes to mind is the lack of agility (Titanic effect). The older the tools are, the more likely it is that they were designed at a time when the business conditions didn’t evolve as fast as they do today. Hence it becomes harder and harder to adapt to those changing business conditions, to collaborate with partners, to merge infrastructures, to expand business models and so on.

Behind lack of agility, there is a more general symptom that shows that your software infrastructure is bloated: people lose an awful amount of time solving very old problems that have long been solved by newer technologies. Productivity is key both for the motivation of your software team and for your ability to quickly implement new requirements. But mature technologies are also getting older and older, and as time goes, it becomes exponentially harder for them to integrate new features, to the point when this evolution is just not possible anymore, forcing you to do the Big Switch.

It’s a well-known disease in corporate IT: instead of making it evolve continuously, inertia often leads companies to evolving in eras, the transition for one era to the next one being often marked by big rewritings. The cost of these efforts is usually extremely high, not only because of the resources you need to allocate to this rewriting, but also because of the time during which you won’t be able to make your features evolve. Some of this cost might be compensated by the fact that you take the opportunity to improve performance or add new features. But it can also be amplified by bad business decisions like trusting Indians to do the porting or something like that.

Another important issue is the growing cost of maintenance of legacy systems. Even when you realize that rewriting everything on each transition is risky, maintaining legacy software becomes more and more expensive as it is harder to find resources with the knowledge of your technologies. Combine that with the point mentioned above about productivity and you understand that it takes more time to more expensive people to maintain your system.

Finally, as I said before, technology passionate people often tend to like playing with new toys. Now even if letting them completely free to do so can be very dangerous for you as a decision maker, forcing them to use only old technologies that they will probably never need anywhere else can also frustrate them to the point when your will lose their intelligence and insight. That’s when the cost of turnover hits you in the face.

So what can I do?

That’s the question you might ask yourself if you have some decision power in a company with too much software inertia and too many of the issues mentioned above. Here are a few leads that can help you improve the situations. Most of them are based on the generic principle that you have to find the right balance between capitalizing on your existing infrastructure and make it evolve continuously.

The first key for me is technology watch. RSS feeds and conferences are a great way to keep in touch with what’s happening outside of your organization, and even what’s coming in the next few years. When you’re in darkness and you don’t have a clue about what’s around you, it’s always safer not to move at all. But since you need to move, you also must learn more about your industry and what others are using, even if you don’t incorporate all of them.

The next step is to be honest with yourself about the limitations of your current infrastructure. As I said before, a lot of software vendors rely on the fact that you won’t discuss your own decisions when they are very expensive. So it takes some courage to be lucid about the weaknesses of your current system and monitoring those weaknesses in time is crucial, either to find local solutions to those limitations, or to decide when it’s time to replace a technology that is too limited. This is especially hard to do in bureaucratic environments where decisions tend go from the top down, and bottom feedback is not often listened to. So my advice: listen more to the people who are using the technologies you choose on a day-to-day basis, and you might realize that your situation is not as perfect as you currently think it is (Ostrich-style).

When you hear about interesting new stuff, don’t hesitate to try it out, to allocate some resources to develop a proof-of-concept for it, or go through a getting-started tutorial. Very important: do not base your opinion solely on rumors, analyst reports and opinion of others. Don’t forget that in the same way as silver-bullet is a myth, the technology that is inherently and universally bad does not exist. So what might be the right tool for the job of other might not be good for you, and vice-versa. That’s why making your own opinion is very important, even if it will never be comprehensive.

Another important thing to understand is that innovation starts in opposition. Opposition against the status quo, against existing technologies, which often leads innovators to restart from scratch in very original ways, making it harder to integrate those innovations with existing technologies. But if those are successful, there is very often a second phase in which those innovations are incorporated into existing technologies, or at least some work is done to ease their integration with mature tools. For almost every new technique, version 1 is a proof-of-concept, version 2 turns into a more complete solution, version 3 gets integrated with existing technologies. So when it gets to that version 3, it’s always interesting to try it out.

Next, let’s talk about Open Source. It’s incredible to see all the limiting beliefs that circulate around Open Source. Beyond the fact that people tend to associate free and low-quality (a belief that is of course sustained by big software vendors, even when they benefit from Open Source themselves), a lot of IT decision-makers also think that if it’s Open Source, they won’t have any support for it. My answer is that if it doesn’t have any support, it is in fact not worth it, but make sure there really is no support, because one of the most successful business models for Open Source is corporate support. Hence most interesting Open Source technologies are backed by at least one company offering high-grade professional support. And maybe the most unfair argument is that Open Source is dangerous because it can disappear over night. When you understand how most Open Source licenses work, you see that they simply forbid project owners to hide their code, and beyond that, communities are often much more reliable than software vendors who can bankrupt in no time. I’m not saying that Open Source software is more reliable and durable than commercial software, but it is certainly not less so. Now beyond this reliability and durability issue, by definition, Open Source projects don’t rely on vendor lock-in, but on the quality and usefulness of their technology, which leaves you with more choice to go from one to another and to combine technologies coming from different providers. Now I just want to mitigate what I just said: Open Source can definitely help you to get rid off your inertia more than you think, but it might also create new problems like free lock-in, in which you end up using a tool not because it’s the best for the job, but simply because it’s free. Fortunately for us, not all commercial software vendors are as rotten as big old ones.

Architecture can also play an important role in gaining more agility with your software infrastructure. Try to avoid big monolithic solutions and favor modular architectures allowing you to change parts of your systems without rewriting everything. Virtualization and componentization are definitely going to help you in that endeavor, as well as getting your software architects more experienced with composing their own toolkits for specific problems, instead of forcing them to always apply the same bloated infrastructure.

Finally, important enemies of agility are over-confidence and self-sufficiency. Of course I’m preaching for my church here but I think that bringing new blood to your teams in the form of external consultants can really help you make your software technologies evolve continuously, especially when you don’t just use them to fill in boxes but instead empower them to help you get more agile… and avoid the iceberg (shameless plug inside).