L’état des lieux

On parle beaucoup d’architecture. Quels bénéfices UML apporte à l’architecture ? Et pourquoi se préoccuper d’architecture ? Ce chapitre propose de répondre à la question « pourquoi l’architecture ? », examine rapidement deux outils d’architecture, et décrit les apports d’UML à cette discipline.

Les questions existentielles du système

Bien que les 14 diagrammes UML n’aient pas encore été tous examinés, les services rendus par UML ont été étudiés : ont été décrits les outils mis à disposition des analystes du métier pour développer les quatre visions dynamique, structurale, fonctionnelle et collaborative du métier.

Ces quatre visions doivent fournir un ensemble de réponses cohérentes aux trois questions fondamentales rappelées ci-après. L’ordre de prise en compte de ces descriptions n’a pas d’importance et la démarche peut parfaitement être incrémentale et/ou itérative.

	Que répondre ?	Comment répondre ?
Comment ça marche ?	Descriptions dynamique, collaborative	Diagrammes d’activité, états-transitions, de séquences, de communication, de temps
Comment c’est fait ?	Description structurale	Diagramme de classes, de composants, d’objets, des paquetages, de déploiement, de structure composite, des profils
À quoi ça sert ?	Description fonctionnelle	Diagramme des cas d’utilisation

Tableau 1 : Les trois questions minimales de l’analyse d’un système

Rappel : en apparence, cet ouvrage se différencie d’UML qui ne reconnaît que deux descriptions, donc regroupe ses diagrammes en deux familles : les diagrammes structuraux, les diagrammes comportementaux. En fait, selon la vision UML, les diagrammes comportementaux répondent aux deux questions : comment ça marche ? À quoi ça sert ?

En toute rigueur, le travail de l’analyste du métier pourrait s’arrêter là. Le concepteur pourrait prendre la suite :...

L’architecture en entreprise

Deux exemples d’outillage en architecture seront examinés : TOGAF et Praxeme. Auparavant sont passées en revue les missions que l’architecture se donne.

1. Répondre à deux besoins : généricité et cohérence interne

L’architecture a été identifiée comme une solution possible à l’impératif de généricité. Mais pourquoi beaucoup de systèmes d’information en l’état actuel ne sont-ils pas complètement aptes à satisfaire ce besoin ?

Le problème crucial rencontré actuellement par les entreprises a été très synthétiquement exposé par le CEISAR (Center of Excellence in Enterprise Architecture, un centre d’expertise en architecture fondé en 2009 à l’École centrale de Paris) : « Les technologies et les systèmes d’information ont un rôle à jouer dans le développement de la flexibilité des entreprises. Les solutions informatiques ont généralement été construites par générations successives. La cohérence d’ensemble a rarement été une priorité. »

Autrement dit, l’accroissement s’est fait en mettant bout à bout des outils partiels, sans souci patrimonial global. C’est un des soucis des entreprises actuellement : ce manque de cohérence dans le système d’information rend les évolutions difficiles, lentes, chères.

Cette cohérence concerne à la fois l’information (les concepts du métier, leurs attributs, leur cycle de vie) et les processus (qui orchestrent les fonctionnalités, décrites comme des cas d’utilisation). En quoi le Business Analyst est-il concerné ?

Deux cas de figure se présentent :

La cohérence est recherchée métier par métier, sans préoccupation d’une vision d’ensemble qui pourrait être partagée par tous les acteurs de l’entreprise. L’information et les services sont définis verticalement, silo par silo : comptabilité, finance, commercial, production, etc.
La cohérence est recherchée...

L’architecture en entreprise selon TOGAF et Praxeme

Il ne s’agit pas d’établir une comparaison entre ces pratiques, mais de préparer les points d’entrée d’UML dans ces deux méthodes. Les apports d’UML à l’architecture seront vus à la section Les apports d’UML à l’architecture.

1. Le framework TOGAF version 9.1

a. La mise en œuvre de TOGAF

L’idéal selon TOGAF est d’atteindre the boundaryless information flow™ : l’information doit pouvoir circuler à la fois au sein de l’entreprise et entre les entreprises partenaires membres du même écosystème, sans être entravée par une quelconque frontière (ce qui n’exclut pas les interfaces de contrôle).

Standard de fait de l’architecture, TOGAF vise à fournir des méthodes, des outils, des guides et des bonnes pratiques dont la mise en œuvre permettra d’organiser l’informatique matérielle et logicielle en fonction du métier de l’entreprise, de son évolution, des buts et raisons d’être de celle-ci.

Cette mise en œuvre n’est pas linéaire : elle est à la fois incrémentale et itérative, ce qui se traduit par le parcours de plusieurs cycles d’amélioration continue.

