Tech Talk

Recent posts

In today’s fast-paced business world, there are still many employing tools of the past.  Are you one of them?  Let’s look at one service available today that should help you save some money and take steps to solve a growing industry problem; recruiting, training and retaining competent team members, especially in the accounting field.

In this fourth post in my series on Enterprise System Pitfalls, I’m going to discuss a conceptually difficult topic called Implicit Dependencies. I reiterate to my R&D team all the time that complexity is our number one enemy, and that dependencies have the most significant impact on complexity. Most architects understand that dependencies create complexity, and it is one of the primary reasons there has been such a shift away from monolithic design. Interwoven dependencies inside a monolith is the reason updates begin to be very difficult. A change in one area of the system can have a negative side affect in unexpected ways in unexpected modules. Many times, a small update will require an entire system build and deploy, slowing down our ability to improve the system quickly, or to create smaller independent teams. Most of these problems trace back to dependencies. Well, that and poor system design, but let’s just focus on dependencies.

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.

Today I continue my series on enterprise system pitfalls and discuss the problem of over abstraction. Be sure to read my previous post which lays the foundation for this series.

Are we getting the economic return we should be with new technology innovation? In this article, I’m starting a series reflecting on common weaknesses in enterprise systems development, and am going to try to unpack as concisely as I can these pitfalls we fall into.  We’ll analyze why we stumble into these problems, our struggle recognizing the root causes, and the results.

want to read more articles like this?

want to read more articles like this?

Sign up to receive our twice-a-month Watercooler and Siegel Sez Newsletters and never miss another article or news story.


Enterprise System Pitfalls Part III: The Infrastructure Imbalance

by Mark Loyd
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 The Author
Mark Loyd
Jonas Chorum

Mark has two passions… technology and the outdoors. Starting his technology career in the late '90s 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 5 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. 

Blog post currently doesn't have any comments.
Leave comment

 Security code