About integrations, inlays and interoperability
Before going into more detail on what SOA contributes to the scenario described in our previous entry, let’s pause for a moment in the term “integration.”
In order not to beat around the bush, let’s focus on EAI (Enterprise Application Integration). According to wikipedia, EAI is the process of connecting applications with each other to exchange operational or financial information. There are two reflections that emerge immediately:
- The way in which the applications are connected is decisive
- A step further would be to exchange processes, not only information
Indeed, there are many ways to connect applications in an organization. One devastating fact that you can see in that entry is that the number of point-to-point connections grows geometrically: to have 10 applications connected this way, 45 point-to-point connections are required!! Think of organizations with dozens and dozens of applications … more spaghetti!.
Of course, these scenarios end up presenting serious blockades that make the projects that need to be undertaken unfeasible. Let us not forget that budgets are limited (and nowadays, waning).
But the problem goes beyond the number of point-to-point connections, the consequent inefficiency in the network that supports them, and its frustrating domino effect when we consider modifying an information system. Further on, such point-to-point connections may be of different nature, and may introduce even more problems. For example:
- Applications showing options or buttons in their interface to open other applications
- Applications accessing databases from other applications
- Applications using exact copies of tables from other applications, which are loaded periodically
- Applications retrieving files generated by other applications, with a proprietary structure designed by that application
- Applications publishing proprietary web services to be invoked by other systems
All these ways of integrating applications seem more inlays than integrations. Here information is no longer shared, the coupling is not at the data level, it is at the level of structures, data models, user interfaces. It is an amalgam of applications designed to interconnect in a way that triggers costs when it comes to evolving or replacing existing information systems. As we have mentioned, embedding seems to be a better term for this way of integrating information systems. It seems to be a more precise and adjusted term to what is being done.
Regarding the second part of the definition, we wondered why to exchange only information. Why not exchange processes? But beware, “processes” is a term that should be specified. We are not talking about “dates calculation”, neither “ID validation”, or anything like that. We are talking about business processes. These functionalities are repeated in several information systems throughout the various functional areas, or some of them, and we strive to solve them again and again using the technological trend of the moment. For example, consulting a report (any report). Or updating a client information (for the whole organization, in real time). Or knowing in which bed a patient is admitted (an information that’s needed in admission, in nursing, doctors, pharmacy, kitchen, etc).
When focus is set on exchanging processes, the applications are no longer integrated, but interoperable. Interoperability involves the ability of an organization’s information systems to share and reuse business processes that present business-specific, cross-functional (functional interoperability) and business data through standards (semantic interoperability).
Therefore, we have the following picture: from integrating applications to exchange operational and financial information, we have moved to interoperable applications both at business processes level and business semantics level.
Once this approach is set, we can continue.