Au cours d’un des cycles, le praticien TOGAF décrit le métier et organise l’information et les processus autour d’un ensemble de composants (les ABB ou Architecture Building Block), puis il identifie les composants solutions (les SBB ou Solution Building Block) qui répondent aux besoins en implémentant les spécifications des ABB. Il pilotera soit la création de SBB nouveaux, soit l’adaptation de SBB existants.

Un processus TOGAF doit se soumettre aux principes de gouvernance de l’entreprise : il s’agit, dans une phase préliminaire, de les mettre en lumière et de les inscrire comme principes d’architecture.

Figure 3 : Une itération TOGAF (vision synthétique du processus de production d’architectures)

Mettre en œuvre TOGAF, c’est suivre un cheminement relativement bien balisé (mais faiblement contraignant) en déployant des outils d’analyse et de modélisation...

Les apports d’UML à l’architecture

UML a-t-il sa place parmi les outils utilisés par une équipe d’architectes ? Des outils dédiés existent, fournis par des éditeurs, qui le plus souvent sont descendants d’outils BPMN (Business Process Management Notation). Ces outils sont excellents, ils couvrent bien la mission de l’architecte, alors pourquoi utiliser un outil UML ?

Les raisons invoquées pour choisir ou refuser UML sont parfois accessoires : le faible attrait pour la modélisation, pour la conceptualisation fait adopter des outils qui semblent bien ancrés dans le concret de l’opérationnel métier et qui présentent un réel fini graphique, esthétique, donc plaisant aux acteurs de l’entreprise non techniciens. Les outils UML, issus plutôt d’un monde technique, n’ont pas encore intégré cette nécessité.

Mais il faut évoquer un autre aspect : la continuité indispensable entre les analyses du métier amont et les travaux de conception et de réalisation. UML a de sérieux atouts car il couvre toutes les étapes de l’ingénierie logicielle et est équipé pour assurer cette traçabilité si bénéfique à la cohérence globale du SI. Certes, les outils BPMN embarquent des outils d’adaptation ou de construction de solutions. Ils savent simuler, implémenter, piloter des processus, via le BPEL (Business Process Execution Language).

Le BPEL est un langage dérivé du XML ; il définit la logique d’enchaînement des actions qui vont constituer le processus. Un moteur d’orchestration interprète ce langage et permet les interconnexions, de même que le partage de l’information et la gestion des événements.

1. Les diagrammes UML natifs au service de l’architecture

Cette section prend en compte les préoccupations métier de l’architecte, qui sont celles de l’analyste du métier. Il s’agit de voir de quels outils UML va pouvoir bénéficier l’analyste du métier dans le cadre d’une architecture d’entreprise. De ce fait, seules les phases amont sont ici prises en considération.

a. TOGAF et UML

Les phases...

Pour aller plus loin

Le sujet de l’architecture en entreprise est très vaste, passionnant, massivement exploré et débattu sur des blogs et forums de toutes sortes.

Des clubs et associations existent : ils sont faciles à dénicher sur Internet. Attention : l’adhésion à certains d’entre eux est réservée aux entreprises.

La documentation TOGAF, celle de Praxeme sont disponibles en téléchargement, moyennant quelques restrictions, guère contraignantes. Leur lecture est très instructive. On conseillera de débuter par le Guide général de Praxeme, qui offre un panorama clair, concis de la méthode, mais aussi de ses enjeux. Il donne une réponse aux « pourquoi l’architecture ? », « pourquoi la transformation de l’entreprise ? », « pourquoi ce besoin de généricité et de cohérence ? ». On pourra poursuivre avec les guides des différents aspects et les fiches de procédés, qui commencent à être nombreuses.

TOGAF et ses concepts clés sont relativement accessibles ; le reste de la documentation est touffu, se veut exhaustif, si bien qu’on peut franchement se demander s’il est bien nécessaire de consacrer plus de 700 pages à un framework qui se veut consensuel.

Enfin...

Conclusion

UML ou BPMN ? UML natif ou UML doté de profils ?

L’intérêt des outils BPMN réside dans la possibilité de tester les processus reconfigurés grâce au langage d’exécution BPEL.

À l’heure actuelle, ces solutions BPEL sont puissantes, assez peu répandues, nécessitent l’implémentation de services web. Mais surtout, elles manquent de capacité à la généricité.

Dans les entreprises ayant adopté ces solutions, l’architecture peut mettre en place des innovations métier en reconfigurant les processus, et très secondairement, les données (via les adaptations des services web). Ce qui signifie que la dynamique est totalement externe aux concepts du métier. Or l’orienté objet a permis une avancée majeure : via les cycles de vie, on affecte la plus grande partie de la dynamique aux concepts du métier.

La question fondamentale est : l’innovation est-elle du ressort des pilotes des processus ou de l’entreprise ? Changer le style du management est-il du ressort des responsables des processus ? Adopter un management par les processus permet-il de libérer l’entreprise, de redonner confiance aux acteurs humains, de laisser sa place légitime à l’incertitude inhérente aux organisations humaines où...

UML au service de l'architecture