Part 2: It’s all about economics
There is an old joke I enjoy, that I think has a lot of relevance to software.
There was a guy who always cut his pot roast in half before cooking it. His wife was curious as to why he always did it that way. He replied that this was the way his mother had always done it. His wife went to her husband’s mother and asked her why she did this. The mother replied that this was the way that her mother had always done it. Finally, the wife went to her husband’s grandmother and asked her why she did this.
The grandmother replied, “It was because I didn’t have a dish large enough to put an entire pot roast in!”.
In software we often make this mistake. Our products evolve and have features added without questioning the original assumptions and decisions that led to the existing design.
This easily leads software companies to lose sight of the actual problems that they are trying to solve for their customers. I found it helpful to remind myself why people find value in purchasing middleware. At the crux of it all, it’s about economics.
Normal software economics are wonderfully profitable. Once you have sold enough units, every additional unit sold thereafter yields pure profit.
With this economic model, the cost of actually developing software can be very high as it doesn’t have to be the most efficient process.
But when you sell your software into a market where it has to be integrated, this rosy picture all comes crashing down.
While every industry has standards designed to make integration easier, they are never 100% standard. What may seem like subtle and trivial differences create the need for custom ‘glue’ code that is unique to every customer site. Whether the code is written by enterprises that consume the software or the vendors that produce it, the problem is the same.
The economics have suddenly changed.
Every new system that is deployed now carries additional development costs of writing and maintaining this custom glue code. The problem of minimizing the time to develop software is now overwhelmingly important. This is the very problem that middleware is meant to solve.
The trouble is that middleware vendors believe the problem is the custom ‘glue’ code itself. But that isn’t the problem!
I’ve spent the past few years, re-thinking our approach to integration to address the real problems that our customers face and I am proud to say that we have developed a more sophisticated and appropriate solution. A solution that actually takes into account the real-world problems of our customers. A solution that is not only better suited to meet the integration challenges of today but of the future as well.
I understand that all this talk of change can sound alarming to existing customers. I want to personally assure you that you will be able to continue to use our products in the same way you always have. We will continue to support the existing functionality of our products as long as our customers require it. The solution that I speak of is a major enhancement, not a complete replacement.
We will proudly be presenting this solution at HIMSS later this month, when we unveil Iguana 5.0. I personally invite you to come see what I firmly believe is the future of integration at our booth, #3621.
I also invite you to subscribe to our blog as I will be continuing this blog series to explain not only what changes we’ve made but also the rationale behind them.
You can also follow us on twitter (twitter.com/interfaceware) to receive updates to this series as well as other important product and industry information.
Eliot Muir
President and CEO, iNTERFACEWARE™