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 start by reading the first posting.

Most Lean practices refer to this principle as “defer commitment” or “decide as late as possible“. The general concept is to wait as long as possible until you have the maximum information before making a decision that would be hard (or expensive) to reverse. Agile software development makes effective use of this principle.

A concept that is closely tied to this idea is mass customization which includes practices such as

• a) designing products that are based on standard components and are customized, assembled or configured for specific users,
• b) reducing setup times to enable small batch sizes (even batches of one), and
• c) leveraging the supply chain to achieve just-in-time inventory management.

In the realm of integration, it is more relevant to think of this principle as planning for change and there are several key techniques which can be leveraged to enable it.

First, break dependencies between components to enable each component (or system) to change without impacting others. Loose coupling is one of the most highly valued architectural properties – especially at the enterprise level. Despite the qualifiers in the previous waste section about applying middleware blindly, middleware technologies are one of the most effective ways to achieve loose coupling, and thereby help to break dependencies between applications.

One of best examples of loosely coupled systems can be seen in the typical supply chain. Business-to-business (B2B) interactions are made possible by industry standard data definitions, common protocols, and tools which handle process orchestration as a separate layer from the business applications. In other words, B2B interactions often include at least three types of middleware abstractions; 1) canonical data models, 2) common transport, and 3) orchestration layer. Achieving loose coupling within an enterprise between vendor-purchased applications can be achieved with the same kind of middleware infrastructures.

Second, make it easy to rebuild integrations at the “push of a button”. The reality is that you never build an integration just once. You build it many times – and in fact it is common practice to rebuild an integration a number of times, even before the first production deployment since it isn’t until system integration testing that the “real” data definitions and quality issues appear. So if changing an integration is the norm, why not automate as much as possible to the point where you can quickly regenerate a production integration at the push-of-a-button.

Third, make decisions reversible. For example, let’s say you made a design decision to use an EII (Enterprise Information Integration) approach to create composite views of customer account data in real-time, only to discover through volume testing that the response time will not meet requirements. The alternative approach is to use an ETL solution with some of the customer account data replicated in order to achieve the performance requirements. Normally this would be a significant design change that would impact the overall project time-line if made late in the implementation cycle. However, if all the systems of record and data mapping rules are maintained in a metadata repository and if the data transformation routines are re-useable middleware components, then it may be possible to quickly reverse the original design decision.

Fourth, use mass customization techniques such that a given integration becomes more of an assembly process rather than a custom development effort. This certainly is the core idea behind SOA and middleware platforms, but it still requires discipline to execute it effectively. For example, most large IT shops have a common routine for doing customer address cleansing, but it is surprising how many teams don’t use it and reinvent their own which defeats the purpose of a common routine if it is not used everywhere. A part of the solution is to establish an ICC (Integration Competency Center) or a central team that is responsible for maintaining and enhancing the shared business objects and re-useable components on an ongoing basis.

Tune in next week for Part 5 in the series where I address the topic of speed and how to deliver fast by focusing on end-to-end cycle time.