Tech Talk

Recent posts

Enterprise System Pitfalls: Summary
Today I’m wrapping up a series of posts on the broad topic of Enterprise System Pitfalls. In this series, my hope was to help shed light on the primary problems that cause us to miss budgets, fall short on capabilities, or completely fail when implementing an enterprise system. 

The Year in Review
As 2019 comes to a close, it’s time to count our blessings. One of mine has been the privilege (and fun!) of being able to reach out to so many interesting companies and get them to tell me what they’re doing that’s different, disruptive, and game-changing. The list of things I have to write about in future columns has only gotten longer in the nine months since I started writing this column.

Sustainable Innovation
Sustainability can yield multiple benefits to hotels. Saving energy and water yields direct cost savings. Revenue can be generated by guests who prefer to deal with businesses that minimize their environmental impact. And many would argue that conserving scarce resources is simply the right thing to do.

Meetings Innovation
The sale and delivery of groups and meetings is perhaps the most significant and under-automated functions for many hotels. Even though groups often account for 30% to 60% of revenue, most group bookings are still handled manually for most if not all of steps, as they move from a meeting planner’s research to a confirmed booking.

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

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.


Enterprise System Pitfalls Part III: The Infrastructure Imbalance

by Mark Loyd
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.
Most pitfalls are rooted in a bad way of thinking about the problem and solution. We largely have forgotten the science behind the technology we implement, and underestimate or simply ignore the costs of our decisions and overestimate the theoretical value. This leads to over abstraction, and similarly to over investment in infrastructure.
Enterprise systems have become bloated with layers and layers of components, abstractions, and open source libraries all with the intention of creating a valuable infrastructure that can check all the boxes of a “good modern design.” Many of these components exist only to make other infrastructure components work, producing a recursive effect I would call going down the rabbit hole. “Good modern design” is relative, and a modern architect’s definition of “good” often does not correlate to real value.
I’m a huge fan of orbital rocket design, and even have apps on my phone that tell me when anything is launching into space. I have watched documentaries, binged on YouTube, and am a fanboy of the Everyday Astronaut. In rocket science, there is a very clear, visible and tangible cost of the weight of a rocket. The goal of a rocket is to launch as much payload as possible using as little fuel as possible into orbit, so every pound of rocket is a pound of payload lost. Because of this, the successful designs are ones that find the right balance between structural integrity and mass.
But what is the rocket really? It is simply infrastructure. The rocket has no direct value. The only thing of value is what it carries. When a telecommunication company needs a satellite in space to stream video to more people (from which they get money), there is direct, real, and measurable value of the satellite being in an operational orbit. And, that is the only value. The value of the rocket is based on the value of its payload. So, telecommunications companies select their launch vehicles based primarily on two things: cost and reliability. What else matters? Does the material of the rocket, the types of engines or how many stages matter? Only as it relates to cost and reliability.
Enterprise systems are very similar, but we don’t often look at it that way because we don’t see the problem as a scientific problem, though it really is a problem of science. We must design systems that move as much data as possible, as quickly as possible, with reliability. System components like databases, websites, service buses, libraries, abstractions, APIs, ORMs, services, etc., all have no direct value. The thing of value in information systems is processing and moving information, and delivery of the information in the right form, to the right place, at the right time, with the least cost. If any of your enterprise system components or layers do not directly support this payload, or do so at an exorbitant cost, then you must ask yourself why that component or layer exists.
And, like a rocket, you must pay a price for all the infrastructure you are supporting through development, licenses, service fees, professional services, and the like. And you will pay a fee proportionate to the amount of infrastructure you have deployed for the life of your enterprise platform.
I would therefore encourage anyone that is contemplating enterprise system design to understand the full weight of the infrastructure, and target the right balance of cost and reliability to accomplish what really drives value in your enterprise. Good engineers will look at this problem scientifically, and create an enterprise system that truly values infrastructure based on cost and reliability.
Even if systems are designed to minimize abstractions and infrastructure, many are plagued with a third pitfall called implicit dependencies. We’ll tackle that next time.
About The Author
Mark Loyd
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. 

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

 Security code