0

Integration Laws

I should start out by saying that this blog article is NOT about the High Performance Computing and Communication Act of 1991 which resulted in the National Information Infrastructure (NII), or the Enterprise Integration Act of 2002(1), or the U.S. National Intelligence Strategy for sharing information which is derived from the Intelligence Reform and Terrorism Prevention Act of 2004(2). I am not talking about man-made laws, but rather about laws of nature like gravity and electromagnetism.

Integration “Laws” are a way 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 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. I first published the five integration laws in 2002 in the EAI Journal and again in 2005 in the ICC (Integration Competency Center) book.  So for those of you who aren’t familiar with them, here they are again in blog format.

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 tackle relatively simple problems in short timeframes, 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 unworkable.

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 micro computers, 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 to replace the prior waves. In fact, a given technology will usually last 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

Too many software standards have the same effect as 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 1990’s 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 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 only have two states: Male or Female – 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, yet 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.

Notes:

(1) Enterprise Integration Act of 2002: Public Law 107-277 (116 Stat. 1936-1938) Authorizes the National Institute of Standards and Technology (NIST) to work with major manufacturing industries on an initiative of standards development and implementation for electronic enterprise integration, etc. Requires the Director of the NIST to establish an initiative for advancing enterprise integration within the United States.

(2) The National Intelligence Strategy of the United States of America is a product of the Office of the Director of National Intelligence.  Drafted and implemented in 2005, it describes the drastic overhaul the U.S. intelligence community will carry out. According to the strategy, the intelligence community will create a new system for sharing information, while integrating its existing enterprises to meet its objectives. The changes to the intelligence community derive from the 2002 US National Security Strategy the legal basis of which is the Intelligence Reform and Terrorism Prevention Act of 2004.

FacebookTwitterLinkedInEmailPrintShare
This entry was posted in Data Governance, Data Integration, Enterprise Data Management, Governance, Risk and Compliance, Integration Competency Centers and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>