You always get what you pay for

The right foundation: whether you are building a house or building software

Let’s say you want to build your house and someone would propose building it without a foundation, or just a minimal one, then you would be unhappy even if the price was very attractive. The same goes if the proposal would include a foundation that can support a tower when all you need is a two story house.

The beauty in construction is that even for us the non-initiated people, some things are obvious. Things like how deep you would dig for a foundation. And yes, there are differences in soil that can lead to different approaches. But you can see what is being done and at least ask questions.

When it comes to enterprise software, things are less visible and less transparent. And that leads to two extremes: either over-engineering or under-engineering it.

For now, I will address the second possibility.

Under engineering

Many people see business software as just plain software. They don’t see the structural difference between enterprise software and ‘normal,’ custom-built software. So when we select our needed software solutions for the future, we tend to go for cost as the primary criterion. And the price should be one of the decision factors, but not the only criterion;  we would overlook the quality of what has been built and the long-term implications for maintenance, which also translates into costs over time.

Enterprise software

The fact is, an enterprise software product is not ‘normal’ software. It is a product that needs to work in all sorts of different circumstances and at a variety of customers (with the distinct exception of the SaaS systems where the supplier controls and manages the whole context). Enterprise software should function not only today but in the future as well and thus be based on technologies that will not become extinct in a few years. And it should have a ‘foundation’ to carry the needs of today as well as be adaptable to carry the changing requirements of the future. Ideally should not depend on a single vendor, especially if it’s a small one as continuation over the years is important for a mission critical software product.

The right quality

It’s better to (re)build parts of the system at good quality (prioritized on business value and how often customers use the different parts of the software) than to rebuild everything at a below-average quality, leading to a product that has serious technical debt as soon as it’s ready.

And yes, in the beginning, this leads to more thinking, questioning and strategizing before taking the plunge, but that’s a good thing, it will pay off in the long run. Questions like – how do my customers use the product, which parts are most important, where is the industry headed and which parts of the product are likely to change. Not all modules and functions are used equally, and therefore they don’t need to be created equally. And this type of thinking is essential if we want to become successful.

In the end, creating the new software platform is like planning a house. It requires balancing wishes and budgets and prioritizing what’s most important unless money is not an issue. But it always is. Rushing the team will not fix the financial issue in the long run. And delaying thinking about long-term maintainability will not reduce cost, but only delay the spending of cost which will be incremental if the foundation is laid without keeping this in mind. As the English say: penny wise, pound foolish.

Because you always get what you pay for.

Daniel Lar
Managing Director Yonder