L'architecture métier est définie comme un ensemble d'éléments organisé, avec des relations claires entre ces éléments
qui, collectivement, forment un ensemble défini par sa fonctionnalité. Les éléments représentent la structure
organisationnelle et comportementale d'une entreprise et présentent des abstractions de ses processus et structures
clés [NDL97], [ERI00].
Chaque individu possède des expériences et des perspectives différentes. Lorsque nous souhaitons faire en sorte qu'un
ensemble aussi complexe que l'organisation (notamment ses processus, sa structure et sa stratégie) soit compris par
tous, nous devons trouver un moyen de décrire l'architecture et les problèmes importants pour l'architecture de façon à
ce que chaque groupe concerné puisse les comprendre. Pour y parvenir, il est nécessaire de décrire trois architectures
différentes bien qu'associées, détaillées plus loin.
L'architecture métier est une description des aspects importants de l'organisation. L'architecture
d'application décrit les applications logicielles qui soutiennent le métier, notamment leur utilisation et leurs
interactions. Enfin, l'architecture technique est une description de l'infrastructure matérielle qui soutient
les applications logicielles.
L'architecture métier doit gouverner l'architecture d'application, qui doit gouverner à son tour l'architecture
technique. Cette situation n'implique pas une relation hiérarchique, dans laquelle l'architecture technique est dictée
par l'architecture d'application, elle-même dictée par l'architecture métier. Elle signifie plutôt que les objectifs et
contraintes (appelés moteurs) suivent une seule direction, et que toute décision architecturale (appelée compromis) qui
affecte l'architecture gouvernante doit être appliquée au niveau de cette architecture. Un objectif architectural
implique une condition souhaitée, tandis qu'une contrainte architecturale implique une conformité obligatoire.
Toutefois, même les contraintes peuvent être ignorées intentionnellement. Par exemple, une contrainte qui exige le
respect d'une certaine législation peut être ignorée lorsque les changements nécessaires à la mise en conformité
entraînent des coûts largement supérieurs aux amendes encourues en cas de non respect.
La réalisation de l'architecture consiste à trouver un équilibre entre les forces et à effectuer des compromis, de
manière à aboutir à une solution optimale répondant aux exigences conflictuelles. Par conséquent, l'architecture métier
définit des objectifs et des contraintes qui décrivent le support que l'architecture d'application doit lui offrir. Il
en va de même pour les architectures technique et d'application. En cas de conflit, comme il arrive toujours, il faut
trouver des solutions localisées sous-optimales afin d'offrir une solution générale optimale. Lorsque ces décisions ont
un impact important, elles sont désignées sous le terme de problèmes architecturaux et doivent être formellement
approuvées par les parties prenantes représentées par un conseil d'architecture.
Vous devez toujours tenir compte de ces différentes architectures lorsque vous communiquez avec les parties prenantes.
Si vous discutez de l'une d'entre elles avec une personne qui ne comprend pas sa forme, son application ou sa notation,
votre communication sera inefficace. De plus, il se peut que cette personne comprenne mal les conséquences de ses
décisions sur les autres architectures. Vous devez montrer les répercussions qu'entraînent des décisions concernant
l'une des architectures sur les autres. Ainsi, les parties prenantes comprendront mieux les avantages et les
inconvénients des compromis obtenus, ce qui conduira à une situation d'alignement architectural. L'alignement
architectural permet de comprendre les conséquences des décisions effectuées.
L'architecture métier désigne ce que nous utilisons pour communiquer avec les différentes parties prenantes sur le
métier, afin d'en garantir une compréhension commune et cohérente. Cette architecture peut être décrite comme
l'infrastructure préfabriquée dans laquelle sont reportés les changements effectués dans l'organisation, pour permettre
au métier de réaliser l'idée métier, comme le montre la figure.
L'architecture métier étant complexe et difficile à mesurer, nous la divisons en un certain nombre de vues différentes.
Tout comme l'architecture logicielle est définie dans le Concept :
Architecture logicielle, les vues d'architecture du métier seront définies dans ce document.
Chaque vue décrit un aspect de l'ensemble du métier. Chacune contient donc un sous-ensemble important pour
l'architecture de ce qu'en serait la définition complète. En d'autres termes, une vue d'architecture contient les 20%
de l'ensemble qui sont réellement importants pour cet aspect du métier [ROY98].
Les vues d'architecture sont utiles pour discuter de l'architecture métier avec les différentes parties prenantes.
Chaque partie prenante étant intéressée par une ou plusieurs vues, elle peut se concentrer sur les aspects de
l'organisation qui sont associés à ces vues sans avoir à comprendre les autres également.
Notez que toutes les vues ne s'appliquent pas à toutes les situations. Certaines vues peuvent être ignorées
lorsqu'elles n'ajoutent pas de valeur, et il peut parfois être nécessaire de définir de nouvelles vues. Nous vous
présentons ici quelques vues d'architecture métier courantes :
-
La Vue du marché décrit les marchés sur lesquels le métier opère, les profils et offres client, ou les
produits et services que le métier offre aux clients sur les marchés cible.
-
La Vue des processus métier décrit les objectifs importants du métier et ébauche les principaux cas
d'utilisation métier qui soutiennent ces objectifs. Lorsque les cas d'utilisation métier sont utilisés pour
documenter les processus métier, cette vue est appelée vue des cas d'utilisation métier.
-
La Vue de l'organisation décrit les groupes de rôles et responsabilités dans le métier et la réalisation des
cas métier.
-
La Vue des ressources humaines décrit les profils et les mécanismes incitatifs de rémunération, les
caractéristiques et mécanismes culturels clés, les profils de compétence, ainsi que les mécanismes d'apprentissage
et de formation.
-
La Vue du domaine décrit les principaux concepts métier et structures d'informations utilisés par le métier.
-
La Vue géographique décrit la distribution de la structure organisationnelle, de la fonction et des
ressources sur des sites physiques, tels que les villes et les pays.
-
La Vue de la communication décrit les chemins de communication au sein du métier.
Mappage des vues d'architecture métier aux points de vue RUP
Les points de vue RUP sont décrits dans le Concept :
Architecture système. Ces points de vue sont applicables au développement d'un système en général. Lorsque le
"système" considéré est un métier, les vues d'architecture métier constituent une spécialisation plus pertinente des
points de vue génériques. Le tableau suivant illustre les relations entre les deux. Notez que dans certains cas, selon
les définitions du Concept :
Architecture système, les vues d'architecture métier recouvrent plusieurs vues (lorsqu'une vue est à l'intersection
entre un point de vue et un niveau d'abstraction).
Vues d'architecture métier
|
Points de vue RUP
|
Vue du marché
|
La Vue du marché définit, au moins partiellement, le contexte du métier - elle est axée sur les
produits et services réels et potentiels offerts au consommateur sur les marchés choisis. Elle est
mappée à l'intersection entre le Point de vue logique et le Niveau du contexte. Pour
les besoins du Produit: Document d'architecture métier, la Vue du
marché est limitée aux facteurs qui ont une influence sur l'architecture, et aux domaines où les
changements apportés à l'architecture affecteraient les performances sur les marchés choisis.
Le Produit: Vision métier traite plus généralement des
marchés et des justifications des choix de stratégie métier.
La Vue du marché peut être utilisée pour établir de nouveaux Objectifs métier qui, à leur tour, peuvent
influencer l'architecture métier.
|
Vue des processus métier
|
Ce mappage est direct - à l'intersection entre le Point de vue des processus et le Niveau du
contexte.
|
Vue de l'organisation
|
La Vue de l'organisation concerne la manière dont le métier est structuré pour réaliser les cas
d'utilisation métier, et non les réseaux et hiérarchies du personnel et des postes. Par exemple, vous
pouvez vous attendre à voir les collaborations des Systèmes métier dans cette vue. Elle est donc mappée à
l'intersection entre le Point de vue logique et le Niveau de l'analyse.
|
Vue des ressources humaines
|
La Vue des ressources humaines étend le Point de vue des travailleurs, potentiellement à tous les
niveaux, de manière plus importante au Niveau du contexte où la règle est définie, mais également
aux Niveaux de l'analyse et de la conception, avec, par exemple, l'application des
profils de compétence.
|
Vue du domaine
|
Ce domaine est très bien mappé à l'intersection entre le Point de vue des informations et le
Niveau du contexte.
|
Vue géographique et Vue de la communication
|
Ces vues sont mappées ensemble à l'intersection entre le Point de vue de la distribution et le
Niveau du contexte (Vue des localités de l'entreprise), où les localités sont associées à
l'aspect géographique et les connecteurs à l'aspect communicatif.
|
|