Choix lors de l’architecture et de la conception des services de décision

Dans ce blog, nous parlerons de l’architecture et de la conception de services décisionnels.

Tout d’abord, pour définir le contexte, et comme l’architecture et le design s’intègrent dans une image plus large, examinons le haut -étapes de niveau qui se produisent dans de tels projets :

1. En règle générale, une équipe a identifié un processus décisionnel qui doit être automatisé et a analysé et quantifié comment cette automatisation améliorera l’efficacité et la précision.

2. L’étape suivante consiste à identifier les données qui seront utilisées par les services décisionnels. Vous commencerez très probablement à être impliqué à cette étape.

3. Ensuite, vous devrez identifier comment et où les services de décision s’intégreront dans la solution logicielle plus large. Vous devrez également évaluer le degré d’évolutivité des services de décision et la façon dont ils géreront les volumes de données spécifiés. Vous devrez envisager des voies d’évolution futures.

4. Enfin, dans la dernière étape, vous devrez concevoir la logique de prise de décision. C’est ici que vous commencerez à créer des règles.

Remarque : dans ce blog, nous nous concentrerons principalement sur la troisième étape.

Décomposer

Vous devrez décomposer le processus qui doit être automatisé en un ensemble de services de décision. Votre choix est de créer un service de décision unique ou un ensemble de services indépendants plus petits.

Bien sûr, il n’y a pas de recette unique. Dans certains cas, une seule gestion de service peut répondre à vos besoins, mais en général, il est préférable de créer des services plus petits et indépendants.

Il y a plusieurs raisons à cela :

< li>Vous pouvez les développer et les tester indépendamment. Cela améliorera votre délai de mise sur le marché car vous pouvez parallèler l’effort.
• Vous pouvez les déployer indépendamment. Cela deviendra très important lors de la résolution de problèmes ainsi que lors d’une mise à niveau globale.
• Les petits services sont plus facilement évolutifs, car vous pouvez allouer des ressources à un niveau plus granulaire.
• >Vous pouvez collecter plus facilement des métriques sur l’utilisation, le coût, les performances, etc. d’un service spécifique. Cela est particulièrement vrai dans les environnements sans serveur, car les fournisseurs fournissent déjà diverses métriques au niveau de la fonction sans serveur.
• Ils sont plus facilement utilisable.

Données

Les services de décision agissent sur les données d’entrée, modifient parfois les données d’entrée et produisent des données de sortie.

La principale décision architecturale sera être d’évaluer la quantité de données à transmettre.

Certains services de décision seront simples de ce point de vue : ils auront besoin de toutes les données d’entrée tout le temps pour arriver à une décision.

< p>Cependant, certains services n’utiliseront qu’une partie des données dans des chemins d’exécution spécifiques. Une autre façon de le dire est que certains services devront accéder de manière conditionnelle à des données supplémentaires en fonction des conditions calculées dans le service de décision. Par exemple, lors du calcul d’une offre pour une installation de système solaire, vous aurez besoin d’accéder à diverses données de tarification de configuration ; plutôt que de transmettre toutes les données pour toutes les configurations possibles, il peut être plus approprié de laisser le service de décision demander le sous-ensemble des données dont il a vraiment besoin à ce stade de l’exécution.

Intégration

Dans une solution moderne, vous souhaiterez intégrer vos services de décision avec d’autres services de fournisseur de cloud. Vous devrez évaluer la flexibilité du moteur de service de décision concernant la collaboration avec d’autres services.

En outre, pour des raisons allant de l’amélioration des coûts et de l’infrastructure à la collaboration avec un partenaire ou l’intégration de solutions issues d’une acquisition, vous souhaiterez pour exécuter facilement les mêmes services de décision dans diverses infrastructures de fournisseurs de cloud.

Corticon Flexible Architectural Model

Corticon prend en charge n’importe quel service de décision de taille, vous avez donc une totale liberté pour décomposer vos services de décision à tout moment niveau de granularité nécessaire pour votre solution.

En outre, il prend en charge la transmission de toutes les données ou l’accès conditionnel aux données en fonction des besoins. Il prend également en charge l’écriture dans une source de données à tout moment du flux de service de décision.

En ce qui concerne l’intégration, Corticon offre la meilleure facilité de sa catégorie et un modèle flexible, car il est conçu à partir de zéro pour s’adapter à n’importe quelle infrastructure de fournisseur de cloud sans modifications et pour fonctionner également sur site. En fait, il fournit véritablement des services décisionnels indépendants du cloud ; faire du multi-cloud ou de l’hybride est une réalité avec Corticon.

Enfin, cela ne vous oblige pas à utiliser une solution d’orchestration ou de workflow spécifique. Il fonctionne immédiatement avec le service d’orchestration de fournisseur de cloud que votre équipe connaît peut-être déjà et qui est peut-être déjà utilisé dans vos solutions.

En conclusion, l’architecture et la conception de services décisionnels pour des solutions logicielles modernes nécessitent une bonne compréhension des processus métier, des données impliquées et des points d’intégration requis.

Vous aurez besoin d’un moteur de règles qui vous offre flexibilité, agilité et choix d’intégration pour n’importe quel environnement.

Découvrez ici comment Corticon, en tant qu’environnement no-code/low-code, peut vous aider à augmenter votre productivité et à fournir vos solutions plus rapidement.

Et vous pouvez vous inscrire à un formation gratuite pour Corticon.js ici.

En savoir plus sur Corticon

Source link