SOA: The New Tower of Babel

The Tower of Babel was an engineering marvel that failed nonetheless. Like the great tower, SOA represents a revolution in “infrastructure,” the very scope of which threatens its success.

According to the biblical account, before the Tower of Babel was built, to glorify the city of Babylon, everyone spoke the same language. The architect’s vision was to have the tower reach the heavens as a way to make a name for the citizens of Babylon. Unhappy with the motivation for the construction, or so the story goes, the entity upstairs decided to “confuse their language” and make it impossible for the people of Babylon to communicate successfully to complete the tower.

Without the ability to communicate the people were unable to take advantage of the great infrastructure and they were ultimately scattered far and wide, losing not only their tower, but their community.

Like the Tower of Babel, SOA infrastructure projects begin with a vision predicated on successful communication. It seems reasonable to try to get all the applications and services to speak the same language; just wrap components in well defined service interfaces using industry standard WSDL and all the pieces will be able to talk to one another.

Unfortunately, as with the Tower of Babel, things change. In SOA projects, however, it isn’t “divine intervention” that causes this change, but more mundane concerns. Systems are added to the integration project, new understanding is gained about the systems that are included, and existing systems are modified to accommodate new requirements. Before you know it, the systems no longer speak the same language.

I recently had a conversation with the CIO of a major telecommunications service provider. When presented with the idea of a common model-based approach to integration, he said that they had been trying for years to get everyone to speak the same language. The problem was that every time a system was added, it brought along new requirements, and they essentially had to create a new “common model” to accommodate it. The old systems couldn’t speak the new dialect and they had no tools to find the dependencies and integration code in their systems that would be impacted by enhancements they made to the model to support the new systems.

Because of this, the old common models and technologies used to transform in and out of these models needed to be maintained. They used multiple versions of the “standard” messages to communicate between services, thereby ensuring that there were no standard messages. The integrations were effectively “scattered throughout the earth.”

SOA What? If you don’t want your SOA infrastructure to end up like the Tower of Babel, you not only need to have a common language to communicate between your systems; you also need tools that will allow you to accommodate change to that model over time.