T
Thierry Ciot
Guest
In this blog, we will talk about architecting and designing decision services.
First, to set the context, and as architecture and design fit in a larger picture, let’s review the high-level steps that happen in such projects:
1. Typically, a team has identified a decision-making process that needs to be automated and has analyzed and quantified how this automation will improve efficiency and accuracy.
2. The next step is to identify the data that will be used by the decision services. You will most likely start to be involved at this step.
3. Then, you will need to identify how and where the decision services will integrate into the larger software solution. You will also need to evaluate how scalable the decision services are and how they will handle specified volumes of data. You will need to consider future evolution paths.
4. Finally, in the last step you will need to design the decision-making logic. This is where you will start creating rules.
Note: In this blog, we will focus mainly on step three.
You will need to decompose the process that needs to be automated into a set of decision services. Your choice is to create a single decision service or a set of smaller independent services.
Of course, there is no one-size-fits-all recipe. In some cases, a single service handling may fit your requirements, but in general, it is desirable to create smaller, independent services.
There are multiple reasons for doing so:
Decision services act on input data, sometimes modify the input data and produce output data.
The main architectural decision will be to assess how much data to pass in.
Some decision services will be simple from that point of view: They will need all the input data all the time to arrive at a decision.
However, some services will only use some of the data in specific execution paths. Another way to put this is that some services will need to conditionally access additional data based on conditions computed in the decision service. For example, when computing an offer for a solar system installation, you will need access to various configuration pricing data; rather than passing all the data for all possible configurations, it may be more appropriate to let the decision service request the subset of the data it really needs at that point in the execution.
In a modern solution, you will want to integrate your decision services with other cloud vendor services. You will need to assess how flexible the decision service engine is regarding working with other services.
Additionally, for reasons ranging from improving cost and infrastructure to working with a partner or integrating solutions from an acquisition, you will want to easily run the same decision services in various cloud vendor infrastructures.
Corticon supports any size decision service, so you have complete freedom to decompose your decision services at any granular level necessary for your solution.
Additionally, it supports either passing all the data in or conditionally accessing data on an as-needed basis. It also supports writing to a datasource at any point in the decision service flow.
When it comes to integration, Corticon provides best-in-class ease and a flexible model, as it is designed from the ground up to fit into any cloud vendor infrastructure without changes, and to work on premise as well. In fact, it truly provides decision services that are cloud agnostics—doing multi-cloud or hybrid is a reality with Corticon.
Finally, it does not force you to use a specific orchestration or workflow solution. It works out of the box with the cloud vendor orchestration service your team may already be familiar with and that may already be used in your solutions.
In conclusion, architecting and designing decision services for modern software solutions requires a good understanding of the business processes, the data involved and the required integration points.
You will need a rules engine that provides you with flexibility, agility and choices in integration for any environment.
Find out here how Corticon as a no-code/low-code environment can help increase your productivity and deliver your solutions faster.
And you can enroll in a free training for Corticon.js here.
Learn more about Corticon
Continue reading...
First, to set the context, and as architecture and design fit in a larger picture, let’s review the high-level steps that happen in such projects:
1. Typically, a team has identified a decision-making process that needs to be automated and has analyzed and quantified how this automation will improve efficiency and accuracy.
2. The next step is to identify the data that will be used by the decision services. You will most likely start to be involved at this step.
3. Then, you will need to identify how and where the decision services will integrate into the larger software solution. You will also need to evaluate how scalable the decision services are and how they will handle specified volumes of data. You will need to consider future evolution paths.
4. Finally, in the last step you will need to design the decision-making logic. This is where you will start creating rules.
Note: In this blog, we will focus mainly on step three.
Decomposing
You will need to decompose the process that needs to be automated into a set of decision services. Your choice is to create a single decision service or a set of smaller independent services.
Of course, there is no one-size-fits-all recipe. In some cases, a single service handling may fit your requirements, but in general, it is desirable to create smaller, independent services.
There are multiple reasons for doing so:
- You can independently develop and test them. This will improve your time to market as you can parallel the effort.
- You can independently deploy them. This will become very important when having to fix issues as well as when doing a global upgrade.
- Smaller services are more easily scalable, as you can allocate resources at a more granular level.
- You can collect metrics more easily on specific service usage, cost, performance, etc. This is particularly true in Serverless environments, as vendors already provide various metrics at serverless function level.
- They are more easily re-usable.
Data
Decision services act on input data, sometimes modify the input data and produce output data.
The main architectural decision will be to assess how much data to pass in.
Some decision services will be simple from that point of view: They will need all the input data all the time to arrive at a decision.
However, some services will only use some of the data in specific execution paths. Another way to put this is that some services will need to conditionally access additional data based on conditions computed in the decision service. For example, when computing an offer for a solar system installation, you will need access to various configuration pricing data; rather than passing all the data for all possible configurations, it may be more appropriate to let the decision service request the subset of the data it really needs at that point in the execution.
Integration
In a modern solution, you will want to integrate your decision services with other cloud vendor services. You will need to assess how flexible the decision service engine is regarding working with other services.
Additionally, for reasons ranging from improving cost and infrastructure to working with a partner or integrating solutions from an acquisition, you will want to easily run the same decision services in various cloud vendor infrastructures.
Corticon Flexible Architectural Model
Corticon supports any size decision service, so you have complete freedom to decompose your decision services at any granular level necessary for your solution.
Additionally, it supports either passing all the data in or conditionally accessing data on an as-needed basis. It also supports writing to a datasource at any point in the decision service flow.
When it comes to integration, Corticon provides best-in-class ease and a flexible model, as it is designed from the ground up to fit into any cloud vendor infrastructure without changes, and to work on premise as well. In fact, it truly provides decision services that are cloud agnostics—doing multi-cloud or hybrid is a reality with Corticon.
Finally, it does not force you to use a specific orchestration or workflow solution. It works out of the box with the cloud vendor orchestration service your team may already be familiar with and that may already be used in your solutions.
In conclusion, architecting and designing decision services for modern software solutions requires a good understanding of the business processes, the data involved and the required integration points.
You will need a rules engine that provides you with flexibility, agility and choices in integration for any environment.
Find out here how Corticon as a no-code/low-code environment can help increase your productivity and deliver your solutions faster.
And you can enroll in a free training for Corticon.js here.
Learn more about Corticon
Continue reading...