Changes for page Multi-Model Explained

Summary

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

Details

Page properties

Content

...	...	@@ -14,16 +14,28 @@
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	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		-== 3. eMagiz Cloud - Inner Workings ==
	17	+== 3. eMagiz multi-model environment - Definition ==
18	18
19		-When running your eMagiz solution, there are generally two methods of deploying. There is the Cloud and the on-premise (i.e., in your own data center) option. We see a strong development towards Cloud-based functionality across markets. Furthermore, we see that patterns such as API Gateway and Event Streaming are tailored for a cloud only approach. Given all those characteristics, we have an eMagiz Cloud first strategy when further developing our patterns and features across the platform.
	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, API Gateway, and Event Streaming, as described in link. An illustration of an integration model, or platform instance, using the Messaging pattern is the following:
	20	+
	21	+[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--single-platform-instance.png]]
20	20
21		-In this fundamental, we will zoom in on how the eMagiz Cloud is structured and how it operates for you as a customer. We will start our journey at a high level in which we focus on how we support multiple customer environments within the same eMagiz Cloud. From there, we will in on the details of each of those customer environments. Building on that, we show the differences between a single lane and a double lane setup. Last but not least, we will focus on the key benefits deploying in the eMagiz Cloud holds for you.
	23	+An illustration of two platform instances, both modelled with the Messaging pattern, is shown below:
22	22
23		-=== 3.1 High-level overview ===
	25	+[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-multi-model--two-platform-instances.png]]
24	24
25		-The first perspective on the Cloud we take is how we run multiple customers within the same eMagiz Cloud solution that we offer. The picture below shows how we structured our Cloud to ensure that your data is kept safely within your environment.
	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	+
	29	+== 4 Separation of concerns ==
26	26
	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	+
	33	+=== 4.1 Independent operations ===
	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 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	+
	38	+
27	27	[[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-cloud-inner-workings--high-overview.png]]
28	28
29	29	The most outer line of the picture represents the total eMagiz Cloud. Our support department and cloud admins have access to this level from which they can access each customer environment if need be. When going one level deeper, we see the standard region in which all our customers' data is kept. This default region (eu-central-01 located in Frankfurt) allows us to keep data under European Law and reduces the latency as most of our customer base is located within the European continent. Within this region, we have what we call a Carwash. This carwash is placed in front of each of our customer VPC's to add a layer of security. This layer restricts access to customer endpoints. Behind the carwash, we have one separate VPC per customer model. So when you have multiple models running in eMagiz (as part of your Enterprise license), you will effectively have the same amount of VPCs in the Cloud (assuming all of them run in the Cloud). This allows for the best possible separation of concerns between customers and models.