Rendre votre entreprise innovante, avec des processus métiers plus agiles et augmenter sa capacité à évoluer, sont les principaux objectifs de l'urbanisation du SI.
L'urbanisation du SI est une méthode de la maîtrise de la complexité.
L'urbanisme cible la réappropriation du SI par la maîtrise d'ouvrage.
Pour y arriver, une compétence plus grande en matière de SI leur est nécessaire.
Une meilleure communication maîtrise d'ouvrage - maîtrise d'œuvre pourra s'instaurer.
Une organisation innovante et performante dépend de l'optimisation de son SI dont la complexité est sans cesse croissante.
Il faut maîtriser le SI pour pouvoir le moderniser et innover : le projet d'urbanisation du SI n'est pas un projet en plus !
C'est souvent celui qui permet de réussir tous les autres.
Voir les sous-catégories de la catégorie "Urbanisation SI" :
- Le processus d'urbanisation du Système d'Information
- L'urbanisme et la gouvernance du Système d'Information
- Les autres méthodes de gouvernance du SI
- Les recherches en urbanisation du SI
Comment mettre en œuvre le framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework) ?
TOGAF est une méthode générique comportant des solutions clés en main à la transformation de l’architecture d’entreprise.
Évidemment l’objectif suprême est la réalisation d’applications opérationnelles.
Pour se faire, il faut une vision globale couvrant les aspects stratégiques, métiers, organisationnels, s’assurer de l’alignement entre le métier et la technique, rechercher constamment l’évolutivité des SI et avoir une culture de l’innovation.
TOGAF intègre les stratégies, les exigences, les processus métiers, les applications, les infrastructures techniques et des associations efficientes entre ces différents aspects et va même jusqu'à la planification et la gestion du changement.
Voici un de nos plus fameux articles sur TOGAF : TOGAF pour les nuls.
Vous trouverez bien sur le reste de notre saga dans la catégorie TOGAF
Vous cherchez désespérément un formalisme pour vos processus métiers mettant en accord MOA et MOE, la solution miracle existe, elle s'appelle BPMN
BPMN est un langage plus concret que UML, spécialement conçu pour les experts métiers afin qu'ils puissent représenter leurs processus métiers avec la terminologie qu'ils connaissent
L'article suivant référence l'ensemble des sujets traités sur BPMN :
Le reste de notre saga dans la catégorie BPMN
SysML, c'est comme UML mais en mieux !
UML ne permet pas directement de modéliser les exigences et d'assurer la traçabilité vers leurs réalisations par les autres éléments de conception.
UML ne prévoit rien pour représenter des éléments non-logiciels, des équations mathématiques, des contraintes, des flux (énergie, fluide, ...), des allocations structurelles/comportementales, ...
Et enfin, UML utilise la terminologie orientée objet (classe, attribut, méthode, ...) qui si elle convient bien aux méthodes et langages de programmation objets, n'est pas celle adoptée par l'ingénierie système.
Mais n'oublions pas tout de même que UML est la base de SysML qui est un profil UML (package de stéréotypes, tags/values et contraintes OCL).
Voir les articles de la catégorie SysML de ce blog et notamment SysML pour les nuls : de la modélisation des exigences à la réalisation du système .
Derniers articles
Le diagramme de localisation des applications et des utilisateurs de la phase C Architecture des Systèmes d'Information de TOGAF - étape 27 de notre cas d’étude
Le diagramme de localisation des applications et des utilisateurs a pour objet de répondre aux questions “Où se trouvent les applications et par qui sont elles utilisées ? “.
Le diagramme est réalisé par les architectes applicatifs avec comme référents les architectes applicatifs et les experts métier et à destination des responsables métier, des architectes techniques et des responsables réseaux.
...
Le diagramme de migration applicative de la phase C Architecture des Systèmes d'Information de TOGAF - étape 26 du cas complet Modelio
Le diagramme de migration applicative a pour objet de représenter le plan de migration des applications depuis l’existant jusqu’à la cible suivant la trajectoire établie.
Le diagramme est réalisé par les architectes applicatifs avec comme référents les architectes applicatifs et les architectes techniques et à destination des analystes métier et des architectes techniques.
Pour plus de précisions sur les é...
Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel
Le diagramme de communication des applications a pour objet de montrer la relation entre les entités de données, les services métier et les composants applicatifs.
Le diagramme est réalisé par les architectes applicatifs avec comme référents les architectes applicatifs et les architectes techniques et à destination des analystes métier et des architectes techniques.
Pour plus de précisions sur les élé...
Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
La phase C doit mettre en place l’implémentation et l’exécution des constituants métier indépendamment de la phase D technique qui doit établir la correspondance physique et technologique avec les composants des phases précédentes.
Un synoptique a été abordé dans l’article :
Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la mé...
Diagramme de cycle de vie des entités métier en phase B architecture métier de TOGAF - étape 23 de l'étude de cas
Le diagramme de cycle de vie des entités métier a pour objectif de modéliser tous les états et leurs transitions c'est à dire les événements et les règles métier provoquant les changements d'état.
Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des responsables de domaines métier et processus métier.
...
Diagramme des entités métier en phase B architecture métier de TOGAF - étape 22 du didacticiel
Le diagramme des entités métier a pour objectif de modéliser les entités cœur de métier en faisant attention à rester au niveau macroscopique. Cela signifie de ne s'intéresser qu'aux concepts primaires en faisant abstraction de toutes considérations techniques. Plusieurs niveaux d’échelle pourront être réalisés : 1 - uniquement les entités/relations, 2 - ajout des propriétés et 3 - regroupement en domaines.
Le diagramme est ré...
Diagramme supervision métier en phase B architecture métier de TOGAF – étape 21 de l’exemple complet emprunté à Modelio
Le diagramme supervision métier a pour objectif de montrer à la direction générale la chaîne des constituants de l’architecture d’entreprise, en prenant comme point de départ les objectifs métier en passant par les fonctions métier, unités organisationnelles, processus métier, services métier pour finir aux composants techniques.
Le diagramme est réalisé par les analystes métier avec comme ré...
Diagramme information - service métier en phase B architecture métier de TOGAF - étape 20 de l’étude de cas Modelio
Le diagramme information - service métier a pour objectif de modéliser les entités métier utilisées en entrée et produites en sortie par les services métier. Ces modèles constitueront une aide précieuse pour représenter l’architecture des données en phase C architecture des systèmes d’information.
Le diagramme est réalisé par les analystes métier avec comme référents les experts mé...
Diagramme de cas d’utilisation métier en phase B architecture métier de TOGAF – étape 19 de l’étude de cas Modelio
Le diagramme de cas d’utilisation métier a pour objectif de modéliser les communications entre les acteurs (consommateurs) externes ou internes et les services métier.
Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des analystes métier, responsables métier et architectes applicatifs.
TOGAF distingue les cas d’utilisation mé...
Les règles métier en phase B architecture métier de TOGAF – étape 18 avec l’outil Enterprise Architect de Sparx Systems
Le diagramme de règles métier a pour objectif de modéliser les exigences de prise de décisions (par ex. les tables et arbres de décisions) et leurs logiques (par ex. formules de calculs) qui constituent le cœur de métier d’une entreprise et qui doivent obligatoirement être modélisées avec la norme OMG (Object Management Group), DMN (Decision Model and Notation). Cette norme a été conçue pour être utilisable avec la norme de modé...