Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
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.
View all posts from ken rugg on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.