Fallacy #8: The network is homogeneous

Interoperability is painful.

Around 2005 or 2006, it wasn’t so bad. Most of the code running on the planet, at least the code that mattered, was written in .NET or Java, and interoperability via web services was at least serviceable. Since then, things have gotten gradually worse.

First came Ruby and Ruby on Rails. In the early days, it did not support web services like other platforms did. Next came the dawn of the NoSQL movement, driven at least partially by large companies with no incentive to interoperate. Google built BigTable, Amazon built Dynamo, Facebook built Cassandra, LinkedIn came up with Voldemort. None of these things can talk to each other.

Then came REST, or in other words, “something I invented myself over HTTP.” Each RESTful endpoint is that developer’s definition of what REST means, which is different from what every other developer thinks REST means.

Competitive pressures, together with companies’ desire to create vendor lock-in, suggest that we can expect more divergence to occur in the future.

🔗Semantic interoperability

The true challenge of non-homogenous networks lies in semantic interoperability. This simply means two different players truly understanding the meaning of the data that they’re passing around.

As an example, let’s take nullability. Consider for a moment a software system for a hospital emergency room. Unfortunately, patients sometimes arrive unconscious, unable to provide all of the information we’d like for their patient intake form. Thus, in the hospital ER system, birthdate is a nullable field.

Now consider a software system for a pharmacy. There are many rules that control what patients can have access to different pharmaceuticals. Some of those rules involve the patient’s age.

The ER system contains null birthdates, and the pharmacy system requires it. How do we integrate these two systems?

🔗Solutions

Unfortunately, there are no easy solutions for these problems. The good news for us as developers is that it likely will provide us with job security for a long time to come.

The only real recourse we have is to get business stakeholders in a room together with developers to hash out the problem domain. We have to budget and plan for this, and generally, it will take a lot more time than you might think.

First, it can take a long time just to get the right people in the same room and talking to each other. Once you do, you may even find that business stakeholders will start to argue about the problem domain. People from different departments may get into a fight about what the definition of a patient is. How can we design software for something the business can’t even agree on?

In any case, this is not an argument you want to happen two weeks before you go live.

🔗Summary

Technologically, we live in a diverse world, and challenges are likely to increase as that diversity increases. Software is eating the world, and somebody has to get all that software to talk to each other.

That’s where we come in. There are no easy answers. As developers, it falls upon us to get business stakeholders together as early as possible to hammer out these problems before they become showstoppers.

We just have to work through the problems, using the tool located between our ears as best we can.