A lire sur: http://www.infodsi.com/articles/132232/syntheses-solucom-2-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.
L’un des principaux travers des DSI est de se laisser uniquement guider par les « projets » : la cohérence du SI et la maîtrise de son évolution ne peuvent dans ce cas qu’être incertaines. Il est donc nécessaire de cadrer et de piloter les évolutions du SI et de se mettre en capacité d’anticiper les événements perturbateurs les plus plausibles (contraintes réglementaires, fusion-acquisition- cession, etc.) plutôt que d’y réagir.
Préparer le futur
L’architecte SI doit :
• Définir l’orientation générale du SI (schéma directeur stratégique, 5 à 10 ans) Cette orientation doit répondre aux enjeux des différentes parties prenantes du SI - il peut s’agir d’enjeux d’entreprise (acquérir un nouveau marché, s’ouvrir à l’international...), métiers ou DSI. L’architecte SI doit donc être informé de la stratégie d’entreprise et des enjeux associés sans quoi l’orientation générale serait biaisée.
• Définir la cible SI à moyen terme (schéma directeur opérationnel, 3 à 5 ans) Afin d’anticiper l’avenir, l’architecte SI mène des études prospectives qui lui permettent notamment de maîtriser les évolutions technologiques, de vérifier la faisabilité et d’évaluer le retour sur investissements des pistes d’orientation.
Construire la trajectoire La construction de la trajectoire est l’autre priorité de l’architecte car elle expose concrètement comment la cible d’architecture peut être atteinte. Cette trajectoire indique les grandes étapes d’évolution en se basant sur :
• Une connaissance de l’existant (cartographies) : le SI étant en constante évolution, cette description de l’existant est parfois dépassée sitôt réalisée car cette activité est souvent faite a posteriori. La meilleure façon de disposer d’une description précise et à jour du SI, est que celle-ci soit réalisée par les équipes opérationnelles, durant le projet ou en mode récurrent. C’est déjà le cas par exemple pour la mise à jour de la CMDB qui est intégrée dans les processus de mise en production et de gestion des changements.
• Un portefeuille projets maîtrisé : la trajectoire doit s’appuyer sur des projets identifiés et demandés par le métier. Elle est ainsi réalisable et financée. Pour permettre à l’architecte SI d’assumer la trajectoire, il faut impliquer ce dernier dans les arbitrages budgétaires et la revue des portefeuilles projets aussi bien métiers que techniques. Sans cela, l’architecte SI ne peut avoir qu’un rôle consultatif, sans responsabilité sur la déclinaison opérationnelle du schéma directeur.
Accompagner les projets
L’architecte SI doit s’assurer de l’appropriation de la cible et de la trajectoire par les équipes opérationnelles en menant notamment toutes les actions de communication et d’animation nécessaires. Il effectue les actions de contrôle des architectures projets et peut être impliqué opérationnellement dans ces derniers, ce qui lui permet de maîtriser la trajectoire. Pour autant, l’architecte ne doit pas être dogmatique : il doit savoir accepter et intégrer les inévitables écarts causés par les projets (standards techniques incompatibles avec les certifications éditeurs, solutions non conformes arbitrées pour des raisons de coûts ou de délais, etc.) Si le DSI est le véritable commandant du navire SI, l’architecte SI en est le navigateur : il a pour responsabilité de relever le chemin parcouru (cartographies de l’existant) et de déterminer la route à suivre (cible et trajectoire).
----
Développer la valeur ajoutée pour gagner en maturité
Viser la valeur ajoutée avant la complétude de l’offre La richesse du périmètre couvert par la fonction architecture (des réflexions amont jusqu’à l’implication opérationnelle, en passant par la communication) donne un indice de son niveau de maturité. Mais il n’est pas nécessairement le plus pertinent. D’autres axes doivent être considérés, qui permettent in fine de concrétiser les apports de la fonction :
• Le niveau d’intégration entre les domaines d’architecture : le travail des architectes fonctionnels permet-il aux architectes logiciels ou techniques d’être plus efficaces sur leur périmètre ? À l’inverse, le passage d’un domaine à l’autre est-il un moment douloureux dans la vie des projets ?
• L’articulation effective entre les vues stratégique et opérationnelle : le cadre d’architecture facilite-t-il les phases de conception ? Les projets doivent-ils systématiquement dévier par rapport aux orientations proposées ?
• Les modalités de mise en oeuvre de la fonction : simple pool de ressources multi-compétences ou offre de services « clé en main », orientée résultats, faiblement couplée aux individualités qui portent le service ?
Enfin, la perception client (projet, métier, DSI) de la valeur ajoutée du service est un axe d’analyse essentiel : la fonction architecture apporte-t-elle des solutions ou bien est-elle uniquement le gendarme du SI ? Ce dernier axe conditionne la légitimité de la fonction et donc sa capacité à développer de nouvelles activités.
Les domaines techniques en avance, les domaines fonctionnels en progrès
Malgré une prise de conscience des enjeux associés à la structuration de la fonction architecture, le niveau de maturité des entreprises reste hétérogène, indépendamment de leur secteur d’activité. Cela s’explique à la fois par la jeunesse relative de la démarche, et par la volonté, là où elle a été initiée, de répondre prioritairement à une problématique précise, en obtenant des résultats concrets sur un périmètre limité, plutôt que de se risquer sur un périmètre exhaustif plus complexe à adresser.
Pour autant, certains axes se dégagent :
• La tendance a été de se concentrer sur un ou deux domaines. Ce sont en majorité les domaines techniques et logiciels / applicatifs qui en ont bénéficié du fait de leur capacité à supporter les démarches de rationalisation des infrastructures et donc à proposer un ROI plus évident.
• Le domaine fonctionnel progresse, les architectes fonctionnels étant de plus en plus impliqués dans les projets. Les approches transverses de type SOA ou MDM ont contribué à cette évolution.
• L’existence d’un domaine purement métier reste limitée ; lorsqu’il existe, le lien avec les domaines SI reste à construire.
Asseoir sa légitimité : une priorité pour l’architecte SI
Désormais reconnus à l’échelle des projets, les architectes commencent à influer sur la stratégie du SI. Afin que la fonction architecture puisse exister au-delà des seuls individus qui la composent, l’effort d’industrialisation ne doit plus se faire uniquement périmètre par périmètre mais globalement.
L’architecte SI : une contribution à développer
Si l’architecte projet est plus naturellement légitime au sein de la DSI de par sa contribution directe aux activités opérationnelles, la réalité est toute autre pour l’architecte SI car les bénéfices de son action ne peuvent se mesurer que sur le moyen terme.
Pour les projets, l’architecte SI est parfois vu comme inutile, car trop éloigné des réalités opérationnelles, voire contre-productif car n’apportant que des contraintes.
Les métiers de leur côté ne perçoivent pas toujours les enjeux liés au SI, le considérant souvent comme un mal nécessaire, un centre de coût et refusant de financer des évolutions dont ils ne pourraient bénéficier directement.
Pour obtenir les moyens de son action, il est nécessaire que le rôle d’architecte SI soit légitimé par sa position dans l’organisation. Mais cela n’est pas suffisant : que cela soit vis-à-vis du métier ou du projet, l’architecte SI doit chercher une efficacité sur le court terme (quick wins), travailler en coopération avec ses interlocuteurs et communiquer fortement.
Les clés de la légitimité pour l’architecte SI
La mise en place de la fonction d’architecte SI doit faire face à plusieurs difficultés qui sont à adresser successivement selon le niveau de maturité de la fonction (cf.tableau ci-dessous).
______
Demain : 3e partie
Organiser et animer la communauté des architectes pour gagner en efficacité
Des parcours de formation spécifiques à inventer
Le recours au marché, un véritable accélérateur
Cette Synthèse Solucom a été réalisée par Séverine Badetz est manager chez Solucom, practice Transformation SI, Thierry Debleds, manager chez Solucom, practice Architecture SI, Florent Mathé est manager chez Solucom, practice Architecture SI, Benoît Paroissin est architecte SI chez Solucom, practice Architecture SI.
Cette Synthèse a été rédigée avec l’aide de Sonia Boittin et Eric Chaurand, managers, et de Nathanaël Guiberteau consultant à Solucom.
Solucom tient à remercier Daniel Krob, directeur de recherche au CNRS, professeur à Polytechnique
et président de l’association CESAMES pour son intervention à l’Atelier du 23 juin 2011.
mardi 8 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.
---
Maîtriser l’évolution du SI : définir le cap et le tenirL’un des principaux travers des DSI est de se laisser uniquement guider par les « projets » : la cohérence du SI et la maîtrise de son évolution ne peuvent dans ce cas qu’être incertaines. Il est donc nécessaire de cadrer et de piloter les évolutions du SI et de se mettre en capacité d’anticiper les événements perturbateurs les plus plausibles (contraintes réglementaires, fusion-acquisition- cession, etc.) plutôt que d’y réagir.
Préparer le futur
L’architecte SI doit :
• Définir l’orientation générale du SI (schéma directeur stratégique, 5 à 10 ans) Cette orientation doit répondre aux enjeux des différentes parties prenantes du SI - il peut s’agir d’enjeux d’entreprise (acquérir un nouveau marché, s’ouvrir à l’international...), métiers ou DSI. L’architecte SI doit donc être informé de la stratégie d’entreprise et des enjeux associés sans quoi l’orientation générale serait biaisée.
• Définir la cible SI à moyen terme (schéma directeur opérationnel, 3 à 5 ans) Afin d’anticiper l’avenir, l’architecte SI mène des études prospectives qui lui permettent notamment de maîtriser les évolutions technologiques, de vérifier la faisabilité et d’évaluer le retour sur investissements des pistes d’orientation.
Construire la trajectoire La construction de la trajectoire est l’autre priorité de l’architecte car elle expose concrètement comment la cible d’architecture peut être atteinte. Cette trajectoire indique les grandes étapes d’évolution en se basant sur :
• Une connaissance de l’existant (cartographies) : le SI étant en constante évolution, cette description de l’existant est parfois dépassée sitôt réalisée car cette activité est souvent faite a posteriori. La meilleure façon de disposer d’une description précise et à jour du SI, est que celle-ci soit réalisée par les équipes opérationnelles, durant le projet ou en mode récurrent. C’est déjà le cas par exemple pour la mise à jour de la CMDB qui est intégrée dans les processus de mise en production et de gestion des changements.
• Un portefeuille projets maîtrisé : la trajectoire doit s’appuyer sur des projets identifiés et demandés par le métier. Elle est ainsi réalisable et financée. Pour permettre à l’architecte SI d’assumer la trajectoire, il faut impliquer ce dernier dans les arbitrages budgétaires et la revue des portefeuilles projets aussi bien métiers que techniques. Sans cela, l’architecte SI ne peut avoir qu’un rôle consultatif, sans responsabilité sur la déclinaison opérationnelle du schéma directeur.
Accompagner les projets
L’architecte SI doit s’assurer de l’appropriation de la cible et de la trajectoire par les équipes opérationnelles en menant notamment toutes les actions de communication et d’animation nécessaires. Il effectue les actions de contrôle des architectures projets et peut être impliqué opérationnellement dans ces derniers, ce qui lui permet de maîtriser la trajectoire. Pour autant, l’architecte ne doit pas être dogmatique : il doit savoir accepter et intégrer les inévitables écarts causés par les projets (standards techniques incompatibles avec les certifications éditeurs, solutions non conformes arbitrées pour des raisons de coûts ou de délais, etc.) Si le DSI est le véritable commandant du navire SI, l’architecte SI en est le navigateur : il a pour responsabilité de relever le chemin parcouru (cartographies de l’existant) et de déterminer la route à suivre (cible et trajectoire).
----
Viser la valeur ajoutée avant la complétude de l’offre La richesse du périmètre couvert par la fonction architecture (des réflexions amont jusqu’à l’implication opérationnelle, en passant par la communication) donne un indice de son niveau de maturité. Mais il n’est pas nécessairement le plus pertinent. D’autres axes doivent être considérés, qui permettent in fine de concrétiser les apports de la fonction :
• Le niveau d’intégration entre les domaines d’architecture : le travail des architectes fonctionnels permet-il aux architectes logiciels ou techniques d’être plus efficaces sur leur périmètre ? À l’inverse, le passage d’un domaine à l’autre est-il un moment douloureux dans la vie des projets ?
• L’articulation effective entre les vues stratégique et opérationnelle : le cadre d’architecture facilite-t-il les phases de conception ? Les projets doivent-ils systématiquement dévier par rapport aux orientations proposées ?
• Les modalités de mise en oeuvre de la fonction : simple pool de ressources multi-compétences ou offre de services « clé en main », orientée résultats, faiblement couplée aux individualités qui portent le service ?
Enfin, la perception client (projet, métier, DSI) de la valeur ajoutée du service est un axe d’analyse essentiel : la fonction architecture apporte-t-elle des solutions ou bien est-elle uniquement le gendarme du SI ? Ce dernier axe conditionne la légitimité de la fonction et donc sa capacité à développer de nouvelles activités.
Les domaines techniques en avance, les domaines fonctionnels en progrès
Malgré une prise de conscience des enjeux associés à la structuration de la fonction architecture, le niveau de maturité des entreprises reste hétérogène, indépendamment de leur secteur d’activité. Cela s’explique à la fois par la jeunesse relative de la démarche, et par la volonté, là où elle a été initiée, de répondre prioritairement à une problématique précise, en obtenant des résultats concrets sur un périmètre limité, plutôt que de se risquer sur un périmètre exhaustif plus complexe à adresser.
Pour autant, certains axes se dégagent :
• La tendance a été de se concentrer sur un ou deux domaines. Ce sont en majorité les domaines techniques et logiciels / applicatifs qui en ont bénéficié du fait de leur capacité à supporter les démarches de rationalisation des infrastructures et donc à proposer un ROI plus évident.
• Le domaine fonctionnel progresse, les architectes fonctionnels étant de plus en plus impliqués dans les projets. Les approches transverses de type SOA ou MDM ont contribué à cette évolution.
• L’existence d’un domaine purement métier reste limitée ; lorsqu’il existe, le lien avec les domaines SI reste à construire.
---
Asseoir sa légitimité : une priorité pour l’architecte SI
Désormais reconnus à l’échelle des projets, les architectes commencent à influer sur la stratégie du SI. Afin que la fonction architecture puisse exister au-delà des seuls individus qui la composent, l’effort d’industrialisation ne doit plus se faire uniquement périmètre par périmètre mais globalement.
L’architecte SI : une contribution à développer
Si l’architecte projet est plus naturellement légitime au sein de la DSI de par sa contribution directe aux activités opérationnelles, la réalité est toute autre pour l’architecte SI car les bénéfices de son action ne peuvent se mesurer que sur le moyen terme.
Pour les projets, l’architecte SI est parfois vu comme inutile, car trop éloigné des réalités opérationnelles, voire contre-productif car n’apportant que des contraintes.
Les métiers de leur côté ne perçoivent pas toujours les enjeux liés au SI, le considérant souvent comme un mal nécessaire, un centre de coût et refusant de financer des évolutions dont ils ne pourraient bénéficier directement.
Pour obtenir les moyens de son action, il est nécessaire que le rôle d’architecte SI soit légitimé par sa position dans l’organisation. Mais cela n’est pas suffisant : que cela soit vis-à-vis du métier ou du projet, l’architecte SI doit chercher une efficacité sur le court terme (quick wins), travailler en coopération avec ses interlocuteurs et communiquer fortement.
Les clés de la légitimité pour l’architecte SI
La mise en place de la fonction d’architecte SI doit faire face à plusieurs difficultés qui sont à adresser successivement selon le niveau de maturité de la fonction (cf.tableau ci-dessous).
| Difficultés | Leviers à activer |
|
Nouveauté du rôle |
Manque de reconnaissance auprès des DSI, des directions métiers et des projets. • Part significative du temps consacré aux activités de support aux projets • Engagement et responsabilité sur les choix d’architecture préconisés • Sponsoring de haut niveau et légitimité supportée par l’organisation • Mise en place d’instances de gouvernance adéquates • Mise en perspectives des coûts récurrents, par rapport aux coûts projet lors des arbitrages • Actions de communication |
| Difficulté à arbitrer entre les besoins métiers et les impératifs d’architecture |
Bien que les décisions de l’architecte soient au service de
l’entreprise, les métiers sont parfois réticents à financer la prise en
compte de contraintes qui ne leur bénéficient pas directement. •
Profiter de chaque opportunité projet pour obtenir des victoires rapides
à moindre coût • Disposer d’un budget propre à l’architecture permettant à celle-ci de cofinancer certains projets contribuant significativement à la trajectoire |
| Effet tunnel des activités de mise en place de la fonction architecture |
La définition du cadre d’architecture est un préalable mais peut
donner l’impression que les architectes n’apportent pas de valeur
directe à l’entreprise. • Mise en place graduelle pour minimiser les risques d’échecs, faciliter l’appropriation et libérer du temps sur les activités à valeur ajoutée • Utilisation d’un des nombreux cadres d’architecture du marché (UML-EA, TOGAF / Archimate, Zachman, Club Urba…) comme accélérateur |
|
Évolution permanente du spectre de connaissances à couvrir |
Le manque de connaissance peut avoir pour conséquence une baisse de
pertinence de l’architecte dans ses choix et un manque de crédibilité
vis-à-vis des équipes opérationnelles. • Intégration de la veille technologique comme une activité à part entière • Travail coopératif entre architectes et experts |
|
Absence des standards de modélisation d’architecture |
Modèles de livrables non existants ou bien non appropriés par les équipes projets. • Définition des standards propres à l’entreprise pour assurer la maîtrise cohérente du patrimoine SI et minimiser les efforts de conduite du changement |
______
Demain : 3e partie
Organiser et animer la communauté des architectes pour gagner en efficacité
Des parcours de formation spécifiques à inventer
Le recours au marché, un véritable accélérateur
Cette Synthèse Solucom a été réalisée par Séverine Badetz est manager chez Solucom, practice Transformation SI, Thierry Debleds, manager chez Solucom, practice Architecture SI, Florent Mathé est manager chez Solucom, practice Architecture SI, Benoît Paroissin est architecte SI chez Solucom, practice Architecture SI.
Cette Synthèse a été rédigée avec l’aide de Sonia Boittin et Eric Chaurand, managers, et de Nathanaël Guiberteau consultant à Solucom.
Solucom tient à remercier Daniel Krob, directeur de recherche au CNRS, professeur à Polytechnique
et président de l’association CESAMES pour son intervention à l’Atelier du 23 juin 2011.
Source: infoDSI.com
Aucun commentaire:
Enregistrer un commentaire