Tech Talk

Recent posts

During these trying times we are seeing a meteoric rise in cyber security threats targeting user credentials, financial information and sensitive business data.  The current environment presents specific risks and opportunities for hoteliers.  Identifying and addressing these risks has not yet garnered support from the top of the hotel’s management structure.  This must change and will before long.  It is vital that hoteliers take this opportunity to review their data security processes and procedures in order to close the threat vectors.  The coronavirus pandemic has shone a light on serious process and technical security gaps that lead to an increase in the probability that hotels will suffer catastrophic data compromises. 

It may be quite some time before hotels start buying technology again. There will be exceptions, to be sure, but for now they will be few and far between. And as much as I have enjoyed highlighting pockets of cool innovation in this column over the past year, very few readers will be able to act on those insights in the current environment. So while I hope to be able to return to my old format sooner rather than later, I’m going to change focus in this and upcoming columns. I’ll instead talk about what hotels, technology providers, and displaced technologists can do today.

During this challenging time, remember that your people need even more emotional connection.

Well, I had a topic all lined up for this week’s column. I had completed most of the research and sat down on Monday to start writing. But with all that is going on in the world, I decided to put that on the shelf for a cycle or two. No one is going to take the time to read anything right now that doesn’t talk about the novel Coronavirus and the COVID-19 disease. So, I started afresh and will diverge from my usual approach.
 

Last week, the World Health Organization announced that COVID-19—the viral disease that has swept the globe and killed more than 8,200 people—is officially a pandemic. And on Saturday, the Trump administration extended the ban on foreign nationals from certain European countries to include those traveling from the United Kingdom and Ireland. Industry conferences and meetings have been cancelled or postponed, and many companies are electing not to require employees to travel.



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 IV: Implicit Dependencies

11/04/2019
by Mark Loyd
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.
 
With a desire, then, to reduce complexity, we endeavor to reduce dependencies. The advent and adoption of microservices resulted from this push away from monolithic design, and an attempt to do exactly this. However, do microservices really solve the dependency problem? Not really. Microservices give the appearance of independence, but rely heavily on other services in addition to dependencies that are pushed into coordination, transaction management, and the like. There have been many attempts to architecturally solve the dependency problem without eliminating these implicit dependencies.
 
The right architecture must be determined by first understanding the true sources of complexity. And in the vast majority of microservices implementations I’ve seen, the architecture fundamentally didn’t solve the dependency problem it set out to solve. I also believe that many, if not most, systems can eliminate most problems by addressing design flaws rather than moving to microservices.
 
In order to build the right architecture, implicit, or hidden, dependencies must be understood. And understanding is actually pretty simple. Anything that is shaped specifically, or anything that cares about content is a dependency. As an example, an API function that has specified values as parameters is itself an implicit dependency. Not only the information it sends and receives, but the contract itself is a dependency. This is why the best APIs are simply a function accepting a string and returning a string. This removes any implicit dependencies in the API itself, and it can truly remain version-less, which is ideal decoupling.
 
Consider comparing a simple telephone to a SOAP XML interface written with XML validation routines. Both are intended to transmit information. In the case of the telephone, the phone could care less about the language of the speaker or any of the words spoken. It does not care about any new words or other changes in communication. There are no implicit dependencies in the phone. However, implementors of the XML interfaces (arguably designed to simply facilitate communication like a phone) felt they had to check the content of the XML before passing it to whomever actually acts on the content. This XML validation means the interface cares about the information. Why? Good question. Someone thought it was better to reject data at the transmission layer than leaving it up to the system that really should care. Regardless, this is a great example of implicit dependency. These implicit dependencies became the standard way to implement XML, became a major problem, and is likely the greatest reason people think they should move away from XML interfaces. XML isn’t the problem, the dependencies are.
 
Now consider if an architect has created too many layers in a bloated infrastructure (see my previous post on the Infrastructure Imbalance), complexity is compounded when these needless layers contain implicit dependencies. 
 
In order to build scalable and affordable enterprise systems, be diligent to remove any implicit dependencies, starting with making sure the shapes of your components are the least specified as possible, and that they don’t care about information they are not designed specifically to act upon.
 
In my next post, we’ll examine our biggest enemy in enterprise systems: complexity.
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