In a recent visit to a client, three people asked me to autograph their copies of Integration Competency Center: An Implementation Guidebook. David Lyle and I published the book in 2005, but it was clear from the dog-eared corners and book-mark tabs that it is still relevant and actively being used today. Much has changed in the last seven years including the emergence of Big Data, Data Virtualization, Cloud Integration, Self-Service Business Intelligence, Lean and Agile practices, Data Privacy, Data Archiving (the “death” part of the information life-cycle), and Data Governance. These areas were not mainstream concerns in 2005 like they are today. The original ICC (Integration Competency Center) book concepts and advice are still valid in this new context, but the question I’d like readers to comment on is should we write a new book that explicitly provides guidance for these new capabilities in a shared services environment?
“For starters, integration is a process. More important, it is not a one-time process, but rather an ongoing activity, because the applications that are being integrated continue to change over time.
This independence is necessarily driven by “a separation of concerns,” which is in turn a reaction to IT complexity. As complexity increases, it becomes necessary to break the problem into smaller, more manageable pieces; we call each manageable unit a system.
Applications (or simply systems) may themselves consist of other smaller systems, which are referred to as subsystems. An enterprise therefore has a hierarchy of systems; the collection of systems at the highest level is known as the enterprise application portfolio. The applications in the enterprise portfolio need to interoperate with each other and with the systems of external customers or suppliers. This highest level of integration within an enterprise is the scope of the integration competency center— the topic of this guidebook.
It is important to reinforce the point that a “system” is a logical concept, which means that it is subject to interpretation; in other words, a system is whatever you think it is. The implication of this statement is significant and helps to explain why developing the enterprise application portfolio is more of an agreement process than an analytical process. That said, it is useful to define a system as having one business owner, one IT owner and one architect responsible for it.
A further implication is that a change in organizational structure may change the application portfolio. For example, if a business unit splits into two separate functions, what was previously considered one functional system supporting the unit may now need to be considered two separate functional systems.
The collection of interfaces and middleware components that support the data movement and process interactions between systems in the application portfolio are called integration systems. Technically speaking, integration systems are similar to business systems: They are a collection of hardware components, software components and data to support specific processes. The difference is that integration systems generally serve IT functions and cross-functional business needs rather than specific business units. From a technical perspective, five broad integration patterns can be delineated:
- Data-oriented integration for consolidating and aggregating business intelligence
- Message- (or file-)oriented integration for copying data to one or many systems
- Process-oriented integration for managing long-running cross-functional business processes
- Service oriented integration for handling real-time request/reply transactions between systems
- Portal-oriented integration for providing a common end-user access to multiple systems
Each of these patterns may involve special protocols, standards and technology. The computer industry’s “holy grail” is to achieve a unified architecture for all five patterns, but as with Albert Einstein’s lifelong search for a unified field theory that combined nuclear, electromagnetic and gravitational forces, a unified integration architecture is not likely to emerge in our lifetime.
It is possible, however, for an ICC to establish the equivalent of a unified integration architecture within a given enterprise. When done well, this architecture will result in more efficient operations and rapid implementation of changes.” End of quote.
Once again, the ICC book is available in Kindle format from Amazon and iPad format from iTunes. We would very much appreciate your input. Should we write a new book? And if so, what questions or topics would you most like to see us tackle?