Tech Talk

Recent posts

If Elon Musk Was A Hotelier
Posted: 09/25/2020

What if a person of Elon Musk’s character and bravado were to enter the hotel industry? How would they shake things up and presage the next ‘game-changers’ to propel hospitality beyond our current challenges?

Things right now are hard to predict. That is a fact. Trends lack patterns. Strategy is a 6-month viewfinder. Leaders are in a tactical storm. We feel overwhelmed by the unknown and the feeling of “what is next.” 

Over the past six months, this column has focused mostly on hospitality technologies and issues that were triggered by COVID-19. Innovation has flourished during that time, from both established industry technology providers and from startups. At last count I had identified nearly 300 startups in the space since the beginning of the year, some of them with very interesting technologies.

As outlined in our previous article, cleanliness is dominating the headlines within the hotel industry, with a number of press releases on new initiatives from all the major chains. The landscape has transformed quickly, to help keep up with the standards this article will summarise the basic principles of cleaning and sanitisation of guest rooms and how that can be achieved quickly, easily and cost-effectively.

Decreasing Stress
Posted: 09/14/2020

Stress does not come without your invitation. It is self-induced by our perspectives of what is occurring in our lives. We all have stress, and the less of it, the more happiness you experience. Life is about living day to day.



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