Changes for page Multi-Model Explained

Last modified by Erik Bakker on 2024/08/08 11:57

From version 6.1
edited by Carlijn Kokkeler
on 2022/10/14 09:46
Change comment: There is no comment for this version
To version 10.1
edited by Carlijn Kokkeler
on 2022/10/14 10:00
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -16,7 +16,7 @@
16 16  
17 17  == 3. eMagiz multi-model environment - Definition ==
18 18  
19 -For some companies that work with eMagiz, it is preferable to have multiple integration models. Such 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. Within an integration model, three types of integration patterns can be modelled. These are [[Messaging>>doc:Main.eMagiz Academy.Fundamentals.fundamental-messaging-introduction.WebHome||target="blank"]], [[API Gateway>>doc:Main.eMagiz Academy.Fundamentals.fundamental-api-gateway-introduction.WebHome||target="blank"]], and [[Event Streaming>>doc:Main.eMagiz Academy.Fundamentals.fundamental-event-streaming-introduction.WebHome||target="blank"]]. An illustration of an integration model, or platform instance, using the Messaging pattern is the following:
19 +For some companies that work with eMagiz, it is preferable to have multiple integration models. Such 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. Within an integration model, three types of integration patterns can be modelled. These are [[Messaging>>doc:Main.eMagiz Academy.Fundamentals.fundamental-messaging-introduction.WebHome||target="blank"]], [[API Gateway>>doc:Main.eMagiz Academy.Fundamentals.fundamental-api-gateway-introduction.WebHome||target="blank"]], and [[Event Streaming>>doc:Main.eMagiz Academy.Fundamentals.fundamental-event-streaming-introduction.WebHome||target="blank"]]. An illustration of an integration model, or platform instance, with the Messaging integration pattern is the following:
20 20  
21 21  [[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--single-platform-instance.png]]
22 22  
... ... @@ -33,7 +33,7 @@
33 33  === 4.1 Independent operations ===
34 34  
35 35  Within a company, there may be different business processes that can operate independently. It can be useful to have a clear separation in these business processes, such that the processes 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.
36 -By having an eMagiz model for each distinct business process, it possible to release new integrations and make changes independently, so that the processes can evolve freely. For example, in case there is a different model for sales and transport, there is no dependency on progress of both departments. Below, it is illustrated that, in case a flow that is being worked on for the sales department is still in progress, while a flow that is being worked on for the transport department is done, no new release can be made if the models are not 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 already be released.
36 +By having an eMagiz model for each distinct business process, it is possible to release new integrations and make changes independently, so that the processes can evolve freely. For example, in case there is a different model for sales and transport, there is no dependency on progress of both departments. Below, it is illustrated that, in case a flow that is being worked on for the sales department is still in progress, while a flow that is being worked on for the transport department is done, no new release can be made if the models are not 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 already be released.
37 37  
38 38  
39 39  [[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--independent-operations-single-instance.png]]
... ... @@ -58,13 +58,13 @@
58 58  === 4.4 Manageability & maintainability ===
59 59  
60 60  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. Manageable here means the capability of being controlled or dealt without difficulty. Maintainable concerns the ability to preserve or retain a certain state. In case there is only 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 if something needs improvement.
61 -
61 +
62 62  === 4.5 Deployment architecture ===
63 -
63 +
64 64  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:
65 -
65 +
66 66  [[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--deployment-architecture.png]]
67 -
67 +
68 68  Each model has its own deployment architecture. As can be seen, there are several of the same types of components within the environment. 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. This means that there is less dependency and a better organization within the deployment environments. For example, if one machine hinders the deployment plan, this will cause no issues if that machine is in a different model.
69 69  
70 70  === 4.6 Specialization & effectiveness within teams ===
... ... @@ -77,7 +77,7 @@
77 77  
78 78  === 4.7 Strategy ===
79 79  
80 -With multiple models, there is a clearer separation of the business process. This means that the progress per business process can be better monitored. 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 easily. Moreover, more specific KPIs and goals can be formulated and monitored. Alerts can be put in place per model to check upon the progress and achievement of these KPIs and goals, and support can be provided.
80 +With multiple models, there is a clearer separation of the business process. This means that the progress per business process can be better monitored in terms of 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 easily. Moreover, more specific KPIs and goals can be formulated and monitored. Alerts can be put in place per model to check upon the progress and achievement of these KPIs and goals, and support can be provided.
81 81  
82 82  === 4.8 Funding ===
83 83  
... ... @@ -104,10 +104,9 @@
104 104  * With multiple models, concepts that describe a model can be more clearly defined, since less diverging information needs to be processed.
105 105  * By splitting models, the financing can be distributed more fairly.
106 106  * Having multiple integrations models can be beneficial due to contractual and legal arrangements.
107 -
107 +
108 108  == 5. Suggested Additional Readings ==
109 109  
110 -If you are interested in this topic and want to learn how you can control your Cloud with the help of the eMagiz platform, please check out our microlearnings offering on eMagiz Cloud Management:
111 111  
112 112  * [[Messaging>>doc:Main.eMagiz Academy.Fundamentals.fundamental-messaging-introduction.WebHome||target="blank"]]
113 113  * [[API Gateway>>doc:Main.eMagiz Academy.Fundamentals.fundamental-api-gateway-introduction.WebHome||target="blank"]]