I continue with the third part in my series on enterprise system pitfalls and now discuss the problem of what I call the infrastructure imbalance. I have two previous posts that introduce the topic of pitfalls of enterprise systems and discuss the pitfall of over abstraction.
Most pitfalls are rooted in a bad way of thinking about the problem and solution. We largely have forgotten the science behind the technology we implement, and underestimate or simply ignore the costs of our decisions and overestimate the theoretical value. This leads to over abstraction, and similarly to over investment in infrastructure.
Enterprise systems have become bloated with layers and layers of components, abstractions, and open source libraries all with the intention of creating a valuable infrastructure that can check all the boxes of a “good modern design.” Many of these components exist only to make other infrastructure components work, producing a recursive effect I would call going down the rabbit hole. “Good modern design” is relative, and a modern architect’s definition of “good” often does not correlate to real value.
I’m a huge fan of orbital rocket design, and even have apps on my phone that tell me when anything is launching into space. I have watched documentaries, binged on YouTube, and am a fanboy of the Everyday Astronaut. In rocket science, there is a very clear, visible and tangible cost of the weight of a rocket. The goal of a rocket is to launch as much payload as possible using as little fuel as possible into orbit, so every pound of rocket is a pound of payload lost. Because of this, the successful designs are ones that find the right balance between structural integrity and mass.
But what is the rocket really? It is simply infrastructure. The rocket has no direct value. The only thing of value is what it carries. When a telecommunication company needs a satellite in space to stream video to more people (from which they get money), there is direct, real, and measurable value of the satellite being in an operational orbit. And, that is the only value. The value of the rocket is based on the value of its payload. So, telecommunications companies select their launch vehicles based primarily on two things: cost and reliability. What else matters? Does the material of the rocket, the types of engines or how many stages matter? Only as it relates to cost and reliability.
Enterprise systems are very similar, but we don’t often look at it that way because we don’t see the problem as a scientific problem, though it really is a problem of science. We must design systems that move as much data as possible, as quickly as possible, with reliability. System components like databases, websites, service buses, libraries, abstractions, APIs, ORMs, services, etc., all have no direct value. The thing of value in information systems is processing and moving information, and delivery of the information in the right form, to the right place, at the right time, with the least cost. If any of your enterprise system components or layers do not directly support this payload, or do so at an exorbitant cost, then you must ask yourself why that component or layer exists.
And, like a rocket, you must pay a price for all the infrastructure you are supporting through development, licenses, service fees, professional services, and the like. And you will pay a fee proportionate to the amount of infrastructure you have deployed for the life of your enterprise platform.
I would therefore encourage anyone that is contemplating enterprise system design to understand the full weight of the infrastructure, and target the right balance of cost and reliability to accomplish what really drives value in your enterprise. Good engineers will look at this problem scientifically, and create an enterprise system that truly values infrastructure based on cost and reliability.
Even if systems are designed to minimize abstractions and infrastructure, many are plagued with a third pitfall called implicit dependencies. We’ll tackle that next time.
About Mark Loyd, President, Jonas Chorum
Starting his technology career in the late 90’s as a software developer for a property management system, he quickly worked his way through the ranks and entered his first leadership position in 2000, managing a team of five developers. Twenty years later, having served as COO, CSO, CTO, and now President, Mark leads a talented team of 120 people that follow his passion and vision in making Jonas Chorum a technology leader in the hospitality industry.
