Commencer par se doter d’indicateurs simples et évolutifs…

À l’heure de mettre en place les premiers indicateurs, les DSI retiennent en général trois axes d’analyse clés. D’abord, ils sont attentifs au niveau de réactivité et à la qualité de réponse de l’architecture aux demandes projet. Ils cherchent également à mesurer le pourcentage de projets qui font appel à l’expertise et à la validation des architectes ainsi qu’à connaître le positionnement de ces derniers sur ces projets : intervention dès la phase de cadrage au lancement de l’étude ou au contraire sollicitation a posteriori lors des dernières étapes du design de l’architecture. Enfin, les DSI sont soucieux du niveau de « qualité » des architectures proposées (taux de panne sur les architectures mises en production, taux de respect des SLA, etc.).

Ces indicateurs tendent à évoluer au fur et à mesure que s’industrialise la fonction. L’idée est justement de valoriser les apports du cadre d’architecture ou encore les efforts de rationalisation des coûts faits par les architectes : taux de réutilisation des composants, taux d’adéquation des architectures aux patterns définis ou encore niveau d’efficacité économique des architectures.

Arrêtons-nous un instant sur ce dernier exemple. Mesurer l’efficacité économique des architectures implique la mise en place ou l’adaptation de modèles budgétaires ad hoc. Or, l’expérience montre que ces modèles sont généralement erronés par rapport aux coûts réels. C’est pourquoi avant d’envisager tout indicateur il est important de répondre à deux questions fondamentales : cet indicateur m’apprend-t-il des choses ? Apporte-t-il  des résultats fiables (vérifiés) ? Une bonne pratique lors de la mise en place de tels indicateurs sera par exemple de respecter la règle « SMART« .

Mesurer l’apport de la fonction architecture sur les principaux enjeux de la DSI

L’architecte se doit de participer activement à la définition des enjeux IT et à la construction des réponses à apporter à ces enjeux. Bien sûr, selon les entreprises, ces enjeux (et par conséquent ce que l’on attend des architectes) peuvent être de natures très diverses : réduction des coûts, accompagnement de la transformation métier, palier technologique majeur ou apport d’innovation IT, etc.

Les indicateurs de performance de la fonction architecture ne doivent donc pas évoluer qu’en fonction du niveau de maturité de cette fonction mais doivent aussi être contextualisés par rapport aux enjeux de la DSI et donc par rapport à la « lettre de mission des architectes ».

Par exemple, dans une DSI principalement centrée sur l’optimisation de sa performance économique, des indicateurs tels que la charge moyenne passée sur chaque projet, le coût des architectures proposées ou le taux de rationalisation des socles applicatifs seront prépondérants. À l’inverse, si l’enjeu majeur de la DSI est la remise en cohérence de l’IT par rapport au métier, on privilégiera des indicateurs de couverture des besoins fonctionnels, de niveau de satisfaction des métiers ou encore d’agilité du SI (délai de réalisation des architectures, etc.).

Piloter et promouvoir la fonction architecture

Trop souvent, les indicateurs de performance de la fonction architecture restent confinés en interne de la cellule et ne sont pas communiqués en dehors. Ils constituent pourtant un formidable outil de communication et devraient systématiquement être utilisés pour promouvoir l’apport de valeur des architectes sur les projets d’une part, et sur la stratégie de la DSI d’autre part.

Hélas, même lorsqu’on se limite à regarder en interne de la fonction architecture, on constate bien souvent que ces indicateurs ne sont utilisés que pour du pilotage opérationnel « de bas niveau » quand ils devraient aider à prendre de la hauteur sur l’amélioration de la fonction. Ils pourraient par exemple être exploités pour réfléchir sur le repositionnement des architectes dans le cycle de vie des projets, sur l’alignement des compétences par rapport aux besoins ou encore sur l’amélioration continue du processus d’architecture.

