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.
Abstraction has long been a concept of computer science, and using abstraction is useful and makes sense in some situations. But, like most pitfalls of enterprise systems, the complexities of abstraction are not always obvious, and most architects ignore or simply don’t understand the hidden costs.
I think it’s important to understand fundamentally what most any form of abstraction implies. I would break it down into these terms: translation and representation. First, an abstraction explicitly or implicitly must have a translation from the source, and then the abstraction itself becomes a representation of the original meaning.
Spoken language is a good example of both translation and representation. When translating a speech from one language to another, there is never an exact representation of the original language after translation, unless the original phrase is very simple and if the languages are very similar. This is due to the fact that the nuance of spoken words is implied, and there are many uses of words in the original language. Much of the meaning is derived and not simply communicated in the words. You must take context, know the specific region and personal history of the originator of the speech, and many other complex variables. As such, in the case of translated spoken language, full original meaning is many times lost, misunderstood, or misrepresented. Now the translation is representing the original meaning, but insufficiently. A consumer of the translation now has an imperfect and less meaningful understanding of the original speech.
If you are familiar with the history of the language Esperanto, you are likely already making the connection here. Esperanto is a written/spoken language started in the late 1800s attempting to make a logical common language to simplify translation. It creates an abstraction layer between 2 systems designed to improve and simplify communication. Though much energy and resources were put into it, it has ultimately failed in wide adoption. You can read about Esperanto on Wikipedia.
Abstraction in the computer science sense has the same problems innately. Anytime we traverse an abstraction layer, we must understand there are costs. There is a loss of total meaning. There is now added maintenance to translation to make sure the target representation matches both explicit and implicit meanings of the source. And anytime the source changes, we must invest into fixing what inevitably turns into broken translation. In the meantime, the abstraction now mis-represents the meaning of the originator, and consumers of the abstraction are effectively dysfunctional.
The famous HTNG integration spec is a case in point (if you’re operating in the same industry I am), and a great attempt to make the Esperanto of hospitality systems. The goal of HTNG was to create the one-size-fits-all abstraction between hospitality technology systems. A bunch of really smart people came up with as perfect an abstraction as they could, and it was not perfect. Why? Not because of lack of knowledge and experience of its contributors, but because the abstraction was translating and representing many sources that have different explicit and implicit meanings within their source systems. Though the desire for producers and consumers alike was a magic plug-and-play integration, such integration is simply not mathematically possible. There are real costs to abstraction.
So why do we use so much abstraction? The arguments for abstraction and rudimentary POC-type demos are built to sell the promise of reduced problems with more layers of abstraction, and we can download open sources layers that claim to fix problems with added layers, but we do not weigh the predictable results scientifically. Rather, we accept the over-simplified model while underestimating the cost.
Most modern development approaches now have many abstraction layers, all built with an ideal in mind which doesn’t weigh the true cost. It is uncommon to see any real effort to reduce abstraction. In fact, it is normal to see a growing number of multiple layers of abstraction within the standard functional layers of enterprise systems. This is not innovation. It is thinking about things the wrong way and ignores the lessons of Esperanto and lacks objective scientific review.
The pitfall of over abstraction leads to many problems related to cost, and one of the most obvious is what I call the infrastructure imbalance, which we’ll be exploring in my next post in this series.
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.