Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I work on and write about asynchronous messaging systems, distributed architectures, and all sorts of enterprise
computing and architecture topics.
Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.
First of all, my apologies for such a long pause in the ramblings. I can't believe it's almost been four months. It seems like I OD'd on writing a little bit while helping the Microsoft Patterns and Practices group write a book on integration patterns (see the MSDN Architecture Center). I am now on my way to Las Vegas to TheServerSide Symposium, a flight just long enough to ramble a little.
There are certainly multiple ways to classify integration styles. For example, I have definitely come across Database Integration, Shared Database, and Data Replication. You are just as likely to find references to Portal Integration, Presentation Integration, and User Interface Integration. The names are sufficiently similar to cause more confusion than clarification. Even Enterprise Integration Patterns gives two different overviews of integration styles, one in Chapter 1 and another in Chapter 2. Many other integration books also start with an overview of integration styles. So how do we bring some order into the world of integration styles? After some mulling around, I identified three different ways to classify integration solutions:
I think the intent of integration is a good place to start. By intent I mean a classification of the ultimate problem we are trying to solve. Are we trying to give all applications access to a consistent set of data? Are we trying to give the users a view into multiple systems in one screen? Are we looking to reuse a function or a piece of logic across multiple applications? When customers tell me they want to integrate their applications this is a good way to start. The important part is that these types of integration make no (or very little) assumptions about the technologies or mechanisms that are going to be used to accomplish the integration. We might move files, make SOAP calls or put messages on a message bus. It does not matter (yet). This type of classification is the one I tried to address in Chapter 1 of Enterprise Integration Patterns. I wrote Chapter 1 at the very end (a fairly common occurrence when writing books), so likely there is a more comprehensive taxonomy, but here are the types of intent I came up with (strangely, these integration types did not receive the honor of being patterns, a decision I would certainly revisit if I was writing the chapter again):
Each of these types has a brief definition, focused on the problem the integration is trying to solve rather than how to solve it. For example, Information Portals solve the problem of business users having to access more than one system in order to view all the information they need to perform a specific task. The solution is to create a portal application that shows information from multiple systems in a single screen. To that extend the solution is prescriptive, but how the data gets out of the applications and to the portal is (intentionally) left unanswered. That type of question is answered by another category of "integration style".
One of the key goals of an integration solution is to extract data out of one existing application and move it to another application. In order to do this, you have to connect the application to some form of integration backbone so that the application can participate in the exchange of information. This is the function that is commonly performed by commercial connectors or adapters that are being offered by many integration vendors. When we try to classify these adapters, it becomes apparent that the type of adapter matches the layers of most contemporary business applications. Most well architected business applications have a presentation layer, a business logic layer and a database layer. We can use each of these layers to move data between the application and the integration backbone. Correspondingly, we can define the following types in integration (see picture):
In the soon to be published book by Microsoft's Patterns and Practices group, we discuss these integration styles under the heading of System Connections. In Enterprise Integration Patterns, we touch on these styles under the Channel Adapter pattern (this Web site does not show that portion of the pattern, but it is in the printed book). Two things are noteworthy here. First, how I connect to an application is often a fairly local decision. When I receive a message (assuming for the moment I use message-based integration), it is largely of secondary importance whether I stick this message into the database (Data Integration), whether I call the application's API (Functional Integration) or whether I emulate a user entering data into a screen (Presentation Integration, aka "Screen Scraping"). Second, which mechanism I use is largely independent of the overall intent of my integration. I can certainly envision building an Information Portal using Data Integration, Functional Integration, or Presentation Integration, or a mix of all three! For the more mathematically inclined, if I was going to define a matrix across the two axes of integration intent and connection mechanism we will find that the matrix is reasonably densely populated. There might be some fringe cases, for example, performing Shared Business Functions via Data Integration, but if you have been building integration solutions for a while you will agree that nothing is unheard of! In fact, one of the favorite methods of connecting with one of our favorite ERP packages is done by placing files in certain directories to the picked up by the ERP application. The intent of placing the file is to invoke a common business function.
So far we have identified ways to categorize the overall intent of building an integration solution and the mechanics of connecting to a single application. What is left is a way to describe the nature of the interaction between the systems. This is what we attempted in Chapter 2 of our book. Admittedly, that categorization is a tad more fuzzy but I am sure you will agree that it is again somewhat independent from the other classifications. These integration styles are:
Each style defines a way to move information from A to B. Each style is quite distinct and comes with its own set of advantages and liabilities. This decision tends to be a much more global architectural decision than the decision of how to connect to a specific application. We could call this type of classification an architectural style that we should chose early on and that will shape the way we go about architecting our system.
I hope that presenting three distinct ways of classifying integration solutions is helpful in clarifying some of the terminology that is being used. Because integration is such a broad and varied field, there are definitely additional ways to categorize solutions, for example by the topology, such as Message Bus, or Hub-and-Spoke. However, I felt there was the need to start with some of the high-level categorization and try to bring a little bit of rigor into the terminology. Maybe I'll talk about topologies in my next rambling. And I promise it won't be another four months!
Gregor is a cloud architect and author. He is a frequent speaker on asynchronous messaging,
IT strategy, and cloud.