System Innovations

--  Integration modeling, data warehousing, data strategy --

Home Books & Articles

Company Profile

Integration Modeling
(Excerpted from Laura's book:  Integration Models - Templates for Business Transformation (SAMS, 2000), this is part of an article that was first published in the proceedings of the World Multiconference on Systemics, Cybernetics and Informatics - SCI2000.  For more information contact, phone 770-953-0534)

Integration Modeling fills the gap between

Business Models (mental models, future scenarios, the revenue "S-curve" for market penetration, spreadsheets and bar charts, value chain & core competencies, and various implementations of quadrant or association matrix modeling)


Technical Models (entity relationship diagrams, decomposition diagrams, activity diagrams, statecharts, flow charts, data flow diagrams, use cases, collaboration diagrams, class diagrams, etc.)

IM techniques introduce a core of flexible models that are applicable across industries. Each of these models acts as a template, representing a particular dynamic, which we can harness to deliver improved integration. Examples are taken from actual practice in industries of transportation, telecommunications, financial services, software development and insurance.

Integration models were developed on integration projects carried out in companies doing business in diverse industries. They have been collected and formalized to provide a pattern language for integration. The templates embody common solutions to integration issues, providing a visual syntax for depicting and combining the elements of those solutions.


Integration Modeling provides a core of flexible models that were both developed and discovered on integration-related projects. Each of these models acts as a template or pattern, representing a particular dynamic that we can harness to deliver improved integration.

Similar to the pattern language represented in Erich Gamma’s Design Patterns – Elements of Reusable Object-Oriented Software [1], or its precursor A Pattern Language [2], Christopher Alexander’s treatise on patterns in architecture design, integration models formulate some common approaches to integration issues and present them as patterns in a catalog.

Where integration models differ from the design patterns cited above is that IM models are designed to provide an organizing principle for the modeling of integration issues and their solutions, whereas design patterns focus more on the design of physical implementation. Sometimes integration models are useful in the early and high-level modeling work of a project. Sometimes they filter down into detailed and physical design models, but generally their application is broad, and focused more on the dynamic context for systems building, less on the physical design of implementation solutions.

Integration modeling occurs at the intersection where business and technical modeling overlap, and runs throughout all levels and viewpoints, providing the glue that ties the pieces together that have been separated through analysis. Whereas technical models are analytical (i.e. separating out the components), and business models tend to be task-oriented (getting the job done), integration models are oriented toward clarifying the context. They capture multiple perspectives and may function on more than one level at a time.

Whereas CASE and object-oriented models observe rules that are used to define and master "the box", integration models are about getting "outside the box" without losing sight of it. They are about seeing the big picture without losing touch with the details.


Clarify Contexts

Integration Models help place the technology in the background and bring the business usage to the foreground. They accomplish this by treating systems as context, and focusing on the dynamics of systems interactions. Overall, does a specific business activity follow a cycle? Does it require a web of connections? Or does it contain layers of complexity? How does it function? Questions like these will help define which Integration Models are selected.

Capture Multiple Perspectives

Part of the role of integration models is to help us capture multiple perspectives. Because they are a flexible set of modeling templates, we can apply them in a variety of different settings. They can model the dynamics of a customer scenario, showing what’s important about how our customer might interact with our web site, for instance. Or they can be applied to the computer operations environment, depicting a series of computer systems and devices that support that customer interaction.

Function On More than One Level

Integration models can be utilized to focus in on significant details of a process or system, or to bridge across systems at a very high level. Again, this is because they concentrate on the dynamics of a situation, not on the implementation technology. The level that is captured depends on the perspective being described.

Cross Application Portfolios

Some companies place all the application systems that are used by a business area (for example Marketing, Finance, Operations, Sales, etc.) in a "portfolio", or suite of application systems, for that business area. Applications within a portfolio are more likely to be well integrated. Those in separate portfolios are rarely so. One of the roles of integration models is to provide a way to focus on aspects of doing business that take place across application portfolios.

Provide Placeholders for Infrastructure

When they cross the lines between application portfolios, integration models can highlight opportunities for economies of scale or reuse of a variety of technical assets.

They can also provide placeholders for pulling together an infrastructure. For example, during a Y2K analysis at a wireless services company, integration models helped one client get their arms around their equipment inventory so that their Y2K liabilities could be better understood.


While it is important to understand what integration models are and can offer, it is just as valuable to know what they are not and don’t attempt to do. Integration models do not replace any of the existing mechanisms of systems design, modeling and implementation that are in use today. They are not intended to do away with existing paradigms or to make them obsolete. However they do offer an enhancement to what current mechanisms provide. In providing pattern examples, integration models show how current models can be organized to improve their usefulness.

Not Modeling Notations

Integration modeling does not attempt to replace any of the existing modeling notations, although it can be implemented in virtually any of them. It offers patterns for organizing models developed in any notation, which can help clarify the dynamics of any model.

Not CASE or OO Analysis and Design Models

Integration models do not replace Computer aided software engineering (CASE) models such as those specified in John Zachman’s architecture framework [3]. Nor do they replace object-oriented models for analysis and design of systems. They can be used to provide an organizing principle for these types of models, and the resulting models will appear more coherent and meaningful in their visualization of technical design.

Not Business Models

Integration models can be used to organize a business model, but they are not the same as business models. Business models are task-oriented and often very informal, including such types as mental models and process models. Integration models provide a visual language that can be used to depict the integration aspects of business models, showing where a particular dynamic comes into play. They can be useful in organizing these models, but they are not a type of business model.

Not Rigorously Defined for Automation

The introduction of rigor is required to automate the process of developing technical models. Modeling tools require that the modeling notation be precise, strictly conforming to a set of standards, or conventions, which are built into the tool design as rules for model construction. The tools then offer varying levels of validation and enforcement of the imbedded modeling rules.

Integration models are not intended as a modeling notation or language, and intentionally avoid assuming the rigor that is required by tools for automation. Their goal is to provide a flexible background pattern that can be adapted to many different settings, and consistently applied.

Not One More Level of Detail or Abstraction

Finally, integration models are not intended to insert another level of detail or abstraction into the deliverables of a project. One of the issues that must be addressed when deploying modeling tools is that the level of abstraction they introduce presents a significant learning curve for the users of the tool. Integration models do not add to this problem by adding layers. They are applied to the existing levels of detail and abstraction to help tie them together.


Many companies find that today’s business environment presents challenges that require new tools and new methods of solving problems stemming from integration issues. For computer systems to actually deliver on the promises of automation - faster, better ways of doing business than ever before - these integration issues must be addressed.

The need for this new type of integration is becoming increasingly apparent as more companies get more of their processes automated. Sooner or later, they find that they have a need for solutions they can apply to applications operating across the entire enterprise. Hence the term, Enterprise Application Integration – or EAI, for short.

The market often defines EAI as the use of middleware that allows the rapid integration of legacy, packaged and new applications into new business solutions. We can broaden this definition a little by removing the reference to any specific implementation, and by including concerns that reach beyond specific application solutions to pre-defined business needs. And any meaningful definition must include the significant fact that EAI addresses the context for application systems as well as the systems themselves.

Traditional forms of integration typically place the emphasis on the computer systems and their internals and how to combine the technical components for efficiency. EAI includes the collaboration of technical components, but shifts the emphasis to the context in which those computer systems must perform, including the business goals and models.

Thus, a more comprehensive definition of EAI reads as follows:

Enterprise Application Integration is the process of placing hardware, software and business process in context so that when they are combined the interfaces between components become seamless, information can be easily shared and systems working together can achieve synergies.


Based on the experiences of many software projects, the catalog of integration models offers a distillation of best practices in the integration arena. Not intended as an exhaustive list, the models represent the patterns found useful on projects in many different industries.

The names and descriptions of the integration models are listed here to give you an overview:

  • Cycle - The Cycle depicts a life cycle or cyclical process, which is characterized by repetition, evolution, and the features of self-reinforcement and self-correction.
  • Seed - The Seed is a generator/transformer structure depicting a situation where a core component produces, collects, or contains an array of results.
  • Web - The Web template depicts a network of nodes (or endpoints) and connectors (or arcs). It is useful in modeling network routing and for performing complex path analysis and optimization.
  • Flow - The Flow template is utilized by process and flow analysis to trace the course of information, goods, services, communications, etc.
  • Wave - The Wave model is used to describe the layers of a system, environment or network. Layers help manage complexity.
  • Ring - The Ring is useful in depicting chaining of events, people, devices or network addresses. While the cycle models directional processes, the ring models peer-to-peer relationships.
  • Cell - Cell models support modeling of categorization and compartmentalization. They are useful for analysis of distribution systems, geographic division, and behaviors at the local versus global levels.
  • Tree - The Tree is a structure utilized to model systems with characteristics that include complex branching, diversification, and the implementation of distribution alternatives.


First they give us an organizing principle by providing patterns that have been worked out over time during experiences with other projects. As such, they comprise a sort of toolkit that we can take from one project to another. In formalizing the possible dynamics for a problem set, they support our thinking process and give us a set of options to consider when deciding how to model it. Integration models take us outside the current boundaries by focusing on the background and context for application systems. And they give us a unifying principle, which can carry certain themes from one level to another in the project design and documentation. Last but perhaps most importantly, they help us present technical concepts to non-technical people, in ways that convey meaning visually.


Integration model templates can be used to help clarify the dynamics of any model, whether in UML, CASE, OO or any other notation or language. They are not a notation in themselves, but are more like a background formulation of principles for integration. As such they might make a good set of "snap to grid" formats for tools to adopt.

Integration models make the models that are based on them tend to match each other, bringing an organizing principle to all levels in the project repository. They cover a broad spectrum of structures and are applicable at any level. They tell us how the current problem set might work, where it will likely go next, and what it’s characteristics are. Integration models can also suggest technological options. Some templates translate directly into OO design patterns (see book Design Patterns, by Gamma et al). For instance, the seed template translates into Gamma’s strategy pattern.


[1] Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing) by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch (Designer). Pub. (October 1995) Addison-Wesley Pub

[2] A Pattern Language : Towns, Buildings, Construction
by Christopher Alexander, Sara Ishikawa, Murray Silverstein. Oxford Univ Pr (Trade) – 1977.

[3] A framework for information systems architecture, by J. A. Zachman, IBM Systems Journal Vol 26, No 3, 1987

Add a comment

Return to Systems Integration

Return Home


[Company Profile] [Services] [Home] [Books & Articles] [Laura's Bio]

Copyright 1998, 1999, 2000. Laura Brown, LBPI, Inc. (DBA: System Innovations)
Last Updated: September 18, 2001