Welcome back. In our last post we welcomed you and described the purpose of this serious of blog posts. Â Before we get to far along I want to take a minute to lay a foundation for some of the motivations which drove our implementation. The architects at KNB Integration have been involved in dozens of major corporate IT projects at Fortune 500 companies over the last 10 years. We have designed systems from the ground-up, Â modified existing systems, integrated systems and perhaps most importantly oversaw the maintenance of these systems. We have learned an immense amount during this time and made our fair share of mistakes along the way to. What follows is a distillation of this knowledge, as it applies to the project which is the focus of this series.
One of the main tenets of system integration and modern software development as a whole is loose coupling. By creating simple interfaces between classes, components or entire systems, we help to insure that when an individual entity, component or system changes, those changes do not create a ripple effect, Â impacting other systems throughout the IT landscape. I believe it would be difficult to find any credible software architect who would argue with this.
The challenge arises when attempting to integrate with an existing system that does not provide a simple loosely-coupled interface. In this situation it is not uncommon to see some architects abandon loose-coupling altogether in favor of Â the approaches with which they are Â most comfortable. Â Their rationale being that they’ve seen projects succeed before with these techniques and they are confident they are can replicate this success again. Â Often times, this is the architect who sees a project from inception to production deployment and then moves on to another project. He is not usually the architect who stays around to maintain the system, for if he was, he would know thatÂ while money may be saved up front with such an approach, it is paid back with interest when the system maintenance activities are needed.
A very common example of this sort of tight-coupling is seen when an application exposes it’s database to external consumers. Whether it be via database links, remote JDBC/ODBC calls, data replication, or what have you, the result is that the internal implementation details of the application are now part of a system-wide contract. Â This can have a number of negative implications, most of which will land squarely on the application support team. Application maintenance activities become very challenging as small changes to one system can ripple through-out the landscape and require multiple simultaneous deployments. In some cases, the other teams impacted by this are simply unable to accommodate any additional work or unwilling to make changes to their system which will have no benefits for them in which case real problems arise. Managers will start to use terms like “temporary workaround” in these situations. In a faced paced IT environment, it is well known that few “temporary” solutions actually are. Technical debt is therefore acquired and once modern, viable, systems slowly but surely begin their gradual demise into legacy systems. Â These are the systems that none of the experienced individuals want to work on. Â The ones Â that eventually need to be replaced because they have become too costly to maintain.
This is the scene that plays itself out time and again in the corporate world. It doesn’t have to be this way. And it doesn’t take bold new initiatives to counter. It simply means using that basic design principle we’ve already mentioned; Loose Coupling.
So how exactly could loose coupling have helped? What might be a better approach to integrate with a system that doesn’t provide anything other than it’s graphical user interface?
In our next post we will begin to answer this question by finally showing our real-life example and offering up our solution for your reading enjoyment.