Processus d'architecture

Un processus ou une méthode d'architecture est nécessaire pour prescrire la manière dont les architectures doivent être développées. Tous les frameworks ne fournissent pas un processus défini, laissant à une organisation le soin de créer et de configurer son propre processus. Enterprise Architect peut être utilisé pour définir un processus à n'importe quel niveau de détail et, à l'aide de la fonctionnalité de diagramme enfant, des aspects plus granulaires du processus peuvent être élaborés. Les diagrammes d'activité UML peuvent être utilisés pour créer une suite de diagrammes qui expriment le processus de création d'architecture, y compris les processus, les tâches, les entrées et les sorties, et les personnes qui exécutent les différentes étapes du processus. Enterprise Architect possède également une extension appelée Software Process Engineering Metamodel (SPEM) qui peut être utilisée pour définir le processus avec une grande rigueur si nécessaire. Dans la plupart des cas, le diagramme d'activité UML sera suffisant pour créer un processus détaillé.

En savoir plus : Activity Diagram

Les architectures de base sont souvent difficiles à justifier auprès des parties prenantes au niveau de la direction et de la direction qui ont un plus grand appétit pour l'architecture cible et les feuilles de route. L'importance des architectures de référence est d'établir le point de départ qui permettra de définir les transitions vers les architectures cibles. Il arrive souvent qu'il existe une documentation et des modèles qui peuvent être exploités pour collecter du matériel afin de remplir le référentiel de référence. Par exemple, la plupart des organisations ont eu au moins quelques tentatives de modélisation des processus existants, peut-être dans le cadre d'un effort de réingénierie commerciale et un ou plusieurs modèles d'information et diagrammes matériels existeront souvent.

Enterprise Architect peut être utilisé pour importer du contenu ou des modèles existants à partir d'autres référentiels et pour désosser les modèles de données qui peuvent constituer la base des descriptions de l'architecture de l'information.

Les architectures cibles sont vitales pour les cadres et les responsables hiérarchiques car elles définissent les architectures qui concrétiseront les stratégies commerciales et apporteront de la valeur à l'entreprise. Une fois que celles-ci sont connues et que les architectures de base sont suffisamment élaborées, l'équipe d'architecture peut se lancer dans la tâche plus difficile de définir les architectures de transition et de créer les feuilles de route qui prescriront comment l'architecture cible peut être atteinte dans la pratique en utilisant des étapes de transition.

Enterprise Architect dispose d'une large gamme d'outils qui permettent de définir les architectures cibles pour tous les domaines de l'architecture, y compris les architectures Métier , Information, Application, Technologie, Sécurité, Géospatiale et Sociale. Diagrammes peuvent être créés et présentés dans un large éventail de visualisations et de styles, pour être pertinents à la fois pour l'exécutif et les parties prenantes de la mise en œuvre. Des outils tels que le Gestionnaire de Spécification et le List Vue vous permettent de travailler avec des catalogues dans une vue attrayante de traitement de texte ou de feuille de calcul. L'impact et les relations peuvent être analysés à l'aide des matrices d'analyse des relations et des lacunes et de la fenêtre de traçabilité.

Les architectures de transition sont les étapes d'une architecture de base à une architecture cible finale, et sont théoriquement des architectures cibles elles-mêmes. Ils représentent les étapes pratiques pour passer d'un état actuel à un état futur auquel on aspire et seront souvent représentés comme des projets ou des phases d'un projet au niveau de la mise en œuvre.

Enterprise Architect permet de définir et de relier les architectures de transition dans une séquence de Feuilles de Route à créer afin que les transitions d'un état à l'autre puissent être visualisées et planifiées. N'importe quel nombre de Feuilles de Route peut être défini, et elles peuvent être utilisées pour tous les domaines de l'architecture, de sorte qu'il peut y avoir, par exemple, des Feuilles de Route capacité, d'application et de technologie.

En savoir plus : Roadmap Diagram