This is the fifth blog in a series of 6 blogs about integration 2.0. Did you miss one blog, read the fourth blog Integration 2.0: Interactions!
Though Integration 2.0 does not explicitly mention Services or Service Oriented Architecture (SOA) it makes a clear distinction between stateful services -services that maintain specific data – and stateless services that don’t.
Stateful services
Integration 2.0 embraces a microservice architecture where stateful services do maintain specific data within the business domain. Stateful services (or groups of stateful services in the same domain) in Integration 2.0 should be considered a EA component: autonomous and disclosed through a wrapper. Smaller microservices within the same domain may be grouped and share a wrapper and other resources, like integration capabilities.
A wrapper around a single service is often integral part of the microservice implementation itself. Just like other EA components microservice (group)s may maintain copies of external master data in order to be able to operate autonomously
Stateless services
Stateless (micro)services do not maintain domain/master-data and are therefore considered to be significantly different than stateful-microservices. Generally, they leverage the functionality or data of stateful micro-services (or other EA components), generally by invoking their API-s.
Examples of common stateless services are simple UI-based applications or a process-flows putting specific steps in sequence.
In integration 2.0 stateless services are considered to reside either on the process hub as processes, or as a “System of Innovation”, applications with a limited scope and life-cycle. (See next section).
Systems of Innovation (SoI)
Systems of Innovation (SoI-s) are intended to solve an urgent IT need in a very short time. Time-to-market and flexibility are key. In general, SoI-s have a limited scope and a short lifecycle (weeks or months, e.g. for the existence of a single marketing campaign). A SoI can store its own data, however that data is not considered to be Master Data.
As for the limited maintenance, usage and integration requirements the quality requirements for SoI applications are less strict than for other components. These characteristics of a SoI make that no other components should depend on a SoI.
Systems of Innovation are generally developed using a Low Code/No Code platform – either by business users or by IT. SoI may use the API-s that have been made available through the API management layers.
Though SoI-s intend to have a short lifecycle in some cases these systems deliver a value that exceeds the anticipated scope and life cycle. The business then may decide to keep on using and maintaining that particular SoI. In that case the system may be promoted to Enterprise Application Component, where it will take the role of System of Record. That requires that the requirements for the application will be as strict as the architecture principles dictate. Any technical debt in the implementation that prevents to comply to these guidelines will have to be removed accordingly. And next it will have to be provided with an EA Component wrapper.
Master Data Management (MDM)
Master Data Management (MDM) has a major role in Integration 2.0. Master Data concerns all key business entities and their necessary attributes. Think for instance of customers, vendors, products and employees.
Note that transactions performed by, for or with these business entities are generally not considered to be master data. In a data warehouse these transactions are stored as “facts”, where the Master data represents dimensions in the data warehouse.
MDM guarantees data quality and consistency and dictates the governance over the data: how is data classified (e.g. for security) and who is responsible and accountable.
It assigns systems that serve as “Systems of Record”, which are considered to contain the truth about the state of a certain business object. This so called “golden record” may be directly queried using an API (made available through API hub). Another approach is that other systems keep a copy of this master data. These so-called “slave”-systems subscribe to events generated by the System of Record in case of changes in master data. On each event the slave updates its master data copy accordingly.
Ideally each business data entity is managed by a single EA component. Such an “domain-oriented architecture” simplifies MDM significantly as it is clear what the Systems of Record for each business entity is. Therefor any well-organized micro-service architecture ought to be domain-oriented.
Reality however is that many organizations have multiple (often commercial) systems that don’t perfectly cover the domain without overlapping. Different systems managing the same business objects make it arbitrary what system is effectively “System of Record”. Think for example of a CRM system and an ERP system that both maintain customers. The question may arise: Which one is correct in case a customer in one system differs from the other?
This issue may be tackled with a specific MDM solution. Though there are several approaches such a solution usually concerns a central registration of all systems that manage the same business object. They may either register which system contains the actual truth, or even maintain the master data
itself. In that latter case the MDM system becomes the System-of-Record. The event-hub may be used to synchronize all systems that register that business entity as well.
