La logique d'architecture d'entreprise IT présentée dans le "QUID de la LOI2S" peut être résumée de la manière suivante :
- Structure Organisationnelle :
- L’organisation d’entreprise est composée de différentes directions (générale, RH, financière, commerciale, etc.), chacune ayant des rôles spécifiques.
- Les entités opérationnelles sont interconnectées, utilisant le système d’information comme point de convergence.
- Système d’Information Transverse :
- Le système d’information est décrit comme transverse et indépendant de l’organisation opérationnelle.
- Il est décomposé en trois domaines fonctionnels (Administration, Production, Commercialisation), orchestrés par un Pôle de coordination.
- Pôle de Coordination :
- Ce pôle est responsable de la synchronisation entre les domaines fonctionnels, fixant les objectifs et les politiques de l’entreprise.
- Il joue un rôle clé dans la prise de décisions stratégiques, la supervision de la performance et la représentation des intérêts des actionnaires.
- Gestion des Compétences :
- Une importance particulière est accordée à la combinaison de compétences spécifiques dans chaque domaine fonctionnel.
- Le Pôle de coordination doit travailler en coopération, communiquer efficacement, et prendre des décisions logiques et rapides.
- Décomposition et Coordination :
- Chaque domaine peut être décomposé en sous-domaines, tout en respectant la même logique de décomposition.
- La coordination entre les domaines et sous-domaines est assurée par des directives et sous-directives consolidées.
- Traçabilité et Journalisation :
- La traçabilité des activités est mise en avant, avec des méthodes et technologies permettant une surveillance complète et une collecte de données précise.
- Les activités et processus peuvent être journalisés pour assurer la transparence, la fiabilité et la conformité des activités dans le système d’information.
- Architecture Fractale et Microservices :
- L’architecture fractale LOI2S est mentionnée, permettant de modéliser des systèmes informatiques complexes à partir de composants simples.
- L’approche Microservices est utilisée pour la conception de systèmes d’information, avec des avantages en termes de flexibilité et d’évolutivité.
Quid des 3 piliers organisationnels ?
L’organisation d’une entreprise est composée d’un ensemble d’entités opérationnelles qui travaillent ensemble pour atteindre ses objectifs. Ces entités comprennent notamment :
- La Direction Générale : Elle est responsable de la stratégie de l’entreprise et de la direction des opérations.
- La Direction des Ressources Humaines : Elle est responsable de la gestion des employés et des relations avec le personnel.
- La Direction Financière : Elle est responsable de la gestion des finances et des activités comptables.
- La Direction commerciale : Elle est responsable de la promotion des produits et services, de la mise en œuvre des stratégies de vente et de la gestion des clients. Elle est aussi responsable de l’exploration de nouvelles opportunités commerciales.
- La Direction de la Production : il est responsable de la fabrication des produits et de la gestion de la chaîne d’approvisionnement.
- La Direction Logistique : il est responsable de l’expédition des produits et des services, ainsi que de la gestion des stocks.
- La Direction Marketing Commercial : il est responsable de la promotion des produits et services et de la gestion des relations publiques.
- La Direction Marketing Produits et Services : il est responsable de la recherche et du développement des nouveaux produits et services retenues par suite des études de marchés.
- La Direction des Technologies de l’Information : il est responsable de la gestion des systèmes informatiques et des réseaux.
Toutes les entités opérationnelles sont interconnectées et travaillent ensemble pour renforcer leur activité en utilisant le système d’information comme point de convergence.
Le Système d’information est transverse à l’organisation. Il est conforme au métier sans être corrélé à l’organisation opérationnelle.
La LOI2S décompose le système d’information en 3 Domaines fonctionnelles orchestrés par un Pôle de coordination :
- Administrateur : Comment ? Administration
- Producteur : Quoi ? Production
- Commercialisateur : Vendre ? Commercialisation
Le Pôle de coordination est responsable de la synchronisation entre les 3 Domaines fonctionnelles. Il définit les directives, les objectifs et les moyens nécessaires à leur réalisation. Il fixe et restitue les Indicateurs de performances (KPI).
Le Pôle de coordination est un organe de direction qui a pour rôle
- de fixer les objectifs et les politiques de l’entreprise : le Pôle de coordination est responsable de déterminer les objectifs à long terme de l’entreprise et de définir les politiques qui permettront de les atteindre,
- de prendre des décisions stratégiques importantes : le Pôle de coordination est chargé de prendre des décisions clés en matière de stratégie, de finances, de ressources humaines, de marketing, etc.
- de superviser la performance de l’entreprise : le Pôle de coordination est responsable de surveiller la performance de l’entreprise et de prendre des mesures pour corriger les déviations par rapport aux objectifs,
- d’assurer la responsabilité envers les actionnaires : le Pôle de coordination est responsable de représenter les intérêts des actionnaires et de veiller à ce que l’entreprise soit gérée de manière responsable et éthique,
- de fournir un leadership : le Pôle de coordination doit fournir un leadership clair et cohérent à l’entreprise et à son personnel pour guider leur développement et leur croissance.
En général, le Pôle de coordination est un organe clé de l’organisation qui a un impact significatif sur la performance et le succès de celle-ci.
Pour gérer efficacement ces 3 pôles fonctionnelles, il est important d’avoir une combinaison de ressources avec des sensibilités et des compétences complémentaires :
- Administration : compétences en gestion financière, en gestion des ressources humaines, en conformité légale et réglementaire, en gestion de la qualité, etc.
- Production : compétences en ingénierie, en fabrication, en maintenance, en gestion de la chaîne d’approvisionnement, etc.
- Commercialisation : compétences en marketing, en vente, en négociation, en gestion de la relation client, etc.
Le Pôle de coordination doit, en plus de ces compétences spécifiques, travailler en coopération et concertation, communiquer efficacement, prendre des décisions rapidement de façon logique et rationnelle, résoudre des difficultés, être flexible et s’adapter aux changements, etc.
Le Pôle de coordination influence ou de dirige un groupe de personnes ou organe vers l’atteinte d’un objectif commun. Le Pôle de coordination est leader. Il a la capacité de motiver, inspirer et encourager les autres à atteindre un objectif. Il sert également de coach et de mentor pour guider les autres vers la réussite.
Cependant, il est à noter que les compétences nécessaires peuvent varier en fonction de la taille et de la complexité de l’entreprise, ainsi que de la nature de son secteur d’activité.
Pour les grandes entreprises, il peut être nécessaire de décomposer chaque Domaine en 3 Sous-Domaines fonctionnelles tout en respectant la même logique de décomposition :
- Administratif : Cette section est responsable de l’administration et de la gestion des ressources et des activités de l’entreprise. Elle comprend des fonctions telles que la comptabilité, le juridique, les Achats, le personnel, les relations avec les actionnaires et les partenaires, l’information et l’analyse des données, le développement des produits et des services, et la planification des stratégies.
- Production : Cette section est responsable de la fabrication des produits et des services de l’entreprise. Elle comprend des fonctions telles que la recherche et le développement, la conception, la logistique, la fabrication, l’assemblage et le contrôle de qualité des Produits et Services.
- Commercialisation : Cette section est responsable de la promotion des produits et des services de l’entreprise. Elle comprend des fonctions telles que le marketing et la publicité, le développement des ventes, la gestion des relations avec les clients et la gestion des canaux de distribution.
Exemple en synthèse :
- Administration: Corporate
- Ressources humaines ; Comptabilité ; Paie ; Achats ; Partenaires ; Juridique
- Sécurité et Fraudes
- Production
- Marketing Produit et Service
- Produit ; Service
- Usage, Consommation
- Logistique infrastructure matériels/matériaux consommables ; Déploiement
- Contrôle qualité
- Commercialisation
- Marketing commerciale et publicitaire
- Canaux de distribution ; Médias et réseaux de vente
- Vente ; Proposition commercial ; Devis ; Commande ; Facture
- Support de la Relation Client
Les Domaines peuvent échanger directement entre eux et chaque message est systématiquement envoyé en copie au Pôle de coordination auquel ils sont rattachés.
Le Pôle de coordination dialogue avec chacun de ses Domaines pour ajuster les directives.
Les Domaines rendent compte au Pôle de coordination à chaque lancement et fin d’activité.
Dans le cas d’un Domaine décomposé en Sous-Domaines,
- Le Pôle de coordination des Sous-Domaines rend compte après consolidation au Pôle de coordination du Domaine.
- Le Pôle de coordination du Domaine donne ses directives au Pôles de coordination de ses Sous-domaines qui a la charge de les intégrés afin de coordonner ses sous-directives aux sous-domaines.
- Décomposition
- Un Domaine peut se décomposer en sous-Domaine.
- Une directive peut se décomposer en sous-directives.
- Une Activité peut se décomposer en sous-activités.
- Consolidation
- Des sous-activités sont consolidés en activité.
- Des sous-directives sont consolidés en directive.
- Des sous-Domaines sont consolidés en Domaines.
crée une représentation interactive de votre entreprise en connectant et centralisant l’ensemble des informations liées aux métiers et au SI dans un référentiel commun.
→
Quid de la Traçabilité du système ?
La traçabilité des activités d’une entreprise est importante pour plusieurs raisons :
- Amélioration de la qualité : La traçabilité peut aider à identifier les causes profondes des problèmes et à améliorer la qualité des produits et des processus.
- Conformité réglementaire : Dans de nombreux secteurs, la traçabilité est obligatoire pour respecter les normes réglementaires et les exigences de conformité.
- Résolution des problèmes : La traçabilité peut aider à résoudre rapidement les problèmes en cas de besoin, en permettant de suivre les activités qui ont mené à un incident ou à un problème spécifique.
- Transparence et responsabilité : La traçabilité peut aider à renforcer la transparence et la responsabilité en ce qui concerne les activités et les décisions de l’entreprise.
- Amélioration de la prise de décision : La traçabilité peut fournir des informations précieuses pour l’analyse de données et la prise de décision, en permettant d’identifier les tendances et les opportunités d’amélioration.
En résumé, la traçabilité des activités d’une entreprise peut contribuer à une meilleure gestion, une meilleure qualité, une conformité accrue et une transparence accrue, tout en favorisant une prise de décision plus informée. La traçabilité peut aider à améliorer la qualité des données, à faire respecter les politiques de sécurité et à faciliter la résolution des problèmes en cas de besoin. De plus, la traçabilité peut être utilisée pour auditer les activités et les performances du système d’information.
En général, la traçabilité des activités dans une entreprise nécessite une combinaison de méthodes et de technologies pour assurer une surveillance complète et une collecte de données précise. Les entreprises peuvent choisir la solution de traçabilité la plus appropriée en fonction de leurs besoins en matière de conformité, de sécurité et d’efficacité opérationnelle.
Il existe plusieurs façons de tracer les activités dans un système d’information, notamment :
- Journalisation : Cela implique de consigner les activités dans un fichier journal ou un registre dédié. Ce fichier peut inclure des informations telles que les actions effectuées, la date et l’heure de ces actions, ainsi que les identifiants d’utilisateurs.
- Surveillance en temps réel : Certaines solutions de traçabilité peuvent surveiller en temps réel les activités dans le système d’information et enregistrer les informations correspondantes.
- Enregistrement des transactions : Les systèmes de gestion de bases de données peuvent inclure des fonctionnalités pour enregistrer les transactions, ce qui permet de suivre les modifications apportées aux données.
- Audits internes : Les audits internes peuvent être effectués périodiquement pour vérifier la conformité avec les politiques de sécurité et les normes de l’entreprise, ainsi que pour vérifier la qualité des données et la pertinence des informations enregistrées.
Pour assurer une traçabilité efficace et optimale d’un système ou d’une entreprise, il est important d’adopter une structure de traçabilité générique et homogène. Cela permettra de faciliter l’analyse des traces d’activité et d’alerter en cas variations impromptues.
Ces données peuvent être enregistrées dans un fichier journal ou un registre dédié, et peuvent être utilisées pour suivre les activités, détecter les anomalies et vérifier la conformité aux politiques de sécurité et aux normes de l’entreprise.
Pour avoir une traçabilité parfaite des activités dans un système d’information, il est recommandé d’enregistrer les Données suivantes :
- Qui ? Demandeur (Client), Identifiant de l’Acteur
- Quoi ? Objet de la Demande de Produit ou Service
- Où ? Adresse et Média de réception de la Demande
- Quand ? Horodate réception de la Demande
- Comment ? Eléments de qualification de la Demande
- Pour qui ? Destinataire (Serveur) à qui est destiné le Produit
- Pour quoi ? Motif de la Demande de Produit ou Service
- Pour où ? Adresse et Média d’émission du Produit ou Service
- Pour quand ? Horodate prévisionnelle d’émission du Produit
- Identité de l’Acteur : le nom d’utilisateur, l’adresse IP ou d’autres informations d’identification de l’Acteur qui a déclenché ou effectué une action donnée, Personne morale ou Physique, Système ou Transaction, Processus et Message pour pouvoir suivre et vérifier les activités de manière fiable
- Type d’action : catégoriser/classifier les types d’action et de les enregistrer, tels que la création, modification et suppression de données, la consultation et l’accès à des informations confidentielles ou données de sécurité pour vérifier la conformité aux réglementations, aux politiques de l’entreprise et aux obligations contractuelles, les Demandes, les Processus, les Accusés de réception et le Compte rendu d’exécution.
- Identifiant de la transaction : enregistrer un identifiant unique pour chaque transaction pour pouvoir suivre et vérifier les activités de manière fiable.
- Date et heure : la date et l’heure à laquelle une action a été demandée, effectuée et terminée pour pouvoir suivre les activités dans le temps.
- Informations de contexte : les informations de contexte liées à une action,
– telles que le lieu, la source de l’action et le but recherché, les commentaires de l’utilisateur pour mieux comprendre les motivations, les circonstances et les intentions entourant une action particulière
– telles que les étapes suivies et les informations de prise de décisions, pour améliorer la qualité des processus de l’entreprise
– telles que les matériaux, les matériels et les équipements, les ressources humaines, pour améliorer la gestion des ressources de l’entreprise
– telles que les noms, les rôles ou les profils, les droits te responsabilités, pour améliorer la collaboration et la communication entre les différents acteurs de l’entreprise - Données de performance : des informations sur les performances, telles que les temps d’exécution et les ressources utilisées, pour optimiser les performances du système.
Ces informations supplémentaires peuvent aider à améliorer la traçabilité des activités en fournissant une vue plus complète et détaillée de ce qui se passe dans l’entreprise, ce qui peut faciliter les décisions d’affaires et les processus d’audit.
Cependant, il est important de noter que ces informations supplémentaires peuvent également augmenter la taille et la complexité des données enregistrées, il est donc important de déterminer les informations les plus importantes pour atteindre les objectifs de traçabilité.
Dans l’Architecture de la LOI2S chaque Message
et Processus peut être journalisé soit en continue, soit à la demande à
un instant donnée ou pour une Période données. Les Traces sont de Structure homogène.
La journalisation des Messages et des Processus permet d’assurer la
transparence, la fiabilité et la conformité des activités dans un système
d’information.
· Suivi des activités : Enregistrer les
messages et les processus permet de suivre les activités de l’entreprise et de
vérifier si elles se déroulent comme prévu. Des mécanismes d’alerte permettent
de réguler la disponibilité des ressources nécessaires à la fluidités Process,
Processus et activités de manières manuelle ou automatisée.
· Résolution des erreurs : En cas d’erreur,
la journalisation des messages et des processus peut aider à localiser et identifier
les causes et à résoudre les problèmes plus rapidement.
· Audit : La journalisation des activités
peut être utilisée pour effectuer des audits internes et externes pour s’assurer
que les politiques et les réglementations sont respectées.
· Amélioration des processus : Les
informations recueillies grâce à la journalisation peuvent être utilisées pour optimiser
les processus de l’entreprise.
QUID de l’Architectures fractale LOI2S ?
La LOI2S repose sur le Paradigme Objet dont l’un de ses Concepts immanents est la généricité.
Une Architecture fractale est une modélisation et une implémentation qui présente une logique similaire à toutes les échelles et tous les points de vue.
Rappel : Une figure fractale est un objet mathématique qui présente une structure similaire à toutes les échelles.
Un objet fractal est un objet dont chaque Composant est aussi un objet fractal, ce qui permet de créer des systèmes complexes à partir de Composants simples et répétitifs.
L’urbanisation des systèmes d’information utilise des objets fractaux pour créer des systèmes complexes à partir Composants simples qui collaborent les uns avec les autres via un BUS à Messages, ce qui permet une urbanisation récursive des systèmes d’information..
L’Architecture fractale LOI2S permet donc de modéliser et d’implémenter des Systèmes informatiques complexes à partir de Composants simples et répétitifs, tout en respectant le Paradigme Objet et en exploitant la puissance de l‘Objet.
L’intérêt d’avoir un modèle de conception unifié « design pattern » permet une lecture un dialogue facilité pour l’ensemble des Acteurs concernées par le Système d’Information :
- Que ce soit au niveau d’un Composant élémentaire mono Processus ou de multiples Systèmes informations complexes interconnectés.
- Que ce soit par les acteurs de la MOA Maîtrise d’Ouvrage, les acteurs opérationnels du métier ou les acteurs de la MOE Maitrise d’œuvre Informatique, les concepteurs, les développeurs et les superviseurs.
Dans le cadre de l’Architecture LOI2S les fondamentaux utilisés sont appliqués et applicables tant pour une vision macroscopique du Système d’Information que pour sa décomposition en Microservices élémentaires du Système Informatique. La vision de l’activité métier de l’entreprise comme son implémentation et implantation dans son Système Informatique répondent au même paradigme : un réseau de transport de Messages captés ou émis par des Acteurs Personnes physiques ou morales, des Acteurs systèmes mécaniques ou informatiques. Ces Acteurs sont implémentés dans le Système d’Information sous forme d’Objets ou Composants informatiques : Vision numérique d’un Monde réel et virtuel.
Chaque Composant répond au modèle unifié de la LOI2S et doit couvrir les fonctions essentielles à leur autonomie et au respect du Paradigme Objet pour garantir les Facteurs qualités attendus :
- Une Interface entrante qui capte des Messages numériques ou des Messages analogiques
- Une Interface sortante qui émet des Messages numériques ou des Messages analogiques
- Une Catalogue qui transcrit les informations numériques en informations sémantiques
- Une Annuaire qui identifie et référence tous les Objets de l’Architecture
- Une Profil de Compétences qui habilite les Messages à exécuter des Processus
- Un Planificateur qui ordonnance l’exécution des Processus déclenché par un Message habilité
- Un Processus qui transforme l’Informations des Données indexées et mémorisées sous l’impulsion de Messages et pouvant émettre des Messages
- Une Base d’Index qui permet de requêter des Données à partir d’informations
- Une Base de Données qui mémorise les Informations structurées dans des Données
Chacune de ces fonctions pouvant elles-mêmes être un composant respectant la LOI2S. Ainsi on peut architecturer, dans les extrêmes, son système d’information avec un Composant unique ou avoir autant de Composants que de Processus métier répondant chacun à un Message ou Demande de Service spécifique.
Chaque Message répond au modèle unifié de la LOI2S avec un en-tête générique qui facilite et garantit la traçabilité, la supervision et l’ajustement de l’activité.
crée une représentation interactive de votre entreprise en connectant et centralisant l’ensemble des informations liées aux métiers et au SI dans un référentiel commun.
→
est une norme d'architecture d'entreprise ouverte et indépendante qui prend en charge la description, l'analyse et la visualisation de l'architecture.
→
décrit une architecture de référence pour gérer l'activité des technologies de l'information (IT) et la gestion du cycle de vie associée de bout en bout.
→
montre où trouver des concepts durables et universels et des meilleures pratiques éprouvées d'architecture d'entreprise.
→
montre où trouver des concepts durables et universels et des meilleures pratiques éprouvées d'architecture d'entreprise.
→
QUID de l’Architectures Microservices en LOI2S ?
La LOI2S repose sur le Paradigme Objet pour garantir les Facteurs qualité attendus : Lisibilité – Vérifiabilité – Validité – Confidentialité – Rapidité – Fiabilité – Robustesse – Ergonomie – Facilité – Efficacité – Compatibilité.
Pour répondre à ces Factures de qualité les Objets ou Composants LOI2S doivent répondre à certaines propriétés inhérentes aux Architectures Orientés Objets : Atomicité – Cohérence – Intégrité – Persistance – Modularité – Généricité – Extensibilité – Optimisation – Réutilisabilité – Normalisation.
L’Architecture microservices est une approche pour la conception de systèmes d’information où une application est divisée en plusieurs petits services web autonomes qui fonctionnent ensemble pour fournir une fonctionnalité globale. Chaque service est construit pour effectuer une tâche spécifique et est conçu pour fonctionner de manière indépendante des autres services.
Les avantages de l’Architecture microservices incluent une plus grande flexibilité et une évolutivité plus facile. Les services peuvent être développés, déployés et gérés de manière indépendante, ce qui permet une mise à jour plus rapide et une correction des bugs plus efficace. De plus, les microservices peuvent être développés dans différents langages de programmation, ce qui permet une utilisation plus appropriée des outils et des compétences disponibles.
Cependant, il existe également des inconvénients potentiels à l’utilisation de l’Architecture microservices. La complexité de la gestion d’un grand nombre de services peut être un défi, et il peut être difficile de déterminer les points de défaillance en cas de panne. De plus, la communication entre les services peut être lente si elle n’est pas bien conçue, ce qui peut affecter les performances globales du système.
En résumé, l’Architecture microservices est une approche pour la conception de systèmes d’information qui peut offrir des avantages significatifs en termes de flexibilité et d’évolutivité. Cependant, elle présente également des défis potentiels en termes de gestion de la complexité et de performance globale.A
Apache Docker est un outil open source qui permet à des développeurs de créer des conteneurs Docker à partir d’applications exécutées sur un serveur Apache. Les conteneurs peuvent être facilement déployés et gérés sur des serveurs physiques ou virtuels. Les conteneurs peuvent également être partagés et déplacés entre différentes plateformes sans avoir à modifier le code de l’application. Apache Docker permet aux développeurs de créer des applications plus robustes et plus portables, qui peuvent être déployées et exécutées sur n’importe quel système.
Toutes ces atouts sont ceux recherchés dans l’émergence des Architectures Microservices visant l’évolutivité et la scalabilité grâce à la modularité granulaire de microservices autosuffisants pouvant être instanciés par nécessité dans des Conteneurs applicatifs d’Architecture Docker.
Rappel : Un Conteneur Docker permet l’exécution d’un package logiciel léger, autonome et exécutable. Les conteneurs sont indépendants de la plate-forme système informatique qui permet leur exécution.
La LOI2S fait correspondre les Concepts suivants :
Message métier <-> Microservice <-> Processus métier
Composant métier <-> Macroservice <-> Ensemble de Processus métier
encapsulés dans des Objets métier
répondant à différents Messages métier/Microservices connexes.
- Le Message métier est la Demande de Service métier.
- Le Processus métier est l’exécution de la prise en compte de la Demande de Service.
- Le Composant métier est une Application encapsulant à un ou plusieurs Service
- Un Composant métier est instancié au besoin dans les Conteneurs de l’Architecture Docker.
- La granularité la plus fine correspondant à un seul Processus métier par Composant.
- La granularité monolithique correspondant à un seul Composant englobant tous les Processus métier de l’entreprise (ERP : Enterprise Ressource Planning / Progiciel de Gestion intégré).
Les Fonctions génériques des Composants Conteneur de la LOI2S rend les Microservices autonomes : Numérisation – Analogisation- Transcription- Identification- Habilitation- Affectation- Transformation- Indexation- Mémorisation – Communication – Instanciation
La L0I2S au travers de sa MOM Modélisation Objet Métier facilite une Gouvernances Agile du Système d’information : des Equipes pluridisciplinaires autonomes. Chaque Equipes a la responsabilité de l’évolutions de tel ou tels Composants de l’Architecture d’Entreprise. Sachant que les spécifications des Messages inter Composants sont préétablies lors de la conception de l’Architecture d’Entreprise.
La généricité des Composants de la LOI2S facilite l’intégration granulaire des Services métiers d’une part pour la MOA Maitrise d’Ouvrage métier et d’autres part pour l’implémentation des Conteneurs de l’Architectures Docker par le MOE Maitrise d’Œuvre Informatique qui doivent supporter l’ensemble des Fonctions génériques sous-jacentes.
Rappel : Docker rend le développement efficace et prévisible
Docker supprime les tâches de configuration répétitives et banales et est utilisé tout au long du cycle de vie du développement pour un développement d’applications rapide, facile et portable – bureau et cloud. La plate-forme complète de bout en bout de Docker comprend des interfaces utilisateur, des CLI, des API et une sécurité qui sont conçues pour fonctionner ensemble tout au long du cycle de vie de la livraison des applications.
QUID de la Modélisation métier de Système d'Information LOI2S ?
La LOI2S repose sur le Paradigme Objet pour garantir les Facteurs qualité attendus.
On modélise des objets du monde réel manipulés par les opérationnels du métier de l’entreprise.
Les Objets métier encapsulent des Informations et de Processus de transformation et de mémorisation des informations. Les Informations référencées dans un Objet métier ne peuvent manipulées que par les Processus référencés dans ce même Objet métier. L’exécution des Processus ne peuvent-être déclenchées que par des Messages habilités. Les Processus peuvent émettre des Messages.
La modélisation du métier de l’entreprise va consister à typer toutes ces Versions Type d’Objets génériques en les spécialisant pour imager numériquement le métier de l’entreprise :
- Les Composants métier groupés par Domaine métier.
- Les Objets métier groupés dans des Composants métier.
- Les Données métier et les Processus métier encapsulés dans des Objets métier.
- Les Informations métier structurées dans des Données métier.
- Les Messages métier déclenchés ou émis par des Processus métier.
- Les Processus métier imbriqués en des Process métier.
Nota : L’extension métier n’est qu’une spécialisation des Objets génériques de l’Architecture de la LOI2S. Cette couche métier rend abstrait les problématiques propres à l’implémentation informatique de l’Architecture technique tout en respectant les mêmes principes et concepts.
Dans le logique d’un système d’information orienté Objet tout est Objet spécialisé d’un Objet Type originel. Une Version Type d’Objet instancie des instances d’Objets de même Type ayant
- des caractéristiques communes à toutes les Instances
- Un Type qui le conceptualise sémantiquement, la dénomination du Type d’Objet appelé aussi communément Modèle
- Une Version qui trace l’évolution successive des Objets de même Type
- des caractéristiques propres à chacune des Instances :
- Un Identifiant d’Objet unique et invariant
- Une ou plusieurs Références qui l’identifie à un moment donné dans un contexte donné
- Une chronologie d’Etat qui historise les transitions d’informations de l’Objet au cours du temps
- Horodate
- Etat
- Une Donnée qui agrège de manière structurée des Données, des Informations et/ou des Objets.
De cet Objet Type originel découle les Objets génériques de l’Architecture de la LOI2S :
- Les Données qui structurent des réceptacles d’Informations.
- Les Messages qui agrègent des Données pour déclencher des Processus.
- Les Processus sont des Données spécialisées en structure d’Informations codées dans un langage spécifique de manipulation et de mémorisation de l’information.
- Les Objets métier qui représentent une image numérique des objets du monde réel nécessaires à la pratique d’un métier, d’une entreprise de production ou de service.
Les Objets métier encapsulent des Données et des Processus - Les Composants de l’Architecture de la LOI2S agrègent les Objets génériques essentiels au respect du Paradigme Objet pour garantir les Facteurs qualités
- Une Interface entrante qui capte des Messages numériques ou des Messages analogiques
- Une Interface sortante qui émet des Messages numériques ou des Messages analogiques
- Une Catalogue qui transcrit les informations numériques en informations sémantiques
- Une Annuaire qui identifie et référence tous les Objets de l’Architecture
- Une Profil de Compétences qui habilite les Messages à exécuter des Processus
- Un Planificateur qui ordonnance l’exécution des Processus déclenché par un Message habilité
- Un Processus qui transforme l’Informations des Données indexées et mémorisées sous l’impulsion de Messages et pouvant émettre des Messages
- Une Base d’Index qui permet de requêter des Données à partir d’informations
- Une Base de Données qui mémorise les Informations structurées dans des Données
QUID des Cartographies de l’Architecture d’Entreprise ?
La LOI2S propose différentes visions du métier qui peuvent être cartographiées :
- La vision Composants Consommateur et Fournisseur de Messages vers les BUS à Messages. Les Composants sont regroupés par affinité en Domaine métier.
- La vision Process construite par l’enchainement des Messages réceptionnés et envoyés par les Processus encapsulés dans les Objets métier gérés par les Composants.
- La vision Informations structurées dans les Données des Objets métier encapsulant les Processus Consommateur de Messages entrants et Fournisseur des Messages sortants.
Ces 3 visions du métier sont interdépendantes. La cohérence ou l’intégrité de l’Architecture d’Entreprise est vérifiable :
- Tous les Messages des Domaines Métiers sont identifiés dans des Process métier.
- Tous les Messages sont en entrée ou en sortie de Processus.
- Tous les Processus sont encapsulés dans des Objets métier.
- Toutes les Données des Messages des Processus de chaque Objet métier sont encapsulées dans cet Objet métier.
- Toutes les Données des Messages de chaque Composant sont encapsulées dans des Objets métiers de ce Composant.
- Domaine métier
- Liste les Composants
- Liste des Objets métier
- Liste des Données
- Liste des Processus métier
- Liste des Process métier
- Liste des Objets métier
- Liste les Composants
- Process métier
- Liste des Processus
- Liste des Messages
- Liste des Données
- Liste des Objets métier
- Liste des Données
- Liste des Messages
- Liste des Processus
- Objet métier
- Liste des Données
- Liste des Processus
- Liste des Messages
- Liste des Domaines métier
- Liste des Process métier
- Liste des Données
- Liste des Objets métier
- Liste des Messages
crée une représentation interactive de votre entreprise en connectant et centralisant l’ensemble des informations liées aux métiers et au SI dans un référentiel commun.
→
QUID de la persistance et de l’accès aux informations ?
La LOI2S propose différents Composants ou Fonctions génériques qui imposent nécessairement une persistance d’Informations :
- Catalogue pour coder des Informations et transcrire leur sémantique
- Annuaire pour référencer et identifier des Objets et leurs Données
- Profil de compétences pour habiliter le déclenchement des Processus
- Planificateur pour planifier les Processus à instancier ou instanciés
- Processus pour coder
– les règles de changement d’Etat des Informations et,
– l’émission de Messages - Base Index pour faciliter les recherches et les agrégations analytiques d’informations
- Base de Données pour mémoriser les structures d’informations persistantes altérées
Il existe différents types de systèmes de mémorisation et de consultation des Informations plus ou moins adaptés aux usages (volumétrie, concurrence et performance d’accès, contexte de recherche, agrégation statistique ou association, taux d’activité, archivage, trace historique, etc.).
Les principaux systèmes de gestion de la persistance d’informations :
- Les Tables relationnelles (SQL Structured Query Language)
(ORACLE, SQLServer, PostgreSQL, MySQL, MariaDB, etc.) - Les Documents de structures variables et adaptables
NoSQL, BSON Binary JSON JavaScript Object Notation (clé : valeur)
(MongoDB) - Les Documents Texte (algorithme d’indexation Lucène)
(ElasticSearch , Apache SolR)
Nota : Les Informations clés et les structures d’informations, etc. sont en redondance avec les Informations en Base de Données mais avec une organisation de mémorisation ou d’indexation spécifique optimisée pour la recherche et le calcul d’agrégats analytiques.
Une Base Index peut servir de Cache Index pour les Bases de Données ayant des structures d’indexation moins performante.
Rappel : Les différents SGBD Systèmes de Gestion de Bases de Données
Système hiérarchique où chaque structure d’informations compose des structures d’informations (enfants) et chaque structure d’informations dépend d’une seule structure d’informations (parent)
Système réseau où chaque structure d’informations a des liens multiples entre c.
Système relationnelle où certaines informations de chaque structure d’informations (sous forme de Tableaux en 2 dimensions : Tables) identifie d’autres structures d’informations (Tables) en relation. Système le plus rependu et qui a donné lieu à un langage de requête adapté de manipulation de ces Tables SQL Structured Query Language.
Système orientée objet où les structures d’informations dispose de pointeur vers d’autres Structures d’informations adoptant les concepts de la programmation Objet.
Système orientée texte où les structures d’informations sont des documents textes ou binaires
Système distribuée où les structures d’informations sont mémorisées en sous-ensembles distribuées physiquement.
Système cloud où les structures d’informations sont mémorisées dans des environnements virtualisés privé, public ou hybride.
Système NoSQL où les structures d’informations sont des documents de structures variables est adaptables documents pas documents par oppositions structures des Tableaux structures des systèmes relationnel SQL.
Système orientée graphes où les structures d’informations profilent des graphes relationnels et facilitent la navigation dans ces graphes.
QUID d’Apache Kafka et le BUS à Messages ?
Apache Kafka est un système open source de gestion des flux de données, qui permet aux entreprises de créer des flux de données de manière fiable et efficace à grande échelle pour l’analyse et le traitement des données. Il fournit des intégrations faciles avec les systèmes existants et des capacités de streaming pour traiter les données en temps réel. C’est un système de messages pub-sub distribué, qui peut être utilisé pour diffuser des messages à travers des systèmes répartis, et offre une grande disponibilité, une tolérance aux pannes et une scalabilité linéaire. Kafka est un outil flexible et puissant qui peut être utilisé pour la mise à l’échelle de l’analyse de données, le traitement des transactions et le traitement des événements en temps réel. Il peut également être utilisé pour construire des pipelines de traitement des données, qui peuvent être utilisés pour transformer des données brutes en informations qualifiées.
Un système de messages pub-sub distribué est un type de communication entre les ordinateurs où les messages sont publiés par un certain nombre de sources et sont ensuite diffusés à un certain nombre de destinataires. Les messages sont envoyés à un serveur de messages qui les distribue aux abonnés. Les abonnés peuvent alors recevoir et réagir aux messages reçus. Ce type de système est souvent utilisé pour le partage de données entre les applications et est très efficace pour la mise en œuvre des applications distribuées.
Dans la LOI2S chaque Type de Message numérique inter-Composants correspond à un Topic déclaré dans le Composant BUS à Messages Kafka.
Plusieurs Composants Producteurs peuvent envoyer des Messages de même Type qui s’empilent dans un même Topic.
Chaque Composant Consommateur peut s’abonner aux Topics et donc aux Messages auxquels il est susceptible de pouvoir les faire traiter par ses Processus.
Chaque Composant Consommateur a son curseur et son rythme de lecture de chacun des Topics auxquels il est abonné.
Comme tous Messages DDE de demande de service nécessite au minimum un Message AR Accusé réception et un Message CRF Compte-rendu d’exécution final. Tous les Composants sont Fournisseurs et Consommateurs de Topics.
Kafka permet d’avoir plusieurs Composants Consommateurs pour un même Topic ou Type de Message.
Kafka permet d’avoir plusieurs instances de Composants Consommateurs, ajouter et supprimer à chaud, dans un Consumer Group pour paralléliser la prise en charge des instances d’un même Type de Message et ainsi augmenter le débit du flux de traitement des instances d’un même Type de Message ou libérer des ressources latentes.
Kafka offre également de multiples possibilités en termes de composants fournisseurs et consommateurs de données, et permet d’avoir plusieurs instances de composants avec une scalabilité dynamique, ajouter et supprimer à chaud, dans un Consumer Group pour paralléliser la prise en charge des instances d’un même type de message et ainsi augmenter le débit du flux de traitement des instances d’un même Type de Message ou libérer des ressources latentes.
Les propriétés de Kafka répondent aux Facteurs qualité attendus par la LOI2S :
- Évolutivité
- Rétention
- Durabilité
- Réplication
- Sécurité
- Élasticité
- Débit
- Commande
- Unicité sémantique
- Transaction
- Idempotence
- Immutabilité
- Traçabilité
Nota : L’objectif ici n’est pas de décrire le fonctionnement interne d’un Composant Kafka mais de montrer son intégration fonctionnelle dans la LOI2S.
QUID du Méta-Modèle LOI2S pour le métier ?
Dans la LOI2S tout est Objet. Chaque concept hérite du Paradigme Objet et des Concepts Objets.
L’Objet se spécialise en Type qui représente le niveau de modélisation le plus abstrait pour caractériser/spécialiser les Concepts fondateurs de l’Architecture LOI2S :
- Type, Version Type, Code Catalogue et Dictionnaire
- Objet, Donnée, Information
- Base Index et Base de Données
- Message ciblé ou diffus, Processus, Planificateur de Processus
- Profil de compétence, Annuaire, Catalogue
- Composant, Interface, entrante ou sortante, analogique ou numérique
Pour différencier l’expérience l’opérationnelle métier maitrisée par la MOA Maitrise d’Ouvrage certains concepts sont déclinés « métier » :
- Objet métier et Données métier
- Message métier et Processus métier
- Profil de compétences métier
- Interface métier
- Domaine métier
Cette distinction ne change pas les principes de la LOI2S mais permet seulement de distinguer, – la partie émergée maîtrisée par les métiers, – des notions plus techniques comme la mise ne place de Composants, d’Annuaires, de Bases Index ou Bases de données, de Planificateurs des Processus et certains Messages, l’administration et la supervision du SI sous la responsabilité de la MOE DI Direction Informatique.
La Modélisation du Système d’information par la MOA consiste donc à spécifier les concepts suivants :
- Les Types (dénomination) des Objets métier et identifier leur(s) Données métier de Référence
- Les Données métiers et les Informations encapsulées dans les Objets métier
- Les Processus métier encapsulés dans les Objets métier
leurs Règles métier d’émission de Messages inter-Objets métier
leurs Règles métier de changement d’Etat - Les Messages métier et leurs Données métiers transportés, la nature synchrone ou asynchrone des Messages métier
- Les Interfaces métier des opérationnels métier utilisateurs du Système d’Information et
les Interfaces métier de communication numérique inter-Entreprises Clientes et Partenaires - Les regroupements de ces notions par Domaine métier ainsi que les Profils métier d’habilitation à l’usage du Système d’Information
La MOE et la MOA maitrise conjointement tous les concepts métier de la LOI2S.
QUID des Process métier et Processus métier (BPMN: Business Process Model and Notation) ?
La LOI2S qualifie de Process métier une succession conditionnelle de Processus métier, qui s’exécutent séquentiellement ou parallèlement. Le Process métier est initié ou déclenché par un Message entrant initial et se termine par un Etat stable et persistant des Objets métier impliqués dans une succession d’exécution de Processus.
Un Processus est déclenché par un Message entrant. Un Processus peut émettre des Messages sortants destinés à d’autres Processus.
Rappel : La LOI2S distingue la Modélisation métier spécifiée par les MOA Maîtrise d’Ouvrage de l’implémentation logicielle informatique spécifiée, produite et maintenue par la MOE Maitrise d’œuvre informatique. Néanmoins les paradigmes restent identiques, La MOA ne présentant que les notions métier faisant abstraction des problématiques purement informatiques : langages de programmation, persistance et indexation des informations, Protocoles de communication inter logiciels, Intégrité technique, etc.
Les composantes de la Modélisation métier :
- Process métier
- Processus métier
- Message inter Processus métier
- Domaine métier
- Objet métier
- Processus métier
- Donnée
- Objet métier
Un Domaine métier est un regroupement d’Objets métier ayant de fortes affinités, c.à.d. des échanges importants de Messages entre leurs Processus métier. Ces Domaines métier correspondent en générale à des Profils de Compétences métier spécifiques (Marketeur, Vendeur, Logisticien, Installateur, etc.) et s’aligne peu ou prou avec l’organisation opérationnelle de l’entreprise.
Un Objet métier est un concept représentant une Modélisation des Objets du Monde réel, Ressources (humaines, matériaux, fournitures ou produits, matériels ou outils).
L’Objet métier encapsule des Données ou structures d’informations, propriétés manipulées par ses Processus métier responsables de garantir sa validité, son intégrité et sa cohérence.
Le Processus métier spécifie :
- le Type de Message entrant instancieur de son exécution,
- les conditions d’émission de chaque Messages sortant,
- les Données d‘Objets métier transportées par chaque Message entrant ou sortant
La cohérence de la modélisation s’assure que chaque Type de Message comporte bien les Données nécessaires et donc les informations utiles au Processus métier pour conditionner chaque Message sortants.
BPMN : Business Process Model and Notation
Au même titre qu’il existe un langage Unifié de Modélisation de Système d’Information (UML Unified Modeling Language) , il existe une notation de la Modélisation des Process métier (BPMN Business Process Model and Notation).
L’analogie entre la terminologie la BPMN et la LOI2S est la suivante ;
- Les activités décrivent l’action à mener par instance de Processus métier (tâche = Unité de lieu, de temps et d’acteur, transaction = intégrité de l’Objet métier dans un Etat persistant, sous-processus = décomposition d’un Processus)
- Les Evènements représentent les Messages entre les Processus métier (Message instancieur, de début de Process métier ou intermédiaire, Message sortant final). Un Process métier identifie les Messages CR de fin et Processus de fin qui ne déclenche plus de Message sortant.
- Les Flux de contrôle représentent les conditions d’émission des Messages sortants par le Processus métier.
Nota : Un Process métier peut le cas échéant impliquer plusieurs Domaines métier.
QUID des notions de Front-Office, Middle-Office et Back-Office ?
Les notions de Front-Office, Middle-Office et Back-Office sont liées au métier de l’entreprise.
Le Front-Office (Guichet) regroupe les Processus en relation directe avec les Clients, les Partenaires, personnes morales ou personnes physiques. C’est la partie visible de l’extérieur par le Clients et Partenaires de l’activité d’une entreprise.
Interface web, Suivi de Commandes, Automates de vente, etc.
Le Middle-Office (Support des Guichets) regroupe les Processus qui concourent ou sont nécessaires au bon fonctionnement du Front Office.
Gestion des Risques, Marketing commercial, Support technique, Logistique interne, etc.
Le Back-Office (Arrière-Guichet) regroupe tous les Processus administratifs, de contrôle et de conception des Produits et Services de l’entreprise.
DRH Direction des Ressources Humaines, DSI Direction du Système d’Information, Marketing Produits et Services, etc.
Cette subdivision des Processus de l’entreprise tend à disparaitre pour concourir à l’efficience des Objets métier et des Process métier de bout en bout regroupés par affinité d’interactions en Domaines métier, et ceux avec une plus grande transparence des Processus internes de l’entreprise et une meilleure implication des Clients et Partenaires (la digitalisation des Systèmes d’Information les rendant de plus en plus autonome).
Nota : Ces notions ne doivent pas être assimilées aux notions Front-end, Middleware, Back-end propres aux systèmes informatiques.
QUID des notions de Front-end, Middleware et Back-end ?
Les notions de Front-end, Middleware, Back-end sont liées aux infrastructures de Systèmes Informatiques.
Le Front-end est la couche externe des Composants, leurs interfaces de communications inter Composants numériques ou avec le Monde réel analogique (IHM : Interface Homme Machine, écran, clavier, souris, SVI Serveur vocal interactif, etc.)
Le Middleware est une couche intermédiaire entre le Front-end et le Back-end qui sert de médiateur entre les Composants du SI (BUS à Messages, Messagerie, Réseaux informatiques).
Le Back-end est une couche sous-jacente en support aux fonctions génériques des Composants du SI, des logiciels, progiciels, machines virtuelles et systèmes d’exploitation et système de persistance de données numériques sur lesquels s’appuient les Composants du SI pour mémoriser les Informations et exécuter leur Processus.
Les développements et l’exploitation de chacune de ces couches logicielles requièrent des technologies et des compétences informatiques spécifiques propres : Administrateur réseau, Administrateur de Base de données, Responsable Sécurité SI, Développeurs orientés Front-end, Middleware, Back-end, etc.
Nota : Ces notions ne doivent pas être assimilées aux notions Front-Office, Middle-Office et Back-Office liées à l’organisation des Processus métier de l’entreprise.
QUID des Messages synchrones et asynchrones ?
Dans la LOI2S la communication des Messages numériques inter Composants émis par les Processus sont de 2 Types :
- Synchrone en temps réel, le Processus émetteur est en attente d’une réponse
- Asynchrone en temps différé, le Processus émetteur n’attend pas de réponse
Rappel :
Les Composants ou plus précisément les Processus de la LOI2S communiquent entre eux au travers de Messages ciblés ou de Messages diffus.
- Un Message ciblé est un Message dont le ou les Composants destinataire sont identifiés.
- Un Message diffus est un Message sans Composant destinataire désigné. En fonction du Type de Message ce sont les Composants qui captent les Messages disponibles sur le BUS à Messages.
Dans un Système d’Information distribué massivement parallèle la validité, l’intégrité et la cohérence des informations nécessitent une attention particulière. Chaque Objet métier, chaque Donnée doivent préserver un Etat valide et cohérent malgré la sollicitation de multiples Messages asynchrones émis pas différents Composants internes ou externes au SI.
Un Processus amené à changer l’état d’Objets doit bloquer l’accès aux Objets impliqués et interdépendants durant toute la durée de son exécution, c.à.d. le déclenchement de tous autres Processus impliquant ces mêmes Objets. Le Processus doit garantir l’intégrité et la cohérence de l’Etat des Objets en fin d’exécution. On parle de Processus transactionnel ou Transaction. Si le Processus s’est exécuté correctement, les Objets impliqués ou interdépendants conservent un Etat valide, cohérent et intègre, sinon dans le cas contraire, en cas de dysfonctionnement, l’Etat des Objets impliqués doivent rester dans l’Etat précédent le début de l’exécution du Processus. Le Message initiateur du Processus est renvoyé à son émetteur avec un Compte rendu d’Erreur.
Il appartient à chaque émetteur ou Composant Fournisseur de Message de savoir interpréter les Messages d’AR Accusé Réception ou de CR Compte Rendu.
QUID d’un Message synchrone ?
Le Processus instancié qui émet un Message DDE de Demande (requête ou service délégué) reste en attente d’une réponse immédiate pour continuer l’exécution en cours dont la suite dépend de l’acquittement du Message AR d’Accusé Réception, du Message CR de Compte Rendu de prise en compte. On parle de traitement séquentiel, d’algorithme séquentiel ou d’algorithme série, étape par étape ou pas à pas.
Dans ce cas le Processus reste instancié dans le Composant qui l’encapsule durant la prise ne charge du Message de délégation de service. Les Objets impliqués ou interdépendants bloquent tous autres Processus concernant tous ces Objets.
QUID d’un Message asynchrone ?
Le Processus instancié qui émet un Message DDE de Demande (requête ou service délégué) n’attend pas de réponse pour continuer son exécution. Le Message AR d’Accusé Réception et le Message CR de Compte Rendu sont pris en charge par d’autres instance de Processus dans un temps différé plus au moins long. On parle de traitements parallèles ou simultanés.
Dans ce cas chaque Processus est instancié et s’exécute indépendamment les uns des autres ayant chacun leur propre temps d’exécution. On parle de traitements parallèles d’algorithme parallèle ou d’algorithme simultanée.
Dans ce cas la coordination entre les différents Messages asynchrones doit être pris en charge par chaque Processus en se référant à l’Etat des Objets manipulés ou interdépendants au moment de son exécution. Des règles de priorité ou d’accès concurrents doivent être mise en place dans les Processus : l’Etat des Objets impactées détermine si le Processus accepte, refuse ou diffère la prise en compte du Message.
QUID de la Modélisation des Objets métier ?
La LOI2S se base sur le paradigme Objet pour définir l’écosystème de l’architecture d’un Système d’information. Il n’en reste pas moins que l’objectif premier d’un Système d’information est d’augmenter l’efficience d’un métier. Grâce à la numérisation du monde réel (les Objets et leurs manipulations) l’informatique apporte par sa puissance de référencement et de calcul numérique l’accessibilité, la lisibilité, la facilité de pilotage et de simulation d’un monde complexe et diversifié.
Le paradigme Objet est une approche pragmatique qui commence par numériser la réalité du monde réel ou plus exactement la réalité physique d’un métier tant dans ses objets matériels ou outils que dans ses procédures ou règles de fonctionnement du métier. Ce n’est que dans un deuxième temps, par couplage du monde réel au monde virtuel numérique que seront optimiser les outils du métier et les procédures d’usage. Ce qui pourra amener à revoir le fonctionnement même du métier et de ses outils de production associés.
La démarche commence donc par un recueil des besoins ou plus exactement par l’appropriation de l’existant pour faire suite à une modélisation du métier (MOM : Modèle Objets Métier). Cet existant est exprimé par les opérationnelles du métier au travers d’un langage enrichi de concepts propres aux spécificités de chaque métier. D’où l’importance de la mise en place d’un Dictionnaire métier d’unification de toute la sémantique utilisée par les opérationnelles métier communément appelé MOA Maitrise d’Ouvrage en opposition à la MOE Maitrise d’œuvre chargé de la réalisation et de l’implantation du projet d’informatisation ou de digitalisation.
La LOI2S est un socle ou une plateforme générique d’implémentation de Système d’Information garantissant une optimisation des Facteurs qualité : Lisibilité – Vérifiabilité – Validité – Confidentialité – Rapidité – Fiabilité – Robustesse – Ergonomie – Facilité – Efficacité – Compatibilité.
Le MOM de modélisation du métier est simple afin d’être accessible à tous MOA et MOE :
- Objet métier
- Donnée
- Information
- Processus
- Message
Un Objet métier est la représentation conceptuelle d’une Ressource (humaine, matériaux, fourniture ou produit, matériel ou outil). Chaque Objet métier a des caractéristiques ou propriétés modélisées dans des Données : structure ou réceptacle organisé d’informations. Les Données spécialisées en Processus spécifient les transformations possibles de ses Informations durant le Cycle de vie l’Objet métier. L’Objet métier passe ainsi par différents Etat persistant et temporaire de son instanciation (Etat initia) à son archivage ou suppression (Etat final).
Chaque Objet métier répond à des sollicitations modélisées par des Messages pour exécuter des traitements modélisés par de Processus sur ses Données et émettre des Messages de délégation ou de Compte rendu vers d’autres Objets métier.
Message => Objet métier => Processus => Message(s)
Toutes les instances de Type d’Objets métier devront avoir une ou plusieurs Références (une ou plusieurs informations) qui les identifient de manière unique au sein du Système d’information.
Nota : La Modélisation du métier par la MOA fait abstraction de l’Architecture générique de la LOI2S qui est de la responsabilité de la MOE c.à.d. de la Direction informatique.
Un Objet métier est une liste organisée de Données. Certaines Données sont des Processus et d’autres des structures de mémorisation d’Informations
crée une représentation interactive de votre entreprise en connectant et centralisant l’ensemble des informations liées aux métiers et au SI dans un référentiel commun.
→
QUID de la Supervision applicative : Traces logs ?
La LOI2S se base sur 3 composantes (Messages, BUS à Messages, et Processus) pour superviser et réguler l’activité Système d’Information.
Les Messages transportent les Données pour déclencher des Processus encapsulés dans des Composants distribués du SI.
Les Composants BUS à Messages temporisent les Messages émis pour les Processus des Composants Fournisseurs pour les délivrer ou les mettre à disposition aux Composants Consommateurs de ces Messages.
Message
Les Messages sont porteurs d’informations dans leur Données d’entête générique pour faciliter la supervision applicative :
- Donnée d’entête de Message
- Horodate d’instanciation du Message
- Référence de l’Instance du Composant instancieur du Message
- Référence de l’Instance du Processus Instancieur du Message
- Horodate de prise en charge par une Instances de BUS à Messages
Processus
Les Processus disposent d’un Interrupteur de traçabilité qui permet d’émettre des Traces logs génériques dans leur structure d’Informations pour faciliter l’analyse l’activité des Composants du SI :
- Trace logs d’instanciation du Processus
- Horodate d’instanciation du Processus
- Référence de l’Instance du Composant instancieur du Message
- Référence de l’Instance du Processus Instancieur du Message
- Référence du Message instancieur du Processus
- Trace logs d’instanciation d’un Message émis par le Processus
- Horodate d’instanciation du Processus
- Référence de l’Instance du Composant instancieur du Message
- Référence de l’Instance du Processus Instancieur du Message
- Référence du Message instancieur du Processus
- Horodate d’instanciation du Message en émission par le Processus
- Référence du Message en émission par le Processus
Les Traces Logs peuvent être complétées par les Références des Données manipulées par le Processus. Cette structure d’Informations est propre à chaque Type de Processus.
BUS à Messages
Le BUS à Messages dispose aussi d’un Interrupteur de traçabilité qui est globale à l’activité de ce Composant ou propre à un Type de Message à tracer pour supervision ou analyse.
- Trace logs de prise en compte d’un Message d’un Composant Fournisseur
- Horodate de prise en charge du Message d’un Composant Fournisseur
- Référence de l’Instance du Message
- Référence de l’Instance du Composant Fournisseur du Message
- Référence du ou des Composants Consommateurs d’un Message Ciblé
- Trace logs d’émission d’un Message par un Composant Consommateur
- Horodate de prise en charge du Message d’un Composant Fournisseur
- Référence de l’Instance du Message
- Référence de l’Instance du Composant Fournisseur du Message
- Horodate de prise ne charge par un Composant Consommateur
- Référence de l’Instance du Message
- Référence de l’Instance du Composant Consommateur du Message
- Référence du ou des Composants Consommateurs d’un Message Ciblé
Nota :
Les Données de Référence contiennent les Informations suivantes :
- Le Type de composante (Version Type)
- L’Identifiant interne de la composante
- La Référence externe de la composante
La traçabilité est conditionnée par des Interrupteurs de traçabilité pour limiter les volumes engendrées par les Traces Logs (charges d’archivage et d’analyse).
Les Traces Logs sont très utiles tant en phase de Tests de développement, d’intégration que de supervision des activités en production.
En cas de dysfonctionnement (traitement en exception) d’un Composant ces mêmes Traces Logs sont émises automatiquement complétées par une Trace Log d’Erreur générique dans sa structure d’informations :
- Trace logs d’Erreur d’un Composant
- Horodate du dysfonctionnement du Composant
- Référence de la Fonction générique en dysfonctionnement (Code Erreur)
- Référence du Composant en dysfonctionnement
- Référence du Message pris en charge responsable du dysfonctionnement
- Référence du Processus en dysfonctionnement
QUID de la Durée de vie d’un Message dans un BUS à Messages ?
Dans le cas d’un Message ciblé lorsque l’ensemble des Composants Consommateurs ciblés ont consommé le Message sans dysfonctionnement (CR OK), le Message peut être archivé en Trace log.
Dans le cas d’un Message diffus le BUS à Messages ne peut préjuger quand l’ensemble des Composants Consommateurs auront consommé le Message sans dysfonctionnement (CR OK), le Message ne pourra être archivé en Trace log lorsque sa Durée de rétention sera dépassée.
QUID de l’archivage des Messages émis et réceptionnés par des Composants ?
Dans un Composant les Messages réceptionnés sont archivés en Trace Log dès lors qu’ils ont été consommés par un Processus sans dysfonctionnement (CR OK renvoyé au Composant Fournisseur instancieur du Message).
Dans un Composant les Messages ciblés émis sont archivés en Trace Log dés lors qu’ils ont été consommés par le ou les Processus du ou des Composants Consommateurs ciblés sans dysfonctionnement (CR OK).
Dans un Composant les Messages diffus émis sont archivés en Trace Log dès lors qu’ils ont été archivés dans le BUS à Messages d’émission. Ce qui correspond approximativement à quelques instants après leur Durée de rétention.
QUID de la Modularité des Composants (SSA : Sous-Système Applicatif) ?
Pour garantir la modularité du SI, chaque Composant encapsule 9 Fonctions génériques : Numérisation, Analogisation ; Transcription ; Identification ; Habilitation ; Affectation ; Transformation ; Indexation ; Mémorisation
Ces 9 Fonctions génériques garantissent les propriétés ACID (Atomicité, Cohérence, Isolation et Durabilité) des Composants. Les échanges entre les Composants se font au travers de Messages numériques accessibles via un BUS à Message (Réseau de communication numérique).
Rappel : Un Composant peut aussi présenter une Interface entrante analogique et/ou une Interface sortante analogique pour dialoguer avec le Monde réel (IHM Interface Homme Machine par exemple).
La Modularité la LOI2S facilite la substitution d’un Composant en minimisant les impacts sur les autres Composants de l’Architecture aux conditions de respecter les Interfaces entrantes numériques et les Interfaces sortantes numériques, c.à.d. le respect du formalisme de prise ne charge et d’émission des Messages du Composant substitué.
Cette conception Modulaire de l’Architecture en Composant sous forme de Container permet d’envisage de déporter certains Composants sur un plateforme de containérisation de Type « docker » par exemple ou de déporter des Composants sur des plateformes Cloud « Amazon Web Services », « Microsoft Azure », « Google Cloud Platform » pour exemple.
La modularité des Composants offre une plus grande flexibilité pour répondre aux fluctuations de charge. En effet, il est plus aisé de démultiplier les instances des Composants les plus sollicités en fonction de l’activité croissante ou saisonnière de tel ou tel Process métier.
La LOI2S permet un haut degré de portabilité et de flexibilité.
Nota : A la conception de l’Architecture, la granularité des Composants est un compromis qui cherche à démultiplier le nombre de Composants tout en minimisant le nombre de Messages inter Composants.
La démultiplication des Messages inter Composants déclenchent de multiples micro-Processus (Architecture micro-services massivement parallèle).
La démultiplication des Composants impose d’avoir une organisation, méthode et démarche rigoureuses des Versions de Composants facilité par la généricité des Objets de la LOI2S.
QUID de la Gestion des Versions ?
Au sein d’une Architecture LOI2S plusieurs Versions d’une même Type d’Objet peuvent être prises en charge simultanément, certains Composants pouvant traiter une seule, plusieurs Versions ou que certaines Versions d’un même Type d’Objet. En d’autres termes, un SI peut traiter en parallèle différentes Versions d’un même Type d’Objets (anciennes et nouvelles générations d’Objets métier ou Process, Processus).
Chaque Objet de la LOI2S dispose un Type qui le caractérise. Chaque Evolution d’un Type d’Objets est tracée par un Indice de Version à 3 degrés d’Evolution :
- Degré d’Evolution majeurimpose d’actualiser la liste des Versions Type d’Objets compatibles
- Degré d’Evolution ascendantenécessite le cas échéant de préciser la compatibilité avec certains Objets
- Degré d’Evolution corrective ne change pas la compatibilité des Objets entre eux
C’est donc le Type d’Objet qui est porteur de la Version.
Rappel : Un Type de Composant est habilité à traiter certains Types de Messages s’il dispose de Types de Processus capables de traiter ces Types de Messages.
Si le Type de Message est porteur d’un Indice de Version alors cette Version de Type de Message ne pourra être pris en charge que par une Version Type de Composant que s’il dispose d’une Version de Type de Processus apte à prendre en compte cette Version de Type de Message. Ce qui sous-entend que chaque Version Type de Processus est compatible avec une liste de Versions Type de Message.
Dans cette liste de Versions Type de Message d’une Version Type de Processus
- le Degré d’Evolution corrective n’est jamais vérifié,
- et si seul le Degré d’Evolution majeurest précisé pour un Type de Message alors seul ce degré devra être vérifié
- sinon si le Degré d’Evolution ascendante est précisé pour un Type de Message alors les Degrés d’Evolution majeur devront être semblables et le degré d’Evolution ascendante du Type de Message devra être antérieur.
Il appartient au Concepteur du SI de maintenir les listes de Versions de Type d’Objet compatible lors de toute Evolution majeur ou ascendante de Type d’Objet. Ces listes de Versions Type d’Objet sont référencées dans le MDM Master Data Mangement qui a en charge de s’assurer des comptabilités entre les différentes Versions Type d’Objet identifiées lors des Evolutions du SI.
(Vérifier s’il existe bien des Composants ayant des Processus aptes en prendre en compte certaines Versions Type de Message, Bus à Messages compatibles, Objets métiers, Données et Bases de Données compatibles par exemple.)
Nota : Ne pas faire d’amalgame entre la compatibilité des Versions entre Types d’Objet et l’habilitation d’un Profil de Compétence à exécuter un Processus à réception d’un Type de Messages émit par certains Composants. Dans ce dernier cas, ce sont les Profils de Compétences qui sont habilités et non pas le Type de Message.
QUID de la granularité des Composants (SSA : Sous-Système Applicatif) ?
S’il est possible de faire un Système d’Information avec un
seul Composant de la LOI2S, dès que le nombre de Processus devient
plus important, il est préférable de décomposer le SI en de multiples Composants
distribués et redondés pour garantir une disponibilité totale ou dégradée en
cas de défaillances localisées de l’infrastructure informatique.
Le principal critère de décomposition du SI va être le
couplage entre les Objets métier. Le plus courant est la décomposition
par Domaine fonctionnel qui, en générale, suit l’Organisation opérationnelle
de l’Entreprise décomposée par Profil de compétences. Cette approche
rejoint, la mise sur le marché des progiciels spécialisés autonomes par Domaines
fonctionnels tant métier (Prospection, Vente, Support après-vente, Logistique, Rétention,
Compta, Valorisation-Facturation, etc.) que technique informatique (Distribution
des Messages, Indexation des Données, Mémorisation des Données, Gestion des
Droits et des Profils de compétence, Dictionnaire, Annuaire et Catalogue, Interfaces
de Présentation ou de communication interentreprise, etc.).
La décomposition est aussi une aide à l’organisation distribuée
d’équipes spécialisées par Profils de Compétences métiers ou techniques pour la
spécification, conception et le développement du SI.
Nota : La décomposition du SI la plus fine serait d’avoir autant de Composants que de version Type d’Objet métier et de Fonctions génériques associées. Ce qui engendre une démultiplication des Messages inter Composants déclenchant de multiples Processus (Architecture micro-services massivement parallèle).
QUID de la Sémantique et des Concepts de la LOI2S ?
La LOI2S repose sur 11 Types d’Objet instanciables : Message ; BUS à Messages ; Catalogue ; Annuaire ; Profil de Compétence ; Objet métier ; Processus ; Donnée ; Base d’Index ; Base de Données ; Composant
Ces Types d’Objets garantissent la généricité du SI qui facilité ainsi sa lisibilité et cadre sa conception ou plus globalement l’Architecture du SI.
Chaque Composant du SI dispose de 9 Fonctions génériques : Numérisation, Analogisation ; Transcription ; Identification ; Habilitation ; Affectation ; Transformation ; Indexation ; Mémorisation
Ces 9 Fonctions génériques encapsulées dans chaque Composant garantissent la modularité du SI.
La conception du SI par la LOI2S en quelque mots
Les Composants communiquent entre eux via des Messages transportés par le BUS à Messages.
Les BUS à Messages, les Catalogues, les Annuaires, les Profils de Compétence, les Bases d’Index, les Bases de Données sont des Composants.
Les Données sont des modèles de structures organisées d’Informations typées et instanciées.
Chaque Processus est une Donnée qui se caractérise par un Type de langage de manipulation des Informations des Données d’Objet métier. Un Processus est déclenché par une Message habilité.
Un Objet métier est un modèle de structure organisée de Données : modèle de structure d’Informations statiques ou Processus de manipulation d’informations. Chaque Objet métier dispose de Processus qui garantissent l’intégrité des Informations encapsulées dans ses Données. En d’autres termes les Processus d’un Objet métier spécifient comment les Informations sont manipulables. Sachant que seuls les Processus encapsulés par l’Objet métier peuvent manipuler les Informations des Données de cet Objet métier. Chaque Processus peut instancier, altérer, indexer et mémoriser les Informations des Données encapsulés dans l’Objet métier.
L’ensemble de ces Objets instanciables et ces Fonctions génériques représentent l’infrastructure fonctionnelle de l’Architecture du SI par la LOI2S.
Nota : On retrouve ici, mais d’un point de vue fonctionnel métier, des notions basiques de la POO Programmation Orientée Objet et des infrastructures logicielles. Ces notions doivent être maîtrisées par les MOA Maitrises d’ouvrage et les MOE Maitrises d’œuvre qui participent aux spécifications, à la conception et aux développements du SI métier.
QUID des Catalogues et de la Codification des Informations ?
La codification des informations permet un couplage faible entre la modélisation du métier (Données, Messages, Objets métiers, Processus) et la sémantique du langage métier exprimée au niveau des Interfaces utilisateur (IHM : Interface Homme Machine).
L’historique et les origines de chaque organisation, chaque entreprise, même exerçant un métier similaire, engendrent des variations de langage même si dans la réalité il s’agit des mêmes entités qui répondent aux mêmes impératifs d’un même métier.
Plus facile à comprendre, la langue écrite et parlée diffère en fonction de l’origine ou de l’implantation des utilisateurs qui interagissent avec le Système d’information.
De plus en fonction – des spécifieurs, des concepteurs, des développeurs, etc. du SI (MOA : Maitrise d’Ouvrage et MOE : Maitrise d’œuvre) – de la culture local qui peut elle aussi évoluer dans le temps, – de la cible clientèle ou partenaire des usagers du SI, les expressions peuvent évoluer sans pour autant changer la nature même des Informations et de leurs traitements.
Une même information peut donc avoir plusieurs expressions sémantiques : Dénomination, Abréviation, Description, langage graphique ou iconique et ceux dans plusieurs langues.
Il est impératif de disposer un Dictionnaire métier leur de la conception et la maintenance du SI pour garantir la signification de chaque information et l’unicité de sa codification et de ses modes d’expression.
Les informations sont donc codifiées, de manière à les rendre plus stables voir invariantes au niveau des modèles et des règles de gestion du métier, d’où l’étape de transcription ou transcodification associé à la présence du Catalogue dans chaque Composant de la LO2S.
QUID des Identifiants internes et des Références externes ?
Dans la LOI2S on distingue les 2 notions suivantes :
- Les Identifiants internes à un Composant
- Les Références externes partagées entre plusieurs Composants voir plusieurs SI
Chaque Composant du SI peut avoir ses propres caractéristiques physiques, techniques, système, logiciels ou progiciels informatiques. Seules ses Interfaces entrantes et Interfaces sortantes numériques doivent respecter un protocole unifiée fonctionnel de communication pour permettre les interactions entre les différents Composants du SI.
Les systèmes de mémorisation des Données et d’indexation MPD : Modèle Physique de Données ont leur propre spécification d’identification des Données pour optimiser leur fonctionnement. Les Données ont une organisation, des typages et des identifications propres aux SGBD : Systèmes de Gestion de Base de Données. On utilise alors la notion d’Identifiant interne. Ces Identifiants ne sont connus et manipulés qu’en interne à chaque Composant. Ces Identifiants internes sont sous la responsabilité de chaque Composant pour garantir l’unicité, la cohérence et l’intégrité des informations interne du Composant.
Il en est d’ailleurs de même pour les typages des informations disponibles et spécifiques à chaque SGBD.
Par ailleurs, les instances de Données, d’Objets métier, de Messages, de Processus peuvent être distribuées dans différents Composants du SI voir externalisées vers d’autres SI interentreprises. Pour les identifier d’un point de vue fonctionnel et métier on utilise la notion de Référence.
Cette Référence garantit l’unicité des instances inter Composants et interentreprises.
Une même Instance peut avoir plusieurs Références et chaque Référence peut être constituée de plusieurs Informations. Une Référence se veut invariable pour une instance donnée durant tout son Cycle de vie. Si pour une raison nécessaire cette Référence d’instance serait amenée à changer, il faut s’assurer de l’unicité et de l’actualisation, la resynchronisation de toutes les instances dans tous les Composants susceptibles de la mémoriser. Une méthode suggérée consiste à garder sur l’instance l’historique de ses Références associées à une Date ou une Période de validité. Il est ainsi possible de référencer et identifier une instance avec une Référence ancienne, voir une Référence temporaire.
Nota : Si les Types des informations sont propres à chaque SGBD, les Types des Informations des instances inter Composants doivent respecter un format unifié pour l’ensemble des Composants du SI. Ces Types ou format d’Informations au même titre que les structures des Données, des Objets métier, des Messages, de Processus, sont spécifiés dans le MDM : Master Data Mangement.
QUID de la granularité des informations : les Objets métier ?
La LOI2S distingue différentes notions porteuses d’informations :
- Information
- Donnée
- Objet métier
- Processus
- Message
Une Information est la granularité la plus fine. Elle est insécable et elle dispose d’un Type élémentaire : Texte, Numérique entier, Numérique à virgule flottante, Montant, Identifiant, Référence, Abréviation, Code, Description, Commentaire, Liste de Valeurs, Média Image, Média Vidéo, etc…
Chaque Type élémentaire d’Information est défini et référencé au niveau du MDM : Master Data Management qui le caractérise : Nombre de caractères, Nombre de chiffres, Représentation, Valeur minimum, Valeur Maximum, Longueur, Valeur acceptable, Type binaire ou Codec, etc.
Les Types disponibles sont propres à chaque Système d’Information.
Une Donnée est une structure d’Informations. Cette structure est établie au niveau du MDM : Ordonnancement et organisation hiérarchique des Informations, Information obligatoire ou facultative, Nombre d’occurrence minimum et maximum, etc.
Le plus important pour définir cette granularité est l’unicité Cycle de vie des Informations liées dans une Donnée instanciée qui doit disposer obligatoirement, – d’une ou plusieurs Informations de Référence qui l’identifie de manière unique dans le Système d’Information, – d’un Identifiant unique attribué par Composant qui la traite et/ou la mémorise.
Une Donnée peut référencer une ou plusieurs autres Données.
Un Objet métier est une structure de Données, identifiable et manipulé par les opérationnels du Métier ou MOA : Maîtrise d’Ouvrage. Il représente la granularité des Spéciations fonctionnelles du Métier :
[Objet métier] Processus [Données en paramètre] => [Objet(s) métier résultant(s)]
Sujet verbe complément(s) => produit(s)
Chaque Objet métier à une dénomination unique au niveau du MDM qui le Type au sein du Système d’Information.
Chaque instance d’Objet métier est caractérise par – une Référence métier, – un Cycle de Vie ou Diagramme d’Etats spécifié et piloter dans un BPM : Business Process Manager.
Un Processus est une Donnée qui est caractérisée par un langage de programmation qui impose une certaine syntaxe ou champ lexical. Cette Donnée représente – soit du Code binaire compilé exécutable pour une Système d’exploitation donné, – soit du Code textuel interprétable par une Machine virtuelle donnée qui est capable de l’exécuter. Le Processus ou Tâche métier est la plus petite unité de traitement de Données spécifiée par la MOA. L’ordonnancement des Processus spécifie les Process métier décrit dans le BPM par la MOA.
Un Message est un Objet Métier évènementiel qui dispose – d’une Donnée entête générique qui généralise la gestion des Messages au sein du Système d’information et une ou plusieurs Données transportées, un ou plusieurs Objets métier transportées.
La granularité des Informations qui transitent via le BUS à Message et qui sont mémorisées dans chaque Composants du Système d’Information LOI2S est la Donnée référencée regroupant de multiples informations intimement liées (ayant un Cycle de vie identique).
QUID de la redondance des informations ?
Mise à part un système monolithique qui ne comporterait qu’un seul Serveur de Base de Données, tout Système d’Information redonde des informations dans ses Composants et ses Messages multiples. Et quand bien même, un seul Serveur de Base de Données, pour optimiser la sélection des informations clés, réplique les informations pour les organiser et les ordonner dans des structures d’Index. Ce Serveur dispose de mécanismes transactionnels qui garantissent la synchronisation de ses informations redondées.
Dans la LOI2S les Données (Structures d’informations regroupées sous un Identifiant) se retrouvent persistantes dans différents Composants et transitent portées par différents Messages. Il est donc important d’identifier le Composant référent de telle ou telle Donnée dans tel ou tel Etat à un instant donné.
A noter, que certains Composants peuvent faire persister une même Donnée dans des Etats différents et il peut être nécessaire d’archiver l’Etat d’une Donnée telle qu’elle était à un moment donné (Historisation d’un Diagramme d’Etat).
Un Processus qui nécessite d’avoir des Données à jours doit lancer un Message de récupération de la Donnée (de ses informations) au Composant référent. La généricité de ce Type de Message permet demander une ou plusieurs Données identifiés simultanément si le Composant Fournisseur référent est identique pour chacune des Données.
Dans les architectures actuelles distribuées et hétérogènes les données proviennent de sources de plus en plus nombreuses et cela impose lors de conception du Système d’Information la mise en place d’un MDM : Master Data Management pour garantir la cohérence synchrone de plusieurs Données traitées et analysées à une date donnée.
Mode pro-actif (PUSH)
Le Composant référent Fournisseur de Données envoie via le BUS à Message à chaque actualisation de Données un Message diffus ou un Message ciblé à l’ensemble des Composants Consommateurs des Données redondées.
Le Message poussé via le BUS à Message est porteur de la Référence de l’instance de la Donnée actualisée.
Mode passif (PULL)
Le Composant Consommateur de Données redondées envoie via le BUS à Message au Composant référent Fournisseur un Message ciblé pour obtenir les Données actualisées. Si le Message précise la Version Type de chaque Donnée et leur Date de dernière actualisation connues, le Composant référent Fournisseur ne renvoie les Informations de la Donnée que si la Date d’actualisation est plus récente afin d’optimiser le transport d’informations sur le Réseau et dans le Bus à Message.
Le Message demandeur de Données redondées précise – soit la Référence de l’instance de la Donnée à actualiser, – soit un minimum d’informations nécessaire à l’identification de cette instance de Donnée. Le Composant référent Fournisseur détient la ou les Références de cette instance de Donnée.
Nota : La granularité des Informations qui transitent via le BUS à Message et qui sont mémorisées dans chaque Composants du Système d’Information LOI2S est la Donnée référencée regroupant de multiples informations intimement liées (ayant un Cycle de vie identique).