Software integration links software applications or databases together. Software integration can involve one large software application or absorbing several legacy applications or merely tying them together in a federation. In both cases, software integration creates icebergs – very large systems, with deep masses of data and assumptions lay underneath the single, somewhat visible mass. It is easy to mistake the small visible portion as the entire project, forgetting the collective history, database size, legacy rules and exceptions, megabytes of documentation and user standard practices that lie beneath the surface.
The path the software integration takes is similar to an iceberg, with many stakeholders and newly absorbed users creating inertia to hold the project to whatever path is has been on. As the size and the project duration increase, so does the inertia.
- As the number of stakeholders grows, the number of approvals required to make even minor changes also grows. More votes increases the odds of a critical stakeholder saying now.
- As system complexity grows, whether from more data connections or multiple configurations resulting from imported legacy systems, the volume of required testing increases.
- As the user base grows, the impact of an outage increases. The ability to take a system offline for a few hours generates more user screams, so weekly outages become monthly or quarterly. The rate of change slows due to the increasing size of the iceberg.
My father used to say that there’s only two ways to move an iceberg, one very determined tug boat for a very long time or a fleet of tugboats at once. The same logic applies to the integrated software icebergs. Change only occurs in two ways: everyone agrees to make the change at the same time and works together to pull off the momentous task or one person works very slowly to influence stakeholders over time to make the change. Both cases are difficult to achieve, which is why inertia is one of the fundamental rules of physics as well as human affairs.
Fortunately, industrial engineering gives us a ray of hope. Aim to keep the new system lean and agile over a conglomeration of existing tools, functions and systems – and thus prevent an IT equivalent of the Titanic disaster.