Here 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.

A core principle of Lean and the Toyota Production System is continuous improvement through experimentation and learning. The general notion is that there isn’t a “perfect” way to do something. Rather, there are always opportunities for improvement that can be uncovered using scientific disciplines.

As described by Poppendieck(1), the scientific method in general follows these steps:

• Observe and describe a phenomenon or group of phenomena.
• Formulate a hypothesis to explain the phenomena.
• Use the hypothesis to predict something—the existence of other phenomena or the results of new observations.
• Perform experiments to see if the predictions hold up.
• If the experiments bear out the hypothesis it may be regarded as a theory or rule.
• If the experiments do not bear out the hypothesis, it must be rejected or modified.

This breaks down to the more simplified 4-step method prescribed by Deming; Plan, Do, Check and Act. Most Lean practices focus on building knowledge but I prefer to put the emphasis on sustaining knowledge which incorporates the idea of ongoing maintenance and nourishment. There are a number of ways this principle can be applied to integration activities.

First, standards should be challenged and improved. A corollary to this principle is one of the five EAI Laws(2), “There are no universal standards”. Standards are in fact essential for a Lean integration, but it is a mistake to consider them to be fixed, static, un-changeable and applicable in all situations. Industry standards such as COBOL, TCP/IP and HTTP (to name just a few) have evolved significantly over the years. Enterprise integration standards also need to be sustained and evolve over time.

Second, Lean practices put a strong emphasis on scientific methods. One of the reasons this is so important in the integration arena is that we are often faced with the challenge of achieving alignment across multiple independent teams or organizational functions. Gaining agreement across groups that don’t usually work together is hard. In the absence of data, all you have is opinions, and gaining agreement between people with different opinions that are filtered by paradigm-colored glasses is virtually impossible without objective data. A particularly useful, and practical, technique for data driven cross-team problem solving is Management by Fact (MBF) which will be described in a future posting.

Third, integration dependencies between components should be maintained in a structured, and searchable, repository rather than in static unstructured formats. Your first reaction might be that this is unnecessary since your organization already has a mandate that each project develop detailed documentation about all information exchanges between components. In which case ask yourself these questions:

1. Does the documentation reflect what was deployed to production including changes made after the design was completed?
2. Would a typical business analyst, designer, or developer be able to find the documentation two years later? Five years later? If the original author of the documents is no longer with the company?
3. If they do find the documentation, would it be understandable? In other words, are the graphical notation conventions the same for all documentation and are they based on a common glossary and taxonomy for data objects?
4. If maintenance changes were made to production after the project was deployed, was the documentation updated to reflect the changes?

If you answered yes to all four questions, then you already have the necessary discipline for this particular aspect of sustaining integration knowledge. If you answered no to one or more questions, then you are wasting time every time you need to change something and need to re-create yet another version of a custom integration document.

Tune in next week for Part 4 in the series where I address the topic of planning for change based on Lean principles.

References
1. Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2007.
2. John Schmidt, The EAI Laws, Business Integration Journal, July 2002