During the last couple of years, decision platforms evolved as technology that became more available and cost-effective. The need for making automated decisions has grown as well, and every organization is experiencing challenges of making the decisions while not having their domain experts around because of the recent pandemic. All these forces brought the importance of automated decisions to the surface.
That’s why we want to talk about the key capabilities you need to look at when choosing a Decision Platform.
Data and Integration
Data and Apps Integrations are a very important component to any decision platform. They should be able to connect to multiple data sources using different adapters such as Databases, REST services, Files, etc. These generic data connectors enable the platform to access the data for reading or manipulation. Also, specific integration for applications and services makes it easy to work with. For instance, if you need to read data from a particular application such as Google Workspace, Salesforce and deal with Google Vision, Microsoft Vision, etc., it will be much easier for the end-users to build models when using custom apps integration rather than generic REST call.
The data you read is probably transactional and operational data from your systems of records, therefore they are not necessarily in the shape and forms of what is needed for the decision execution. Once the data is read, you need to validate, enrich, and transform the data. This should be a critical component of your selection criteria that enables power users to build simple and complex data operations to deal with data read from multiple data sources. Data filtering, aggregation, manipulation, and enriching is a vital part of decision automation and a key component of decision platform.
Data operation can be modeled in a visual graphical fashion, or they can be modeled in expressions and syntax driven for advanced users. When it comes to data operations, make sure the decision platform has the ability to support XML, JSON, and dynamic data/objects natively so your data operations can deal with any types of data as this will save you tons of time and money when you implement complex decision automation scenario.
Non-Standard System Integration
Not all the data and apps integration is possible via a built-in standard integration point such as service call or database. Your organizations might work with vendors that do not provide API endpoints, and this is where the robotics capability of decision platform will be needed to integrate with websites, applications, etc. to gather data or record the outcomes of decisions back into the other systems.
It is unrealistic to expect the decision platform to have all the data and apps integration that you need in your organization, therefore a native SDK (Software Development Kit) is a key consideration to the platform. The SDK allows you to create those specific apps integrations when needed. Also, in the context of integration, the SDK will enable your IT and application development team to embed the decisions inside your applications and systems (in-proc integration).
Decision Authoring and Modeling
As we already established that a decision is entirely a different entity than process, business rule, data, etc. then should look into the decision platform in detail and understand how it allows you to ‘model decisions explicitly’ and you can support multistep decisioning scenarios.
Decisions can be rule-driven, or data-driven therefore you need to be able to satisfy a decision with many ways of modeling a decision logic.
If decisions are rule-driven, look at different options of business rules modeling such as lookup table, decision table, natural language, tree-subtree, and so on. When a decision is data-driven then therefore many different techniques can be used, from simple data lookup and aggregation to building Machine Learning (ML) models inside the platform or bringing your own trained ML algorithms and make them part of the decision model.
Make sure you can reuse your decisions, either by importing from standards such as Decision Model and Notation or by being able to package a decisioning scenario and reuse it across multiple projects.
As your understanding of business decisions matures, your models and implementation mature. Therefore, the decision platform should be able to manage multiple versions of decisions.
When it comes to versioning, there are two scenarios you should look at managing versions at:
- Design and development phase
- Runtime and execution phase
In the design and development phase, you need to be able to manage the project artifacts, it’s a better practice when the decision platform supports built-in, easy-to-use integration with source control systems such as GIT. This makes it easy to work with and support multiple streams of changes across multiple teams. Support for GIT enables and enhances team collaboration.
In the runtime and execution phase, you need to be able to switch between multiple concurrent versions of the same decisions automatically based on time or performance. Time-based is more for scenarios when a specific policy comes to effect, and the performance-based model allows you to use adaptive control to find the best performing decisions amount multiple existing versions.
Orchestration capability is a very important component when it comes to decision platforms. This enables you to model and deploy the end-to-end decision automation scenario. It ensures you can model, deploy and deliver a complete solution and integrate everything (e.g. data, file, services, and tasks) and involve everyone (e.g. domain expert interventions) as part of the decision automation scenario.
Understand if the provided orchestrations capability supports both transient or long-running models. Is the orchestration capability a simple decision flow? Or will it cover more complex scenarios such as human and multi-tasking, external events, timers, advanced fork, and branching i.e. inclusive and exclusive gateways?
Decision KPIs and Monitoring
In the decision platform, you need to be able to define organization decisions’ key performance indicators (KPIs). This should be done at the administration and configuration level, rather than at the modeling stage. As your decision automation runs on the day-to-day business, users will need to define KPIs based on the outcome of the decisions. The platform should collect those results and make them available for data exploration in different tools such as Power BI, Tableau, and so on.
Other types of KPIs that your operation (Ops) team might be interested in are the speed of execution. This will help the operation team to identify bottlenecks, improve the models, and monitors how the rules or other parts of the models are performing.
Potentially combining the KPIs with the champion challenger model, enables organizations to run multiple models in parallel to an existing one, and perform A/B testing based on the defined KPIs.
Of course, based on your organization’s appetite for using cloud and data security governance, you will need to have different options on the infrastructure to deploy and consume decision services. The decision platform ideally should support both on-prem and cloud deployment options.
For less-involved, easier deployments for decisions, you need to look for serverless deployment options that enable users to deploy the models as a service with a single click to different cloud providers such as Azure, AWS, and Google Cloud.
However, the deployment models to specific infrastructure also should support Docker deployment as well as VM.
SaaS is always a good option, but the issue is the performance of SaaS platforms as by definition they are shared environments. A better alternative to SaaS is to look for private managed services that you can get the benefits of not dealing with managing the infrastructure and also have the best performance.
Published August 12th, 2021 at 06:19 pm