Juger de la performance d’une fonction architecture, c’est donc d’une part mesurer sa pertinence dans l’accompagnement des projets et d’autre part, confirmer sa plus-value par rapport aux enjeux de l’entreprise. Sans oublier, bien sûr, que mesurer l’apport de la fonction architecture poursuit aussi un but double : aider à son pilotage et à sa promotion auprès de la DSI voire même des Métiers.

Cet article Jugeons de la performance de la fonction architecture ! est apparu en premier sur RiskInsight.

Le rôle d’architecte se décline sur deux dimensions. L’une, stratégique, qui porte sur le SI à horizon 2 à 5 ans et l’autre,  opérationnelle à horizon 6 à 12 mois, qui se focalise sur un projet SI. L’architecte vise ainsi à mettre en cohérence plusieurs angles de vue (DSI, métiers) selon des timings  différents  et sur toutes les couches du SI (fonctionnelle, informationnelle, applicative, technique). Cette mise en cohérence doit  naturellement être réalisée de manière systématique et industrialisée, c’est-à-dire dans le respect d’un cadre d’architecture et selon une gouvernance appropriée.

Une maturité du marché encore faible, reflet d’un rôle en construction

Chez la plupart des grands comptes, l’architecture d’entreprise a une maturité faible. Toutefois, pour faire face aux nouveaux enjeux des DSI (rationalisation du parc applicatif et de l’IT, recours aux services dans le Cloud pour les domaines support, introduction de nouveaux modes de fonctionnement pour raccourcir les délais de mise en production, etc.) elle tend à se développer de plus en plus.

Quelques pistes pour gagner en maturité

Pour accompagner  ce mouvement, nous recommandons de concentrer  les efforts sur 2 points.

– Profiter des phases d’engagement des grands projets pour permettre aux architectes de décliner les principes directeurs de la transformation du SI et ainsi garantir leur bonne application. L’implication des architectes d’entreprise sur les dossiers de cadrage est nécessaire pour donner aux donneurs d’ordre les bonnes clés d’arbitrage.

– Intégrer au cycle projet les instances de gouvernance qui régissent le processus de définition et de mise en œuvre de l’architecture.  Cela  permet à la fois de peser sur les choix en apportant des solutions pragmatiques et réalistes mais aussi de communiquer sur l’apport de valeur en mettant en cohérence et en perspective l’ensemble des projets d’un domaine.

Il va sans dire que l’architecture d’entreprise gagne aujourd’hui du terrain chez l’ensemble des grands comptes mais peine encore à trouver des moyens à la hauteur des enjeux adressés, comme nous l’avons vu dans un article précédent. Son implantation passe donc par une mise en œuvre pragmatique sur les programmes clés de l’entreprise afin de gagner en légitimité.

Cet article L’architecture d’entreprise : une maturité qui progresse, reflet d’un rôle en construction est apparu en premier sur RiskInsight.

Architecture d’entreprise : 4 raisons d’entreprendre la démarche

1. Rationaliser les coûts – C’est là le leitmotiv récurrent, les réponses étant à adapter au niveau de maturité de l’entreprise. Forte de la réponse globale (infrastructures, applications ou processus de gouvernance) qu’elle peut apporter, l’architecture d’entreprise y contribue fortement. Ce sont néanmoins principalement les couches dites « basses » du SI qui bénéficient de cette logique de rationalisation grâce à la définition et à la mise en œuvre de socles techniques. Seules les entreprises les plus matures sauront réussir leurs tentatives de rationalisation des couches dites « hautes » (notamment en termes de services métiers comme le promettaient les démarches SOA).

2. Connaître l’existant – Connaître son SI accélère la phase d’analyse de l’existant préalable à toute étude dans le cadre d’évolutions métiers ou technologiques. L’architecture d’entreprise permet d’accéder à cette vision globale du SI et de l’entreprise et donc de gagner en réactivité. Par exemple, l’évolution majeure du poste de travail ou de l’infrastructure demande une bonne connaissance du parc applicatif pour définir la stratégie de migration.

