Appendix B. Integration Laws1
1. John G. Schmidt and David Lyle, Integration Competency Center: An Implementation Methodology (Informatica Corporation, 2005), pp. 12–14.
Integration “laws” are ways of thinking about the fundamental drivers of integration. The laws reflect the reality of dealing with “systems-of-systems” (or complex systems) that are characteristic of enterprise integration. They represent the reality of “what is” rather than “what could be” and, just like the laws of physics, describe many characteristics of the real world.
An effective integration approach must not conflict with the integration laws. Although challenging them won’t land you in jail, ignoring them will likely add to the list of failed integration projects. As you start down the path of your ICC implementation, remember these five laws.
Law #1: The Whole Is Greater than the Sum of Its Parts
The notion of “process decomposition” is deeply ingrained in most analysis techniques used in modern software development life-cycle methodologies. It is based on the presumption that there are natural boundaries along which to divide a complex system into smaller components for integration. This approach comes from the reductionist perspective, dealing with one dimension of problem analysis.
While this approach helps with tackling relatively simple problems in short time frames, it fails as system complexity increases and natural boundaries disappear. All of the gains achieved by breaking down the big problem are lost as the cost of integrating the small solutions becomes untenable.
Most methodologies fail to realize that the essence of an end-to-end system cannot be captured by studying its individual components alone, and they fail to assign responsibility for the holistic solution. Or if accountability is clear for the initial construction of a solution, the solution can deteriorate if no one is responsible for sustaining the end-to-end processes on an ongoing basis.
Law #2: There Is No End State
Organizational entities split, merge, and morph into new structures. Political motivations and boundaries change. Technology evolves, and today’s leading edge is tomorrow’s legacy. An effective ICC approach must consider the full life cycle of a system and be based on best practices that recognize the adaptive nature of complex systems. From the start, we must plan for constant change.
Furthermore, ICCs must deal with legacy systems based on prior generations of technology. There have been many waves of application technology over the years that seem to move in regular seven-year cycles (e.g., mainframe to mini to microcomputers, monolithic to client/server to Web service applications, etc.). The shift from one wave to the next is neither instantaneous nor is it necessarily economically justified. In fact, a given technology usually lasts through several waves before it is fully replaced. Therefore, the ICC must deal with three to four generations of technology simultaneously.
Law #3: There Are No Universal Standards
Having too many software standards has the same effect as having no standards at all. Even successful standards (such as TCP/IP for the Internet) are not universal. When it comes to software standards such as COBOL or Java, interoperability and transportability come at the expense of vendor-specific extensions, forcing developers to use a less-than-ideal core set of “pure” language features.
The ICC should strive to define and adopt standards within the enterprise, but also work externally with standards organizations to gain agreement across the industry. That said, the ICC must deal with the reality that many forces—including competition, the “not invented here” syndrome, and evolving technologies—will result in many different standards for the foreseeable future.
Law #4: Information Adapts to Meet Local Needs
The information engineering movement of the early 1990s was based on the incorrect notion that an enterprise can have a single consistent data model without redundancy. A more accurate way to look at information is as follows:
Information = Data + Context
This formula says that the same data across different domains may have different meanings. For example, a simple attribute such as “Current Customer” can mean something different to the marketing, customer service, and legal departments. An extreme example is gender, which you might think could have only two states: male or female; but one particular enterprise has defined eight different genders. The same thing happens with natural languages (the various meanings that words adopt in different communities). The ICC must embrace informational diversity, recognizing that variations exist, and use techniques to compensate for them.
Law #5: All Details Are Relevant
Abstraction is the practice of representing a problem without all the details, developing a model solution based on the abstract problem, and then using the model to create the real-life solution. The success of this approach depends on our ability to build and use abstract models to manage and direct activities. But the effectiveness of an abstract model is inversely proportional to the complexity of the context, because no details can be safely ignored. The cost of developing and maintaining abstract models of the system and the project can become an economic black hole, consuming all benefits.
A successful ICC deals with this conundrum by decomposing the problem while maintaining a view of the entire picture. Although there is no easy solution, an effective ICC must strive to achieve dynamic models—models that are connected to the real world in such a way that when one changes, so does the other. Only then can we attain a truly sustainable integration infrastructure.