Changes for page Multi-Model Explained

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -9,10 +9,10 @@
9	9
10	10	== 2. Key concepts ==
11	11
12		-* An environment in eMagiz in which there are multiple integration models is called a multi-model environment.
	12	+* An environment in eMagiz in which there are multiple integration models is called a multi-model environment.
13	13	* With integration model, an eMagiz platform instance is meant, in which it is possible to build integrations.
14	14	* 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.
15		-* 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.
	15	+* 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.
16	16
17	17	== 3. eMagiz multi-model environment - Definition ==
18	18
...	...	@@ -24,16 +24,16 @@
24	24
25	25	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--two-platform-instances.png]]
26	26
27		-Per integration model, it is possible to decide which integration patterns are available. This may be only one pattern, but it could also be two, or all three.
	27	+Per integration model, it is possible to decide which integration patterns are available. This may be only one pattern, but it could also be two, or all three.
28	28
29		-== 4 Separation of concerns ==
	29	+== 4. Separation of concerns ==
30	30
31	31	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. Reasons for applying this separation of concerns principle in the eMagiz environment are given below.
32	32
33	33	=== 4.1 Independent operations ===
34	34
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 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.
	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 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, it is difficult to make a new release 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 be released without having to take into account flow changes from the sales department that may have an impact on it.
37	37
38	38
39	39	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--independent-operations-single-instance.png]]
...	...	@@ -49,7 +49,7 @@
49	49
50	50	=== 4.3 Risk mitigation ===
51	51
52		-Within a multi-model environment, the impact on the business might a model break down is less as compared to a single-model environment. The reason for this, is that 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 in case the complete business runs on one model. If there are multiple models within a business that describe different business processes, other business processes can still continue if a cloud slot for one model has crashed. This is illustrated below.
	52	+Within a multi-model environment, the impact on the business might a model break down is less as compared to a single-model environment. The reason for this, is that 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 in case the complete business runs on one model. If there are multiple models within a business that describe different business processes, other business processes can still continue if a cloud slot for one model has crashed. This is illustrated below.
53	53
54	54	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--risk-mitigation-single-instance.png]]
55	55
...	...	@@ -57,7 +57,7 @@
57	57
58	58	=== 4.4 Manageability & maintainability ===
59	59
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.
	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
...	...	@@ -65,11 +65,13 @@
65	65
66	66	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--deployment-architecture.png]]
67	67
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.
	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	+Moreover, with multiple instances, the deployment architecture can be scaled more accurately according to what is desired for the model environment. For example, in case there are 1 or 2 interfaces that need a lot of capacity, it is not always necessary to scale according to the largest component. In other words, resources can be used more effectively.
	71	+
70	70	=== 4.6 Specialization & effectiveness within teams ===
71	71
72		-When there is one large model, there is more complexity and more diverging concepts have to 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 domain of a company to develop a model that is very specific to that domain in terms of data structure. It also ensures that more domain-specific language and conventions can be applied, e.g. in naming entities.
	74	+When there is one large model, there is more complexity and more diverging concepts have to 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 domain of a company to develop a model that is very specific to that domain in terms of data structure. It also ensures that more domain-specific language and conventions can be applied, e.g. in naming entities.
73	73	Furthermore, developers and users can specialize in one model, such that models can be worked on more effectively. In case 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 more quickly, and potential improvements are discovered and resolved more easily.
74	74	Lastly, different models can be worked on in parallel, also increasing the effectiveness of development and deployment. An illustration of the above mentioned arguments is given below.
75	75
...	...	@@ -77,11 +77,11 @@
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 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.
	82	+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
84		-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 model are combined, either the sales department will have to make up for all the costs, or less improvements can be made as compared to when the models are split. Thus, by splitting models, the financing can be distributed more fairly.
	86	+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 model are combined, either the sales department will have to make up for all the costs, or less improvements can be made as compared to when the models are split. Thus, by splitting models, the financing can be distributed more fairly.
85	85
86	86	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--funding.png]]
87	87