It is the second lap that costs

It is the first change to your infrastructure that gives the answer on how good your architecture really is.

It is really hard to estimate to what level you should structure your integration projects in terms of architectural guidelines, documentation and organization. It often feels that structure is an obstacle that stops you from getting the project delivered in time and it is of course tempting to take shortcuts for documentation, testing, routines for installation and change. Most of us probably have an alternative where you ask someone in your company that knows the whole company and can fix it for you in a short time. This someone is often the person that knows all systems, people as well as techniques involved so well it’s not really worth doing any documentation since it is so obvious for him. Everything is all well so far.

The problem is that the people you work with during the projects lifetime and whom you are comfortable with when you take the shortcuts to gain the valuable time, are probably long gone when it is time for the first change or when the integration platform is outdated and you are standing there with n-number of integrations to be migrated to a new stunning platform.

But since most of us know all about taking shortcuts then we also know what usually happens when the day that always comes sooner or later appears. I am talking about the day when there is a reason for a change. Now is the time when we are suffering from the tactical delivery decision once taken, and all the “simple” integrations once deployed now appears like a huge question mark with undefined dependencies and unclear ownership.

Therefore even though spending a little time on documenting and do a proper handover to operations adds on some extra time initially you will benefit of this work later in the lifecycle of the solution. What appears obvious today and for your current team seems likely as a mess for your successors that are going to migrate your “old” unknown technology and associated undocumented integrations to a modern platform. This is when it starts to cost both resources and time which could have been used for more important tasks then to reverse engineer old solutions.

What is the definition of quality of processes, documentation and architectural guidelines then? Personally I believe there is an easy answer to that question. Your level of structure should be exactly as much as you manage to govern with the resources, time and budget you have available. I know the answer is easy to say but is hard to find what level best suits your conditions.

If you have a limited budget or set of resources and do not have the possibilities to ensure that your rules are being applied then don’t apply all the state of the art frameworks available. Keep it on a level that you know will be applied and used in real life but no less than that. Keep as a rule of thumb; Your level of structure and processes needs to be on a level so that you can assign an owner and responsible for the framework, principle or process you are enforcing. No less, No more.

Integration Framework describes components that we know by experience needs to be in place to ensure integration solutions that are cost effective during the whole lifecycle.

Posted in: •Integration  | Tagged: •Application maintenance  •Integration