Archives des Processus - LOI2S

Quid de la traçabilité du système ?

PALUCK — Mon, 06 Feb 2023 13:49:33 +0000

Object Information Service System

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.

Voir aussi QUID de la Supervision applicative : Traces logs ? – LOI2S (loi2s-sasu.fr)

L’article Quid de la traçabilité du système ? est apparu en premier sur LOI2S.

QUID de l’Architectures fractale LOI2S ?

PALUCK — Fri, 28 Oct 2022 09:38:30 +0000

Object Information Service System

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é.

Maîtriser le cycle de vie des Composants numériques

La norme Open Group IT4IT Reference 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.
→

Concevoir une entreprise capable de s’adapter au changement

MEGA HOPEX 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.
→

Un flux d'information sécurisée sans frontière

Le langage de modélisation ArchiMate® 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.
→

Garantir des normes, des méthodes et une communication cohérentes

La norme TOGAF® The Open Group Architecture Framework montre où trouver des concepts durables et universels et des meilleures pratiques éprouvées d'architecture d'entreprise.
→

Gagner en agilité, en réactivité et en performance

La notation du BPM apporte une dimension stratégique pour optimiser la performance opérationnelle tout en mettant son système d’information au service de la vision stratégique de l’entreprise.
→

Unifier le language et le formalisme

L'objectif de l'UML est de fournir aux architectes système, ingénieurs logiciels et développeurs de logiciels un formaliste unifié de conception et documentation du SI.
→

Economiser du temps et de l'argent avec l'orienté objet

L'OMG génére des normes technologiques robustes, transparentes et bien documentées, qui fournissent une valeur réelle quantifiable à toutes les industries.
→

Garantir des normes, des méthodes et une communication cohérentes

La norme TOGAF® The Open Group Architecture Framework montre où trouver des concepts durables et universels et des meilleures pratiques éprouvées d'architecture d'entreprise.
→

L’article QUID de l’Architectures fractale LOI2S ? est apparu en premier sur LOI2S.

QUID de la persistance et de l’accès aux informations ?

PALUCK — Tue, 20 Sep 2022 11:50:46 +0000

Object Information Service System

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.

L’article QUID de la persistance et de l’accès aux informations ? est apparu en premier sur LOI2S.

QUID des notions de Front-Office, Middle-Office et Back-Office ?

PALUCK — Mon, 22 Aug 2022 12:07:54 +0000

Object Information Service System

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.

L’article QUID des notions de Front-Office, Middle-Office et Back-Office ? est apparu en premier sur LOI2S.

QUID des notions de Front-end, Middleware et Back-end ?

PALUCK — Mon, 22 Aug 2022 12:02:23 +0000

Object Information Service System

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.

L’article QUID des notions de Front-end, Middleware et Back-end ? est apparu en premier sur LOI2S.

QUID des Messages synchrones et asynchrones ?

PALUCK — Mon, 22 Aug 2022 10:24:35 +0000

Object Information Service System

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.

L’article QUID des Messages synchrones et asynchrones ? est apparu en premier sur LOI2S.

QUID de la Modélisation des Objets métier ?

PALUCK — Fri, 19 Aug 2022 08:24:58 +0000

Object Information Service System

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

Gagner en agilité, en réactivité et en performance

Unifier le language et le formalisme

L'objectif de l'UML est de fournir aux architectes système, ingénieurs logiciels et développeurs de logiciels un formaliste unifié de conception et documentation du SI.
→

Concevoir une entreprise capable de s’adapter au changement

MEGA HOPEX 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.
→

Economiser du temps et de l'argent avec l'orienté objet

L'OMG génére des normes technologiques robustes, transparentes et bien documentées, qui fournissent une valeur réelle quantifiable à toutes les industries.
→

L’article QUID de la Modélisation des Objets métier ? est apparu en premier sur LOI2S.

QUID de la Supervision applicative : Traces logs ?

PALUCK — Thu, 18 Aug 2022 09:08:00 +0000

Object Information Service System

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.

L’article QUID de la Supervision applicative : Traces logs ? est apparu en premier sur LOI2S.

QUID de la Gestion des Versions ?

PALUCK — Wed, 17 Aug 2022 09:16:26 +0000

Object Information Service System

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.

L’article QUID de la Gestion des Versions ? est apparu en premier sur LOI2S.

QUID de la granularité des Composants (SSA : Sous-Système Applicatif) ?

PALUCK — Tue, 16 Aug 2022 12:55:30 +0000

Object Information Service System

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).

L’article QUID de la granularité des Composants (SSA : Sous-Système Applicatif) ? est apparu en premier sur LOI2S.