3 tips to help you with software integration problems

Tuesday, November 09, 2010 gc 1 Comments

In my last post, what is the most difficult problem in software development?  I made the case that integration problems are the biggest challenge to software development and can be detrimental to a team's mojo.

Here are three tips to help you avoid and deal with software integration problems:

1. Use proper solution structure

In Visual Studio, use a single solution when possible. That is, put all projects in a single solution file. It is a great practice. It will help identify dependency problems, make refactoring easier, and improve integration. You will know sooner when an problem is introduced. Not all teams and projects can operate within a single solution. Here are a couple of MSDN references that provide more detail.
http://www.microsoft.com/learning/en/us/book.aspx?ID=12863&locale=en-us
http://msdn.microsoft.com/en-us/library/ee817679.aspx#

In many projects, I find teams using a solution for every assembly and trying to do integration manually. A single solution is more often feasible. This topic deserves more attention, because the decisions that you make about your solution structure can help or worsen integration.

2. Use continuous integration

What is continuous integration? The practice of continuous integration relies on the use of a software agent that monitors code commits, once a commit is identified, then the automated build process is performed, if the build succeeds then unit testing is performed, packaging, code analysis, metrics, etc. If all succeed, then the build is placed in a place for QA engineers and others to obtain. It is a part of Team Foundation Server 2010. In TFS 2008, it was provided via a CI plug-in.  There are a wide range of other tools and solutions.

Continuous integration is the easiest way to increasing a dev team's development velocity. And, the key to continuous integration is automation. I can't imagine an intense software project without using continuous integration.

Many teams have been practicing continuous integration for well over a decade.  I am sure some teams can go back decades. Today, the practice has evolved into continuous deployment and delivery. 
http://continuousdelivery.com/

3. Write an Integration Architecture Document

Clarity breeds success. Even if you think you understand what needs to be done as architect, it does not mean that everyone else does.

Here is the idea for your integration architecture document:

• At least one architectural viewpoint of where you are currently.
• At least one architectural viewpoint of where you want to be.
• A table of key components, interfaces, and owners.
• A high level strategy for integration--the sequence of events. This should probably include a strategy for mocking interfaces so that integration can occur before everything is integrated.
• Key integration points such as web services should be formally defined and reviewed.

There are many other types of architecture documents such as security, technical, business, but the integration architecture can be the most valuable. It is especially needed for projects that are beyond 5-10 developers.

This tip is, perhaps, the most important to avoiding integrations late in the project when the impact and tension are high.

At times when I thought I could get away without writing an integration document, I wish I had.

Do you have any tips for dealing with integration problems?