This article is the next installment of the “10 weeks to Lean Integration” series.  If you are joining the discussion now, you may want to read previous postings starting with this one which includes links to related articles.

There are three basic strategies for improving quality:
1. Inspections, review or audits to ensure quality
2. Reduce cost of recovery to quickly fix problems that are identified
3. Build quality in by “error proofing” the process

Most organizations put the emphasis in that order – but this is a mistake. You can’t “inspect quality in”. By the time the defects are found the damage is done and the cost of fixing the defects can be quite significant. If it is relatively easy to reduce the cost of error recovery in comparison to error-proofing the process, then option 2 could be a viable strategy. However, the recommended approach is to not create the defects in the first place. Contrary to popular opinion, it is possible to create defect free code – even when an outsourcing partner is involved. Poppendieck provides a robust treatment of this topic in Chapter 8 of Implementing Lean Software Development(1). In addition, there are several techniques that integration teams can use.

First, mistake-proof the deployment process. Deployment can include the entire process of source code management and propagation of code from development to test to production. The best way to ensure that mistakes don’t happen (i.e. moving the wrong version, not including a dependent component, not synchronizing the changes with other dependent elements, etc.) is to automate the process. The general idea is to not allow human hands to touch the test or production environments. Instead, describe the changes you want to make in a repository that is integrated with a deployment tool, and when the deployment manifest is complete and the approvals are in place, then have the tool push out all the changes. Two very powerful features emerge when you have this capability; 1) you can make test or production releases much more frequently which allows development of code in small increments (small batches) which is one of the keys to improved quality and reduced cycle-time, and 2) it becomes much easier to reverse the change and roll-back to the prior production state if in fact a problem arises.

Second, stop building legacy code. Poppendieck(1) defines legacy systems as follows:

• “There are two kinds of software—change tolerant software and legacy software. Some software systems are relatively easy to adapt to business and technology changes, and some software systems are difficult to change. These difficult-to-change systems have been labeled “legacy” systems in the software development world. Change tolerant software is characterized by limited dependencies and a comprehensive test harness that flags unintended consequences of change. So we can define legacy systems as systems that are not protected with a suite of tests. A corollary to this is that you are building legacy code every time you build software without associated tests.” (p. 166)

The lesson to take from this for middleware systems or components is to make them modular and testable. A corollary of this principle is that you should mandate integration requirements for new applications. That is, create explicit requirements for the ability of application systems to expose their internal functions through standardized and supported interfaces. The bottom line recommendation is to build the interfaces and test harnesses first – THEN build the rest of the integration code.

Third, perform integration continuously and not just during the life of the project. This is one of the fundamental premises behind an Integration Competency Center or Center of Expertise – that integration is a distinct discipline that requires the on-going focus and attention of a coordinated team in order to ensure that integration solutions, once implemented, don’t disintegrate. The best reference on this topic continues to be the Integration Competency Center(2) book.

Tune in next week for Part 8 in the series where I address the issue of optimizing the end-to-end processes – even if that means executing some of the activities in the process in a way that looks inneficient from the perspective of individual steps.

1. Mary Poppendieck and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2007.
2. John Schmidt and David Lyle, Integration Competency Center: An Implementation Methodology, Integration Consortium and Informatica, 2005

If you’d like to get Informatica blogs on the fly, just click the ‘Subscribe’ button on the right side of the screen.