This is the second blog in a series of 6 blogs about integration 2.0. Read the first blog Integration 2.0!

These recent developments have urged us to define a new Integration approach, that we call “Integration 2.0”. This approach aims to address the challenges posed by the technical and business developments for the next decade.

Basically, the model is not far different from the current approach, but there are a few important changes.

Integration 2.0 is organized around “Enterprise Application Components” (EAC-s): applications or microservices that have been made autonomous. They provide their own generic interface and can operate independently from any other IT component.

Two mayor Integration capabilities are the backbone of the traditional part of the Integration 2.0 landscape: API-hub for (internal and external) synchronous communication and Event-hub for asynchronous communication.

A “process-hub” facilitates any process logic that exceeds the boundaries of EA Components.

In principle all main data exchange in the enterprise is over the API- and Event hub(s). Not only for EA Components, but also for generic IT capabilities (functions) like Master Data Management (MDM) and Business Rules Management (BRM). Also, business-to-business (B2B) communication is typically executed over the external API-hub.

Though additional capabilities may be required for specific domains, like Internet of Things (IoT), Business Intelligence and big data. The characteristics of the data to exchange like speed, volume and format exchanged require a dedicated approach.

Enterprise Application Components (EAC-s)

“Enterprise Application Components” (EAC-s) are responsible to execute specific business transactions. The core of EAC-s may be delivered as Commercial-Of-The-Shelf (COTS), Software-as-a-Service (SaaS), or custom developed micro services. In general, the cores consist of business logic, data, user interface and -for integration purposes- interfaces.

EAC-s are provided / extended with a standard interface. This is a mayor difference with the past were these custom interface services were built upon the ESB. Further EAC-s have all the necessary resources to be able to operate independently from other applications or IT services. That means that resources -like databases instances- are not shared with any other EAC. This concept is based on micro services and implies that all EAC-s may be managed independently. Ideally these EAC-s are so fine grained that they represent business objects on an atomic level in order to have optimal flexibility. A DevOps-team may be complete in control of designing, building, deploying, running, testing, changing and scaling their EAC without having to concern how this will affect any other EAC. Any runtime interaction is done through the standard interfaces that are part of the EAC. And if those are not changed the context does not need to change either.

Standardized application interfaces

Traditionally applications are disclosed by services that run on a shared ESB instance, separately from the application. Integration 2.0 suggests that each component provides a proprietary wrapper of standard interface functions. This standard interface consists of:

• An API for synchronous communication, to expose data and to allow external clients to trigger transactions
• An Event interface for asynchronous communication, both to trigger and to receive events

Figure 5: Enterprise Application wrapped as EA Integration Component

Integration features are literally part of the EAC, and don’t require services running on a central ESB. EAC-s hide the actual implementation of the core functionality from the outside-world. For COTS and SaaS products a wrapper may defined that use the API-s provided by the product. If this offers too limited functionality custom solutions may be developed, e.g. directly approaching the products database and expose it through API or events. Some products provide customizable Integration capabilities – Like SAP offers the integration suite PO. This may be leveraged as well, as long as they are runtime not shared with other SAP applications.

Figure 6: 4 different types of EA wrapped as EA Component

Micro services in general provide their own development stack with runtime libraries. These may be used to develop the Interfaces. If required additional middleware software may be used, as long as a local instance is used in scope of the EAC.

This is the second blog in a series of 6 blogs about integration 2.0. Read the third blog Integration 2.0 Main Integration Concepts!