AILES : AM, Architecture Métier, principes généraux

La sphère Métier
    Les activités et les centres d'intérêts associés à cette sphère sont, et c'est un euphémisme, en amont de tout gros projet. Tellement en amont que, le plus souvent, cette sphère passe à la trappe. En effet, il est rare de voir mettre en oeuvre une architecture métier autour d'un simple projet, qui ne concernerait qu'un seul SI (Système d'Information) ou toute application de plus petite taille.
    L'architecture métier trouve souvent son origine dans le développement d'un programme (et je ne parle pas d'une simple collection de routines informatiques), à savoir un ensemble de projets qui peuvent englober un ou plusieurs SI. Dans ce type de situation, la question de savoir « qui fait quoi ? », donc celle du "métier", se pose avec acuité. Et la réponse est trop souvent « on sait pas, de toutes façons, ce magma de systèmes informatiques est devenu un b..., heu fouillis ingérable! ». Or, comme cela a été souligné dans l'article sur la définition, l'origine et l'enjeux de l'Architecture, c'est souvent quand la situation devient trop complexe que le besoin d'une activité structurante (telle que l'Architecture) se fait sentir.
    Comme l'illustre le schéma suivant (issu, en partie de [Longepe] et [Serclac]), 2 sous-activités sont présentes dans cette sphère architecturale.

Cartographie
    La première est représentée tout autours du carré 'Business Architecture' : il s'agit de structurer et classer l'existant, donc de réaliser une cartographie en terme de :
- services (quels sont les services qui existent déjà, lesquels doivent évoluer ?)
- Applications et Legacy (qui remplit ses services ? Quels sont les problèmes de duplication de services, ou de goulot d'étranglement ?)
- "referentials" (les base de données référentielles, avec là encore y un problème potentiel de duplication de donnée et d'incohérence) a vocation a initier et fournir une base à un projet (et peut se retrouver très souvent en activité transverse, afin de vérifier que chaque projet respecte les activités métier de base).
- liaison entre la partie business et la partie 'consumers' (les clients), qui peuvent aussi bien faire partie de la boite elle-même(!) que de l'extérieur (grand public dans un cadre B2C, Business 2 Client, ou autres entreprises dans un cadre B2B, Business 2 Business), et ce avec des moyens de liaisons en mode connecté ou distant. Évidemment, à ce niveau on ne détaille pas la technologie sous-jacente à ces liaisons, on précises simplement les besoins de liaisons qui permettent de supporter le métier.

Métier
    La deuxième, au sein du carré 'Business Architecture', vise à bien re-préciser le métier. En effet, comme nous le rappelle ce consultant de 30 ans, la technique vise à soutenir un métier. Donc mieux vaut savoir précisément la nature de son métier.
    Pour cela, 3 pré requis sont abordés [Longepe]:
    - la mission: la raison d'être de l'entreprise ou de l'organisme;
    - la vision: l'ensemble des objectifs de haut niveau de l'entreprise;
    - la stratégie: moyen de réaliser la vision au travers d'un ensemble d'objectifs et sous-ojectifs stratégiques;
    Ces objectifs sont à la base des processus métiers ('business Process'). Chaque objectif doit être couvert par un processus, chaque processus par par un ensemble d'activité et chaque activité par un 'bloc fonctionnel' mettant en oeuvre les 'procédures logiques' qui transforme le contenu ou l'état de données. Cette dernière phrase représente une bonne partie de l'activité d'urbanisation qui devient de plus en plus nécessaire, au vu de la complexité des SI actuels.
Toutefois, l'urbanisation ne se limite pas à la seule architecture métier, mais est transversale et va jusqu'à l'Architecture Applicative (elle concerne moins l'Architecture Technique). On verra ainsi dans l'Architecture Fonctionnelle que le bloc fonctionnel se représentera par un 'composant métier' et que les procédures logiques se décriront par des cas d'utilisation.
    Revenons à l'entité de base manipulé par le métier, à savoir les objectifs. Ces derniers peuvent s'illustrer de différentes façons, dont deux sont représentées sur le schéma ci-dessus:
- le diagramme d'Ishikawa, qui visualise les causes et les effets, chaque effet étant un objectif en soi;
- le diagramme d'entreprise, qui fait apparaître les différentes entités fonctionnelles qui composent l'organisation, et qui détaille les activités et flux d'information échangés entre ces entités, mais également entre la société et:
    * les clients;
    * les fournisseurs;
    * les partenaires.

Pourquoi ?
    Quoiqu'on puisse penser de ce qui précède (du style "tout ces histoires de 'stratégie', ça plane beaucoup trop haut'), cette phase est pourtant fondamentale, car elle implique de connaître, déterminer et réunir les points de vue de la direction informatique, des directions de l'entreprise et des utilisateurs. La stratégie ainsi mise en valeur a des conséquences sur le SI, en particulier sur le plan économique où des objectifs bien précis se font souvent jour: 'diminuer le coût de gestion', 'améliorer le cash flow', etc...
    Or, lorsque vous, jeune directeur de SI, aurez à défendre votre projet devant votre direction, vous ne pourrez mettre en avant que ce type d'architecture globale, avec ces processus métier (tous les aspects plus techniques seront bien trop complexes et détaillés pour être porteurs de sens).
    Et alors ? En quoi est-ce important, crucial, vital même ????
    Comme on peut s'en douter, votre direction n'aura que deux objectifs immédiats : augmenter les revenus et abaisser les coûts. Face à votre belle architecture et ces nombreuses procédures (coûteuse en 'mandays', les fameux 'homme-jour'), votre direction aura un mot magique à la bouche : out-sourcing (en gros, car je ne suis pas spécialiste, l'externalisation). L'avantage est que vous passez un devis et transférer les risques de débordement de budget (en terme de matériel et personnel) vers le prestataire. Rq: on l'a déjà vu avec ce témoignage, l'externalisation mal maîtrisée peut faire des dégâts... et il comporte de plus des risques légaux !
    Face à cette exigence radicale, vous devez maîtriser suffisamment vos processus métier pour savoir lesquels doivent rester au sein de votre entreprise et lesquels peuvent être réalisés via une solution intermédiaire à l'externalisation complète:
- le conseil (une société de conseil établit un partenariat avec votre société et vous assiste dans la réalisation de vos objectifs);
- la régie (vous faites venir dans vos locaux de braves prestataires ;) );
- la régie forfaitisée (une externalisation sous haute surveillance)
    S'en suivra une longue bataille budgétaire et politique (qui fait quoi, à quel prix, à quel poste, avec quelles responsabilités et quels parachutes!...)