A lire sur: http://www.infodsi.com/articles/132178/syntheses-solucom-1-4-architecte-homme-cle-transformation.html?key=
La
complexité des systèmes d’information n’a fait que croître ces
dernières années et elle est devenue un véritable obstacle à une agilité
plus que jamais essentielle pour répondre aux enjeux stratégiques de
l’entreprise. Elle est aussi un facteur d’augmentation des coûts de
fonctionnement et des coûts d’intégration des nouveaux projets, alors
que la période est plutôt à la recherche d’économies. Pour réduire cette
complexité, un effort de transformation et de rationalisation des SI
s’avère nécessaire. Et les architectes du système d’information sont au
centre de cet enjeu ! En effet, ce sont eux qui doivent dessiner
l’architecture cible, définir les règles d’architecture et veiller à
leur respect par les différents projets SI. Et ce sont eux qui doivent
aussi impulser les travaux de simplification et de transformation du SI.
Face à un tel enjeu, la fonction d’architecte SI doit accélérer sa montée en puissance. Aujourd’hui encore trop souvent centrée sur la technique, elle doit aussi mieux comprendre et mieux porter la stratégie de l’entreprise. Elle doit clarifier et exprimer sa vision cible de l’architecture SI et des actions à mener pour converger progressivement vers cette cible. Sa légitimité doit être renforcée, pour que les orientations à moyen ou long termes soient prises en compte et que les efforts financiers associés soient engagés. Alors que la tendance est à l’externalisation d’une part croissante des activités opérationnelles de la DSI, l’architecture SI est bien l’un des métiers d’avenir de cette dernière, l’un de ceux qui va permettre à l’entreprise de maîtriser son destin en matière de SI.
L’architecte du bâtiment est un maître d’oeuvre…
Le terme « Architecte » provient du domaine du bâtiment. Il apparaît en France au XVIème siècle et désigne la « personne qui, par profession, trace les plans d’un édifice et en contrôle la construction » (1). De l’antiquité à l’époque contemporaine, l’architecte est l’interlocuteur privilégié du commanditaire ou maîtrise d’ouvrage (MOA) et assure le rôle de maître d’oeuvre (MOE) des travaux de construction, cumulant différentes responsabilités : conception technique et artistique, évaluation économique, direction des travaux, respect des devis et des délais et enfin réception des chantiers.
… tout comme l’architecte de projet informatique
Initialement, en informatique, le chef de projet assurait seul la MOE d’un projet dans toutes ses dimensions : relations avec la MOA, organisation des équipes et moyens, gestion du budget et du planning, choix techniques… Les projets devenant de plus en plus complexes, le rôle de chef de projet s’est peu à peu focalisé sur les aspects relationnels et organisationnels, laissant les aspects techniques à la charge des équipes de réalisation. Ceci est particulièrement vrai en France où, les développeurs, issus d’écoles d’ingénieurs, ont été en capacité d’assurer les activités de conception et d’assumer les choix techniques. Aujourd’hui, pour être complète, la MOE d’un projet doit être portée par un binôme constitué d’un chef de projet (qui pilote le planning et les budgets) et d’un architecte projet, qui est responsable de :
• La prise en compte des exigences fonctionnelles exprimées par la MOA et des contraintes exogènes (technique, sécurité...) applicables au projet ;
• La réalisation des plans généraux de la solution ;
• La validation des choix de conception détaillée ;
• La vérification de leur bonne application jusqu’à la recette projet.
L’équilibre du binôme chef de projet / architecte projet garantit la prise en compte des considérations fonctionnelles et techniques dans les arbitrages à réaliser, au même titre que le budget ou le planning. L’architecte projet doit donc maîtriser l’ensemble des dimensions d’un projet. Il est avant tout un généraliste capable d’appréhender toutes les contraintes et exigences et de les conceptualiser afin de les rendre compréhensibles par la MOA et par l’équipe de réalisation.
L’architecte SI : un rôle induit par l’évolution du SI
Les projets informatiques ont longtemps pu être menés par des équipes autonomes maîtrisant l’intégralité des composantes d’une application :
• Informatique centralisée formant un tout cohérent ;
• Progiciels homogènes sur un périmètre fonctionnel donné ;
• Applications en silos répondant à des besoins spécifiques.
Mais la juxtaposition d’applications indépendantes a montré ses limites : il est nécessaire de faire communiquer fortement ces applications entre elles pour garantir la cohérence de l’information à travers l’ensemble du SI et instrumenter des processus métiers sans rupture. L’évolution entropique du SI est également accentuée par d’autres facteurs :
• Un manque de vision globale et prospective du SI ;
• Des choix d’architecture indirectement pilotés par les métiers, notamment par leurs contraintes budgétaires et de délais ;
• Un volume de demandes de projets non maîtrisé et difficile à anticiper ;
• Un financement des projets uniquement centré sur les seuls besoins des métiers. Les projets ne peuvent donc plus être entièrement autonomes vis-à-vis du reste du SI.
Pour rester cohérent, le SI doit être considéré comme un ensemble intégré. Pour que la DSI puisse maîtriser le SI elle doit s’appuyer sur un nouveau rôle émergent : l’architecte SI. Transverse et multi-domaines, celui-ci est capable d’accompagner la stratégie d’entreprise et de la décliner opérationnellement sur le moyen terme.
Une nécessaire spécialisation des architectes...
La DSI doit faire face à une complexification sans cesse grandissante, que cela soit au niveau fonctionnel avec des métiers de plus en plus consommateurs et exigeants face au SI ou au niveau technique avec une hétérogénéité croissante. Maîtriser l’ensemble des problématiques sur tout le spectre du SI est devenu difficile, voire impossible. L’architecte, qu’il soit architecte projet ou architecte SI, finit donc par devoir se spécialiser par domaine. Parmi les domaines classiquement mis en avant, on trouve :
• Le domaine métier qui recouvre ce que l’entreprise fait et son organisation. Il contient la description des processus métiers sur la base d’un découpage en activités.
• Le domaine fonctionnel qui décrit une vision organisée des fonctions de l’entreprise, automatisées ou automatisables, utilisées dans le cadre des processus ainsi que les informations manipulées dans le cadre de ces fonctions. Ces fonctions sont indépendantes de l’organisation, des processus et des solutions techniques.
• Le domaine applicatif qui fournit une vision du SI, à savoir des fonctions automatisées du SI (application, périmètre fonctionnel, flux inter-applicatifs, données manipulées…).
• Le domaine technique qui contient les éléments d’infrastructure technique (matériels et logiciels) nécessaires au fonctionnement des applications.
Le cadre d’architecture, véritable vecteur de cohérence
Cadrer l’activité des architectes, une nécessité
L’architecture est une pratique portée par plusieurs architectes exerçant leurs activités sur plusieurs dimensions (temporelle, périmètre, domaine…). Ce morcellement des activités induit des risques d’incohérence, de non couverture de certaines dimensions et génère des flous sur les rôles et responsabilités entre les architectes et vis-à-vis des autres acteurs du SI.
Pour compenser ce morcellement et rendre un service « sans couture », il faut renforcer la coordination des activités des architectes :
• En organisant la fonction architecture pour articuler efficacement les activités et mieux maîtriser les adhérences entre domaines ;
• En industrialisant les pratiques par la définition et la mise en application d’un cadre d’architecture.
Le cadre d’architecture, pilier de la cohérence
L’enjeu d’un cadre d’architecture est de permettre l’interopérabilité d’une dimension à l’autre. Il contient :
• Une structuration en domaines (métier, fonctionnel…) pour identifier les responsabilités de chaque acteur et vérifier que la fonction architecture couvre complètement le périmètre ;
• Un vocabulaire commun et des concepts partagés (méta-modèle), pour permettre aux architectes de parler un même langage, en se basant sur des modèles évitant les interprétations, plutôt que sur de simples représentations graphiques ;
• Des méthodes et guides méthodologiques permettant d’articuler les activités d’architecture avec les autres activités du SI (études, production…) ;
• Des processus de gouvernance de l’architecture et les instances décisionnaires associées. Le cadre d’architecture est construit par les architectes SI qui, de par leur positionnement transverse, sont les plus à même de fédérer les différentes visions. Il existe plusieurs cadres d’architecture sur le marché qui ont en commun de décomposer la description de l’entreprise en plus ou moins de domaines. Peu importe le cadre choisi, ou comment il est décliné par l’entreprise, dès lors que celui-ci est suffisamment complet et cohérent, notamment sur l’accostage entre les différents domaines. L’objectif étant principalement de réconcilier l’ensemble des domaines. En support de ce cadre d’architecture, l’outillage associé doit être défini : référentiels, outils de modélisation… Ces outils communs permettent de faciliter l’échange autour des éléments de description du SI.
Un manque d’industrialisation
Le manque d’industrialisation des pratiques est caractéristique de la maturité actuelle du marché. Il se mesure notamment à travers :
• L’absence quasi-généralisée de cadre d’architecture global embrassant l’ensemble des domaines et activités ;
• Les faiblesses observées au niveau de la description du SI.
Quand elle existe, elle met généralement l’accent sur l’existant ou la cible ; la notion de trajectoire permettant de passer de l’un à l’autre étant rarement adressée. Ces lacunes s’expliquent :
• Les livrables ou activités qui permettraient le maintien à jour d’une représentation du SI sont encore trop rarement intégrés aux projets ou à l’opérationnel courant ;
• La mise à disposition des outils permettant la réalisation de ces activités, au-delà du périmètre des architectes, représente un coût d’entrée important (licences, formation) ;
• Enfin, le marché offre à ce jour peu de solutions intégrées pour adresser l’ensemble du périmètre : de l’existant à la cible en passant par la trajectoire, du fonctionnel jusqu’au technique, de l’exploitant à l’urbaniste, etc.
Beaucoup d’entreprises ont recours à des développements spécifiques pour compléter les outils du marché, développer des ponts entre les outils et mettre en place des contraintes vertueuses forçant la mise en cohérence des différents référentiels.
Maîtriser les efforts sans brider l’ambition
Le cadre d’architecture est source d’efficacité. Néanmoins, sa construction requiert un investissement important qui doit être lissé dans le temps. Il nécessite un effort continu, itératif et est construit à la manière d’un tableau : d’abord une esquisse permettant de donner les lignes principales, puis progressivement les formes générales et enfin les détails.
1. Source : Centre national de ressources textuelles et lexicales www.cnrtl.fr/etymologie/architecte
2 - CMDB : Configuration management data base
________
Demain : 2e partie
Maîtriser l’évolution du SI
Développer la valeur ajoutée pour gagner en maturité
Asseoir sa légitimité : une priorité pour l’architecte SI
vendredi 4 mai 2012
La
complexité des systèmes d’information n’a fait que croître ces
dernières années et elle est devenue un véritable obstacle à une agilité
plus que jamais essentielle pour répondre aux enjeux stratégiques de
l’entreprise. Elle est aussi un facteur d’augmentation des coûts de
fonctionnement et des coûts d’intégration des nouveaux projets, alors
que la période est plutôt à la recherche d’économies. Pour réduire cette
complexité, un effort de transformation et de rationalisation des SI
s’avère nécessaire. Et les architectes du système d’information sont au
centre de cet enjeu ! En effet, ce sont eux qui doivent dessiner
l’architecture cible, définir les règles d’architecture et veiller à
leur respect par les différents projets SI. Et ce sont eux qui doivent
aussi impulser les travaux de simplification et de transformation du SI.Face à un tel enjeu, la fonction d’architecte SI doit accélérer sa montée en puissance. Aujourd’hui encore trop souvent centrée sur la technique, elle doit aussi mieux comprendre et mieux porter la stratégie de l’entreprise. Elle doit clarifier et exprimer sa vision cible de l’architecture SI et des actions à mener pour converger progressivement vers cette cible. Sa légitimité doit être renforcée, pour que les orientations à moyen ou long termes soient prises en compte et que les efforts financiers associés soient engagés. Alors que la tendance est à l’externalisation d’une part croissante des activités opérationnelles de la DSI, l’architecture SI est bien l’un des métiers d’avenir de cette dernière, l’un de ceux qui va permettre à l’entreprise de maîtriser son destin en matière de SI.
L’architecte du bâtiment est un maître d’oeuvre…
Le terme « Architecte » provient du domaine du bâtiment. Il apparaît en France au XVIème siècle et désigne la « personne qui, par profession, trace les plans d’un édifice et en contrôle la construction » (1). De l’antiquité à l’époque contemporaine, l’architecte est l’interlocuteur privilégié du commanditaire ou maîtrise d’ouvrage (MOA) et assure le rôle de maître d’oeuvre (MOE) des travaux de construction, cumulant différentes responsabilités : conception technique et artistique, évaluation économique, direction des travaux, respect des devis et des délais et enfin réception des chantiers.
… tout comme l’architecte de projet informatique
Initialement, en informatique, le chef de projet assurait seul la MOE d’un projet dans toutes ses dimensions : relations avec la MOA, organisation des équipes et moyens, gestion du budget et du planning, choix techniques… Les projets devenant de plus en plus complexes, le rôle de chef de projet s’est peu à peu focalisé sur les aspects relationnels et organisationnels, laissant les aspects techniques à la charge des équipes de réalisation. Ceci est particulièrement vrai en France où, les développeurs, issus d’écoles d’ingénieurs, ont été en capacité d’assurer les activités de conception et d’assumer les choix techniques. Aujourd’hui, pour être complète, la MOE d’un projet doit être portée par un binôme constitué d’un chef de projet (qui pilote le planning et les budgets) et d’un architecte projet, qui est responsable de :
• La prise en compte des exigences fonctionnelles exprimées par la MOA et des contraintes exogènes (technique, sécurité...) applicables au projet ;
• La réalisation des plans généraux de la solution ;
• La validation des choix de conception détaillée ;
• La vérification de leur bonne application jusqu’à la recette projet.
L’équilibre du binôme chef de projet / architecte projet garantit la prise en compte des considérations fonctionnelles et techniques dans les arbitrages à réaliser, au même titre que le budget ou le planning. L’architecte projet doit donc maîtriser l’ensemble des dimensions d’un projet. Il est avant tout un généraliste capable d’appréhender toutes les contraintes et exigences et de les conceptualiser afin de les rendre compréhensibles par la MOA et par l’équipe de réalisation.
L’architecte SI : un rôle induit par l’évolution du SI
Les projets informatiques ont longtemps pu être menés par des équipes autonomes maîtrisant l’intégralité des composantes d’une application :
• Informatique centralisée formant un tout cohérent ;
• Progiciels homogènes sur un périmètre fonctionnel donné ;
• Applications en silos répondant à des besoins spécifiques.
Mais la juxtaposition d’applications indépendantes a montré ses limites : il est nécessaire de faire communiquer fortement ces applications entre elles pour garantir la cohérence de l’information à travers l’ensemble du SI et instrumenter des processus métiers sans rupture. L’évolution entropique du SI est également accentuée par d’autres facteurs :
• Un manque de vision globale et prospective du SI ;
• Des choix d’architecture indirectement pilotés par les métiers, notamment par leurs contraintes budgétaires et de délais ;
• Un volume de demandes de projets non maîtrisé et difficile à anticiper ;
• Un financement des projets uniquement centré sur les seuls besoins des métiers. Les projets ne peuvent donc plus être entièrement autonomes vis-à-vis du reste du SI.
Pour rester cohérent, le SI doit être considéré comme un ensemble intégré. Pour que la DSI puisse maîtriser le SI elle doit s’appuyer sur un nouveau rôle émergent : l’architecte SI. Transverse et multi-domaines, celui-ci est capable d’accompagner la stratégie d’entreprise et de la décliner opérationnellement sur le moyen terme.
Une nécessaire spécialisation des architectes...
La DSI doit faire face à une complexification sans cesse grandissante, que cela soit au niveau fonctionnel avec des métiers de plus en plus consommateurs et exigeants face au SI ou au niveau technique avec une hétérogénéité croissante. Maîtriser l’ensemble des problématiques sur tout le spectre du SI est devenu difficile, voire impossible. L’architecte, qu’il soit architecte projet ou architecte SI, finit donc par devoir se spécialiser par domaine. Parmi les domaines classiquement mis en avant, on trouve :
• Le domaine métier qui recouvre ce que l’entreprise fait et son organisation. Il contient la description des processus métiers sur la base d’un découpage en activités.
• Le domaine fonctionnel qui décrit une vision organisée des fonctions de l’entreprise, automatisées ou automatisables, utilisées dans le cadre des processus ainsi que les informations manipulées dans le cadre de ces fonctions. Ces fonctions sont indépendantes de l’organisation, des processus et des solutions techniques.
• Le domaine applicatif qui fournit une vision du SI, à savoir des fonctions automatisées du SI (application, périmètre fonctionnel, flux inter-applicatifs, données manipulées…).
• Le domaine technique qui contient les éléments d’infrastructure technique (matériels et logiciels) nécessaires au fonctionnement des applications.
Le cadre d’architecture, véritable vecteur de cohérence
Cadrer l’activité des architectes, une nécessité
L’architecture est une pratique portée par plusieurs architectes exerçant leurs activités sur plusieurs dimensions (temporelle, périmètre, domaine…). Ce morcellement des activités induit des risques d’incohérence, de non couverture de certaines dimensions et génère des flous sur les rôles et responsabilités entre les architectes et vis-à-vis des autres acteurs du SI.
Pour compenser ce morcellement et rendre un service « sans couture », il faut renforcer la coordination des activités des architectes :
• En organisant la fonction architecture pour articuler efficacement les activités et mieux maîtriser les adhérences entre domaines ;
• En industrialisant les pratiques par la définition et la mise en application d’un cadre d’architecture.
Le cadre d’architecture, pilier de la cohérence
L’enjeu d’un cadre d’architecture est de permettre l’interopérabilité d’une dimension à l’autre. Il contient :
• Une structuration en domaines (métier, fonctionnel…) pour identifier les responsabilités de chaque acteur et vérifier que la fonction architecture couvre complètement le périmètre ;
• Un vocabulaire commun et des concepts partagés (méta-modèle), pour permettre aux architectes de parler un même langage, en se basant sur des modèles évitant les interprétations, plutôt que sur de simples représentations graphiques ;
• Des méthodes et guides méthodologiques permettant d’articuler les activités d’architecture avec les autres activités du SI (études, production…) ;
• Des processus de gouvernance de l’architecture et les instances décisionnaires associées. Le cadre d’architecture est construit par les architectes SI qui, de par leur positionnement transverse, sont les plus à même de fédérer les différentes visions. Il existe plusieurs cadres d’architecture sur le marché qui ont en commun de décomposer la description de l’entreprise en plus ou moins de domaines. Peu importe le cadre choisi, ou comment il est décliné par l’entreprise, dès lors que celui-ci est suffisamment complet et cohérent, notamment sur l’accostage entre les différents domaines. L’objectif étant principalement de réconcilier l’ensemble des domaines. En support de ce cadre d’architecture, l’outillage associé doit être défini : référentiels, outils de modélisation… Ces outils communs permettent de faciliter l’échange autour des éléments de description du SI.
Un manque d’industrialisation
Le manque d’industrialisation des pratiques est caractéristique de la maturité actuelle du marché. Il se mesure notamment à travers :
• L’absence quasi-généralisée de cadre d’architecture global embrassant l’ensemble des domaines et activités ;
• Les faiblesses observées au niveau de la description du SI.
Quand elle existe, elle met généralement l’accent sur l’existant ou la cible ; la notion de trajectoire permettant de passer de l’un à l’autre étant rarement adressée. Ces lacunes s’expliquent :
• Les livrables ou activités qui permettraient le maintien à jour d’une représentation du SI sont encore trop rarement intégrés aux projets ou à l’opérationnel courant ;
• La mise à disposition des outils permettant la réalisation de ces activités, au-delà du périmètre des architectes, représente un coût d’entrée important (licences, formation) ;
• Enfin, le marché offre à ce jour peu de solutions intégrées pour adresser l’ensemble du périmètre : de l’existant à la cible en passant par la trajectoire, du fonctionnel jusqu’au technique, de l’exploitant à l’urbaniste, etc.
Beaucoup d’entreprises ont recours à des développements spécifiques pour compléter les outils du marché, développer des ponts entre les outils et mettre en place des contraintes vertueuses forçant la mise en cohérence des différents référentiels.
Maîtriser les efforts sans brider l’ambition
Le cadre d’architecture est source d’efficacité. Néanmoins, sa construction requiert un investissement important qui doit être lissé dans le temps. Il nécessite un effort continu, itératif et est construit à la manière d’un tableau : d’abord une esquisse permettant de donner les lignes principales, puis progressivement les formes générales et enfin les détails.
1. Source : Centre national de ressources textuelles et lexicales www.cnrtl.fr/etymologie/architecte
2 - CMDB : Configuration management data base
________
Demain : 2e partie
Maîtriser l’évolution du SI
Développer la valeur ajoutée pour gagner en maturité
Asseoir sa légitimité : une priorité pour l’architecte SI
Source: infoDSI.com
Aucun commentaire:
Enregistrer un commentaire