3. Définir la cible SI – Définir une cible SI pour répondre au mieux aux enjeux stratégiques de l’entreprise est, malgré les apparences (« c’est trop théorique ! »), un exercice de projection essentiel qui permet de poser les 1ers jalons de réalisation du SI qui serviront à valider au fur et à mesure les orientations des différents projets.

4. Être force de proposition vis-à-vis des Métiers – Restreindre la DSI à un ensemble de techniciens est monnaie courante. Pour briser cet a priori, la DSI doit apprendre à se positionner vis-à-vis des Métiers. L’architecture d’entreprise permet à la DSI notamment d’instaurer un dialogue dans la durée (pour mieux comprendre les besoins et contraintes des Métiers). Par ce biais, la DSI peut jouer un rôle de conseil en vulgarisant pour les Métiers les nouvelles technologies et leurs apports. Loin du simple fournisseur de solutions techniques, elle devient incubateur d’innovation pour les Métiers ! 

L’architecture d’entreprise en pratique : étapes de mise en œuvre

Il est bien entendu essentiel de définir les contours d’une 1^ère version de la démarche. Une entreprise et son SI sont souvent représentés en couches (stratégie, métier, fonctionnelle, applicative et technique), l’architecture d’entreprise se concentrant sur les trois dernières. Il est illusoire de vouloir s’attaquer de but en blanc à l’ensemble des couches. Aussi faut-il choisir ses combats en se concentrant sur les faiblesses de l’entreprise et sur certains quick wins.

Par la suite, il faut mettre en place une organisation et des process.

• Définir des rôles clés s’avère incontournable. Créer le rôle d’architecte d’entreprise est indispensable. Il est celui qui saura allier connaissance du SI et du Métier, celui qui saura le mieux dialoguer avec toutes les parties prenantes, au-delà de son expertise technique. Un deuxième rôle qu’un sponsor de haut niveau est indispensable pour légitimer ce rôle dans l’entreprise et l’inscrire dans la durée.
• Construire et mettre à jour le référentiel est aussi rapidement nécessaire. Élément clé de toute démarche d’architecture d’entreprise, il comporte notamment un ensemble de cartographies du SI (fonctions SI, applications, services applicatifs, éléments techniques, objets métiers…) qu’il faudra enrichir, un catalogue des solutions applicatives et techniques référencées (ensemble des composants validés et recommandés par la DSI pour constituer les réponses SI aux besoins métiers ou techniques) ainsi que différents patterns d’architecture. Attention néanmoins : se noyer dans trop de détails est préjudiciable à la pertinence du référentiel d’architecture et augmente les chances de ne pas être à jour. À l’inverse, un manque d’informations peut nuire aux besoins des projets SI.
• Mettre en place un process de veille et d’innovation doit également permettre à la DSI de capter les nouveaux usages et d’en expliquer les enjeux et contraintes aux Métiers pour ne plus les subir.

Seules des instances de gouvernance transverse sauront par ailleurs soutenir ces différents process. Il s’agit d’établir un dialogue récurrent avec les Métiers avec pour ordre du jour partage des contraintes, présentation par la DSI des sujets d’innovation technologique (économies réalisées, diminution du temps de mise en production d’un nouveau produit…), etc.

Pour autant, tous ces process ne sauront être efficaces si la DSI n’arrive pas vendre son projet d’architecture d’entreprise en interne ! Deux types d’acteurs sont à convaincre de l’intérêt de la démarche : les Métiers, à qui il faut très clairement expliquer qu’il ne s’agit pas de « marcher sur leurs plates-bandes » mais de mieux les accompagner, et les acteurs de la DSI elle-même qui, pour certains, pourraient l’interpréter comme une façon d’être contrôlés. Il faut au contraire convaincre ces derniers de l’accès à des activités stratégiques à plus forte valeur ajoutée (et comprenant plus d’interactions avec les Métiers de l’entreprise).

