Monolithic Applications - Why Understanding The Business Matters

I've been thinking a lot about how to make a monolithic application useful in the long term. I subscribed to the view that systems have a usable life and once they are at the end you get rid of them. It's a reasonable perspective that still has merit. That is, until you get into the real world. There is no reason to believe that the lessons you learnt from the system about to be thrown out won't repeat. Or worse: you end up with 2 dud systems and no way forward. Many decisions were made in good faith, often with the idea that the team would go back and clean the mess up.

Many of you have experienced this story first hand: a business adds more and more to an application and at the same time cuts corners. The business ends up with what they want right now, but not what they want in the future. It becomes complicated to manage, new versions take longer to come out and if key developers leave it becomes a slippery slope. People begin the ask the question: are we getting value out of this system?

It's a great question to ask. A fundamental question. Every business should ask it even if they think the answer is yes. Once they ask the question raise a mirror at the business - the system is reflecting the business. Sounds like a cop out? It is, but that is the problem. More often than not, organisations schedule their development work via a steering committee. This committee rarely has more than one person on it who is technical. The asymmetry results in decisions without understanding the implications on the long-term value of the system. It is up to that single person to articulate abstract concepts and win time and effort to projects that don't appear to have any value.

So how do you get around it? You need to understand the business, but more important you need to understand where the business is heading. If you understand where the business wants to be in 12/24/36 months you can plan and win support for projects that supports the business in its goals. This means there needs to be openness between the head of IT and CEO.

By understanding the business I don't mean every single operational detail. I mean the "Operating Model" as defined in Enterprise Architecture. If you are staring at this and have no idea what that means then start searching. You already intuitively know what operating model your business is, but you may not be making decisions to support it.

Let's say that you are clear on the operating model of the business and the decisions you have made over the past year in development supported that model. Then you read an email by the CEO. About a restructure of various business units with the goal to increase cross-selling opportunities. A completely different operating model. And it's happening in three months.

This could just be bad luck. Perhaps you could have done nothing to foresee this restructure. That is unlikely. Often restructures and changes like this don't happen in a vacuum and there are many signs. This is where understanding the future of the business becomes critical. Businesses want systems to change quickly and you can give the illusion of it being quick if you start the changes early. Small, incremental changes - between other "now" projects.

So this is where we come a full circle. I have in the past blamed others for why systems are monolithic and bulky. I understand now that the responsibility of heads of IT is not to just manage projects or lead teams. They must know the business model to the degree where they can make suggestions of a more optimal model. The previous example about the cross-selling opportunities is what a CIO should be recommending. This vision will be welcomed by the executive and projects scheduled to make it happen. The monolithic system can be undone.