The biggest enemy to any system is complexity. In a system of inputs and outputs, such as an enterprise system, more complexity means more parts are used in interaction with inputs to create the outputs. Every part that must be built and maintained costs time and money. If we were to look at this from a risk perspective, every part that a process is dependent on is a risk. Each part is a risk of being broken, functioning unexpectedly, or adding time or other variable to the mix of parts that must function in coordination in order to get the expected result. When using probability to calculate total risk, it is a function of multiplication, meaning that each part adds exponentially more risk. Think of it this way: each part doubles the likelihood of failure.
Albert Einstein is attributed as saying, “Everything should be made as simple as possible, but no simpler.” Antoine de Saint-Exupery said, “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” At this point, most readers are nodding their heads in agreement. If so, then why do we have such overly-complex enterprise systems? The problem lies in how we think. Humans process things in a linear manner based on analogy. Most of the time, we solve problems by forging ahead, and not stopping, returning to principles, and making the simplest decision.
In my last blog, I addressed the common misconception that microservices by nature reduce dependencies. In my experience, this isn’t true in nearly all implementations. But most modern enterprise system architects believe by linear thinking and analogy that the problems of their old monolith will be solved with microservices. The typical results I see is that the dependencies become hidden (implicit), but not removed, and the system overall is exponentially more complicated. My last three posts on enterprise system pitfalls discussed problems that ultimately lead to complexity:
- Over abstraction: Creating abstract layers between specific functions adds significant complexity.
- The infrastructure imbalance: The more infrastructure code added to a system, the more parts and complexity is created.
- Hidden dependencies: Dependencies are one of the greatest contributors to complexity. We think the shape of our design removes dependencies, but most of the time we have implicit dependencies all over the place.
When you add it all up, the greatest negative impact of all these pitfalls is complexity, which leads to missing deadlines and blowing up budgets. We need to rethink our approach to problem solving. When asked how SpaceX built their prototype rocket in less than 6 months, Elon Musk responded
“The best part is no part. The best process is no process. It costs nothing, weights nothing, can’t go wrong…. The thing I’m most impressed with when we have our design meetings at SpaceX is what did you undesign? Undesigning is the best thing. Just delete it. That’s the best thing.”
If we are to build enterprise systems that meets or exceeds our business needs, we simply need to reduce as much as possible. When facing 2 solutions to a problem, do what is fast and least, not what is “right” in the eyes of the engineers. Engineers needs to change their perspective on what is right. Fast and simple is less expensive, completed on time, and done. This is right. In any engineering endeavor, maintain disciple to view things this way, and you’ll have a working platform very quickly.
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.