Aussi, inutile de se poser la question ! Vous n’avez aujourd’hui plus le choix et devez vous lancer dans une démarche d’architecture d’entreprise. Les évolutions majeures que vit ou va vivre votre entreprise amènent naturellement à lancer ce type de démarche. Autant éviter la marche forcée et accompagner le changement en douceur ! C’est la garantie d’une amélioration sensible de vos relations avec les Métiers.

Pour lire d’avantage sur l’architecture d’entreprise cliquez ici.

Cet article Et si l’architecture d’entreprise permettait enfin de briser la glace avec les Métiers ? est apparu en premier sur RiskInsight.

 Familles d’écueils rencontrés

À cela, plusieurs raisons concomitantes.

Il n’existe en général pas un, mais plusieurs, référentiels d’architecture (les architectures applicatives et fonctionnelles dans un premier référentiel, l’architecture technique dans un second référentiel via une CMDB).

Par ailleurs, de trop nombreux acteurs sont impliqués dans la vie de ces référentiels : urbanistes, architectes SI, architectes de domaine, architectes projet, exploitants…, diluant de ce fait les responsabilités.

Enfin, les processus de mise à jour du référentiel ne font souvent pas partie du cycle de vie projet. Seul le bon vouloir des différents acteurs garantit le maintien d’une information à jour et de qualité.

 Usages d’un référentiel d’architecture d’entreprise

Cependant, disposer de référentiels à jour et exhaustifs contribue efficacement aux principaux projets SI.

Dans le cadre d’évolutions des postes de travail, connaître le parc des applications (application client léger, application client lourd, etc.) s’avère nécessaire pour définir la politique de migration.

De même, les projets d’évolution de l’infrastructure doivent forcément s’accompagner de l’étude de l’impact sur le parc applicatif.

L’utilisation de référentiels facilite également la phase d’analyse de l’existant préalable à toute étude dans le cadre d’évolutions métiers.

Il est aussi indispensable de connaitre l’impact applicatif et fonctionnel et de le présenter aux métiers concernés dans le cas de l’externalisation d’un domaine technique.

Enfin, pour garantir l’industrialisation des solutions et donc la réduction des coûts, la mise en place de standards architecturaux est un impératif.

 Un contenu bien ciblé

En termes de contenu, plusieurs éléments sont à prévoir :

• L’ensemble des cartographies du SI : fonctions SI, applications, services applicatifs, éléments techniques (tels que les services techniques, les infrastructures…). Les cartographies de l’existant constitueront une première étape, qu’il conviendra d’enrichir avec une vision plus prospective.
• Le catalogue des solutions applicatives et techniques référencées : ensemble des composants validés et recommandés par la DSI pour constituer les réponses SI aux besoins métiers ou techniques.
• Les différents patterns d’architecture : typologies d’architecture à mettre en place afin de répondre aux besoins SI.

 Facteurs clés pour une implémentation réussie

Grande question que celle du niveau de granularité des informations contenues dans ces référentiels d’architecture d’entreprise. Se noyer dans un niveau trop important de détail est préjudiciable à la pertinence du référentiel et augmente ses chances de ne pas être à jour. A contrario, un manque d’informations peut nuire aux besoins notamment des projets SI et de ce fait n’avoir plus d’utilité.

Quelques recommandations pour profiter au mieux de ces outils au service des projets SI :

Première condition, accepter d’avoir un outillage multiple… mais mettre en place des processus qui garantissent les corrélations et les mises à jour des informations.

Seconde condition, lancer les premiers chantiers sur un sous-ensemble cohérent (architectures applicative et technique ou architectures fonctionnelle et applicative).

Enfin, dernière condition de succès, travailler à l’insertion du process de définition de l’architecture dans le cycle projet (a minima prévoir les points de contrôle).

A l’heure où les DSI se targuent d’être industrielles, innovantes,… bref, à l’état de l’art, il est temps de mettre en place et faire vivre ces référentiels d’architecture d’entreprise !

Cet article Référentiel d’architecture d’entreprise : vous ne pouvez plus faire l’impasse ! est apparu en premier sur RiskInsight.