Tech Talk

Recent posts

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

Tracking the evolution of key performance indicators (KPIs) over time allows hoteliers to identify meaningful trends, create forecasts and budgets and assess the results of different strategies. To perform this kind of analysis, data has to be recorded within consistent time intervals and in chronological order. This is known as a time series.

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.



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.

x
 

Enterprise System Pitfalls Part II: Over Abstraction

09/09/2019
by Mark Loyd


By Mark Loyd

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 The Author
Mark Loyd
President
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. 


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



 Security code