Multi-Model Explained
In this fundamental we share some valuable insights about working with eMagiz in a multi-model environment. This information covers integration models, separation of concerns, and the benefits of managing different business processes independently.
Should you have any questions, please get in touch with academy@emagiz.com.
1. Prerequisites
- Some context on cloud functionality will be helpful.
2. Key Concepts
- An environment in eMagiz in which there are multiple integration models is called a multi-model environment.
- With integration model, an eMagiz platform instance is meant, in which it is possible to build integrations.
- There are several reasons for choosing multiple integrations models, i.e. separate eMagiz instances. These reasons can be grouped under the term separation of concerns.
- Separation of concerns is a design principle in software development and architecture for separating an application in two or more sections, such that each section addresses a particular concern.
3. eMagiz Multi-Model Environment - Definition
For some companies that work with eMagiz, multiple integration models are preferable. Such an eMagiz environment with multiple integration models is called a multi-model environment. With the integration model, an eMagiz platform instance is meant to make it possible to build integrations. Within an integration model, three types of integration patterns can be modeled. These are Messaging, API Gateway, and Event Streaming. An illustration of an integration model, or platform instance, with the Messaging integration pattern, is the following:
An illustration of two platform instances, both modeled with the Messaging pattern, is shown below:
Per the integration model, deciding which integration patterns are available is possible. This may be only one pattern, but it could also be two or all three.
4. Separation of Concerns
There are several reasons for choosing multiple integration models, i.e., separate eMagiz instances. These reasons can be grouped under the term separation of concerns. Separation of concerns is a design principle in software development and architecture that separates an application into two or more sections, each addressing a particular concern. The reasons for applying this separation of concerns principle in the eMagiz environment are below.
4.1 Independent Operations
Within a company, different business processes may operate independently. It can be useful to have a clear separation between these business processes so that they can evolve independently. This may include entirely different business processes, such as sales and transport, but processes can also be separated based on different use cases or different positions within a business process. For example, one model might address the business processes down the value chain, while the other model addresses the business processes up the value chain.
Having an eMagiz model for each distinct business process makes it possible to release new integrations and make changes independently so that the processes can evolve freely. For example, if there is a different model for sales and transport, there is no dependency on the progress of both departments. Below, it is illustrated that, in this case, a flow being worked on for the sales department is still in progress. In contrast, if the flow being worked on for the transport department is done, it is easier to make a new release if the models are separated. In case there is a separate model for the sales department and the transport department, releases can be made independently, meaning that the improvement on the flow for the transport department can be released without having to take into account flow changes from the sales department that may have an impact on it.
4.2 Data Model
Data models are visual representations that describe data using entities and attributes. Entities are representations of physical objects or well-defined singular concepts. Attributes are details that are specific to an entity. For example, a data model may contain the entity ‘customer’ with attributes ‘id,’ ‘name,’ ‘address,’ and more. Within eMagiz, there are up to 3 data models for a model, namely for each integration pattern (Messaging, API Gateway, Event Streaming).
(Part of) a data model in eMagiz is shown below. As can be seen, a data model can become large, and there is an excellent risk of unclarity. By splitting business processes, data models can be made more specific to the process. This ensures that there is less ambiguity within one model. Moreover, the data models can be reduced in size since entities and attributes that belong to the data model of a particular process can be removed from the data model of another process. This provides a better overview of the entities and attributes within a model.
4.3 Risk Mitigation
Within a multi-model environment, the impact on the business might be less than if a model breaks down compared to a single-model climate. This is because in a multi-model environment, only a part of the integration landscape is affected, instead of the complete landscape. For example, eMagiz models run on cloud slots. In case the cloud slot on which a model runs crashes, no business processes can be executed if the complete business runs on one model. If multiple models within a business describe different business processes, other business processes can still continue if a cloud slot for one model has crashed. This is illustrated below.
4.4 Manageability & Maintainability
Having multiple models gives a more straightforward overview of the models and less complexity. This ensures that the models are better manageable and maintainable. Manageable here means the capability of being controlled or dealt with without difficulty. Maintainable concerns the ability to preserve or retain a particular state. If there is more than one model for a complete organization, the data models, data flows, and overall architecture contain much information, which can cause complexity. With multiple models, it is clearer what processes models describe, and it is better possible to have an overview of the overall architecture. This way, it is more easily discoverable if a process is not working effectively or something needs improvement.
4.5 Deployment Architecture
The deployment architecture in eMagiz shows the machines, containers, and other architectural components that are needed to deploy a release. An example of what such an environment could look like is the following:
Each model has its deployment architecture. As can be seen, several of the same types of components exist within the environment. If there is only one model for an organization, the deployment architecture contains all the architectural components needed to deploy the model. Separate environments ensure fewer container runtimes and connector machines within one environment. This means less dependency and a better organization within the deployment environments. For example, if one machine hinders the deployment plan, there will be no issues if that machine is in a different model.
Moreover, with multiple instances, the deployment architecture can be scaled more accurately according to what is desired for the model environment. For example, if 1 or 2 interfaces need much capacity, it is only sometimes necessary to scale according to the most significant component. In other words, resources can be used more effectively.
4.6 Specialization & Effectiveness within Teams
There is more complexity when there is one large model, and more diverging concepts must be described. With multiple models, concepts that describe a model can be more clearly defined since less diverging information needs to be processed. For example, a team can specialize in one company's domain to develop a model that is very specific to that domain in terms of data structure. This also ensures that more domain-specific language and conventions can be applied, e.g., in naming entities.
Furthermore, developers and users can specialize in one model so that models can be worked on more effectively. If there is one model for a complete organization, developers will have to understand all concepts. When there are multiple models, developers can study the concepts of one model more closely and understand the process better. This will ensure that integrations are built quickly and potential improvements are discovered and resolved more efficiently.
Lastly, different models can be worked on in parallel, increasing the effectiveness of development and deployment. An illustration of the above-mentioned arguments is given below.
4.7 Strategy
With multiple models, there is a more apparent separation of the business process. This means the progress per business process can be better monitored regarding strategy. For example, if there is a separate model for the sales business process, it can be better discoverable whether more integrations have been set up. If the number of integrations has stopped growing, it might be the case that no new partners have joined the company. By having a better overview of the business processes, strategic decisions can be made more quickly. Moreover, more specific KPIs and goals can be formulated and monitored. Alerts can be put in place per model to check up on the progress and achievement of these KPIs and goals, and support can be provided.
4.8 Funding
There may be a difference in funding of different departments or business units. For example, the sales department of a company might have a bigger budget for improving their model compared to the transport department. If the sales model is separate from the transport model, investments could be made by the sales department to add additional features or make other improvements. If the transport and sales models are combined, the sales department must compensate for all the costs, or fewer improvements can be made compared to when the models are split. Thus, by splitting models, the financing can be distributed more fairly.
4.9 Contractual and legal aspects
Multiple integration models can also be beneficial due to contractual and legal arrangements. For example, sharing data between departments within one organization is not allowed. If there is one model for the complete organization, this is a complex issue since all data is available within one model. The problem is solved if there is a different model for the departments between which no data may be shared.
Moreover, contractual arrangements between different departments within a company may differ. It is better to develop separate models. For example, the sales department might have a contractual arrangement that does not allow for a specific type of integration. In case the contractual arrangements of the transport department allow for that type of integration and it is beneficial for their model, it is better to have separate models.
4. Key Takeaways
- An environment in eMagiz in which there are multiple integration models is called a multi-model environment.
- With integration model, an eMagiz platform instance is meant, in which it is possible to build integrations.
- There are several reasons for choosing multiple integrations models, i.e. separate eMagiz instances. These reasons can be grouped under the term separation of concerns.
- Separation of concerns is a design principle in software development and architecture for separating an application in two or more sections, such that each section addresses a particular concern.
- It can be useful to have a clear separation in these business processes, such that the processes can evolve independently.
- It can be beneficial to split large data models.
- Within a multi-model environment, the impact on the business might a model break down is less as compared to a single-model environment.
- By having multiple models, there is a clearer overview of the models, and less complexity. This ensures that the models are better manageable and maintainable.
- In case there is only one model for an organization, the deployment architecture contains all architectural components that are needed to deploy the model. Separate environments ensure that there are less container runtimes and connector machines within one environment.
- With multiple models, concepts that describe a model can be more clearly defined, since less diverging information needs to be processed.
- By splitting models, the financing can be distributed more fairly.
- Having multiple integrations models can be beneficial due to contractual and legal arrangements.