Tech Talk

Recent posts

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.

HU talks with Bob Diachenko, the cybersecurity expert who discovered the breach, about steps hotels can take to prevent data incidents

A groundbreaking new report by the Urban Land Institute in Washington, D.C. explores sustainability in the hospitality industry and examines ways in which hotels are incorporating eco-friendly best practices into both operations and construction. The study includes insights from leading hotel owners, developers and investors.

Every hotel owner wants to know how he can increase the traffic to the website, and at the same time, boost direct bookings. The key to accomplish both the objectives is to design a site that is accessible even to disabled people. It will not only improve the usability for all types of visitors, but it will also improve your market penetration. Designing ADA website is also very imperative to prevent legitimate complications. In addition to this, an ADA feature will aid in improving the website performance in search engines.



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