MarieKisSlaJoue

Face à des systèmes d’information de plus en plus complexes les entreprises ont senti le besoin de développer des approches pour les aider à réduire cette complexité et à mieux la maîtriser. De ce besoin sont donc nées deux approches que l’on retrouve aujourd’hui dans bon nombre de grandes entreprises. Ces méthodes portent le nom d’urbanisation du SI ou d’architecture d’entreprise (Architecture Enterprise en anglais) et aide la DSI à mieux gérer son patrimoine applicatif et à faire gagner le système d’information en agilité. Nous allons ensemble explorer un peu plus ce qu’est l’architecture d’entreprise afin de comprendre l’importance que cette démarche a dans la lutte contre le Shadow IT.

• Qu’est-ce que l’architecture d’entreprise ?

L’urbanisation est une démarche française contrairement à l’architecture d’entreprise qui est une démarche anglo-saxonne. Cependant ces deux disciplines nées en parallèles avaient pour but de répondre au même besoin. Il est amusant de constater qu’elles sont arrivées plus ou moins aux mêmes conclusions pour simplifier le SI et que ces deux disciplines se sont nourries l’une de l’autre. L’architecture d’entreprise est quelque chose de global, cela concerne toute l’entreprise et non seulement un service en particulier. Elle sert à mieux gouverner son système d’information, à le faire évoluer plus rapidement, s’aligner plus facilement avec les objectifs métiers.
Même si l’architecture d’entreprise est quelque chose de très compliquée on peut la résumer de manière très schématique. Le CIGREF l’a fait en 30 secondes. « L’architecture d’entreprise représente la manière dont l’entreprise opère et doit se transformer. Elle sert à piloter la transformation. Elle réunit l’ensemble des acteurs de l’entreprise et facilite leur synergie. Elle fournit une cible, une analyse des écarts et un planning de migration (la roadmap). C’est Un processus dynamique et itératif. »

On comprend donc que l’architecture d’entreprise est une vision globale de l’entreprise, elle permet lors d’une transformation comme c’est le cas avec la transformation digitale d’assurer une cohérence à l’ensemble des projets en plus de participer à l’alignement stratégique du système d’information. Cette démarche permet une meilleure coopération entre les différents acteurs et une meilleure gouvernance en général.

Si on devait résumer ce qu’est l’architecture d’entreprise nous pourrions dire qu’une s’agit d’aider l’entreprise dans une phase de transformation et d’aligner le système d’information avec les objectifs de l’entreprise. Toute l’entreprise est concernée par l’architecture d’entreprise. Tous doivent donc être mobiliser et adhérer à cette démarche pour que cela fonctionne. Les premiers livrables que l’on obtient avec l’architecture d’entreprise est la vision globale de son système d’information, le plus souvent sous forme de carte. Toutes ces données guideront l’entreprise pour ces décisions et se rapprocher le plus possible de la cible souhaiter par l’entreprise.

• Le lien entre EA et agilité du SI

Une des promesses de l’architecture d’entreprise est d’améliorer l’agilité de son système d’information. Si cette promesse peut être vrai elle n’est pas pour autant facile et rapide à avoir. Un projet d’architecture d’entreprise ne rend pas systématiquement le système d’information plus agile.

C’est cette promesse qui pousse la plupart des grande DSI à commencer l’urbanisation de leur système d’information. Si avant le système d’information devais juste est fiable et ouvert tous en étant sécurisé il doit maintenant en plus être agile car l’instabilité économique rend cette qualité vitale pour une entreprise.

On le sait déjà, mais un système d’information non agile est néfaste aussi bien pour le métier qui ont alors du mal à obtenir les solutions nécessaires à leur activité de la part de leur DSI. C’est aussi néfaste à la DSI qui a du mal justement à intégrer un nouveau besoin, qui a du mal à réduire ses coûts. En résumé sans agilité la DSI a du mal à gérer un système d’information qui vieillit de jour en jour et qui faut toujours renouveler.

Pour avoir un système d’information agile on garde donc les mêmes idées qu’on peut retrouver en architecture logiciel, il faut penser le système d’information en modules qui communiquent entre eux par des composants prédéfinis. Ainsi les composants modulaires du système d’information sont des briques qu’on peut facilement remplacer sans affecter les autres.

Pour obtenir cette modularité la clé est dans la gestion des échanges. On compare souvent le système d’information à un plat de spaghetti, car chaque système communique avec d’autres systèmes de façon point à point. Une telle architecture empêche tout changement qui n’aurait pas de répercussion sur le fonctionnement d’autres systèmes et donc sur les processus qui l’utilise. Pour éviter ce plat de spaghetti, (Que les anglais nome hair ball architecture), l’architecture d’entreprise préconise donc des voies d’échange clairement identifiées tel que les EAI ou ETL. Certaines architectures vont même encore plus loin. L’architecture SOA par exemple qui se base principalement sur la notion de service fourni par un système, considère que les échanges doivent se faire dans un langage pivot (très souvent du XML) au travers d’un bus qui relierait toutes les applications entre elles. Chaque système subit alors un couplage faible là où il y en avait un fort auparavant.

Attention néanmoins, ce qui fait la force d’un écosystème en général est sa diversité. Si tous les échanges de données d’une entreprise commençaient par ne passer que par un seul point alors ce point unique deviendrait une zone à risque pour l’entreprise. Il pourrait devenir un goulot d’étranglement et un système si critique qu’il serait difficile à migrer alors que nous l’avons dit, les composants d’un système d’information se rapprochent inexorablement de l’obsolescence.

• L’effet de l’EA sur le patrimoine applicatif et le Shadow IT

L’architecture d’entreprise à la particularité de proposer différentes vues du système d’information. On parle alors de la couche métier, la couche donnée, la couche applicative et enfin la couche infrastructure. Celle qui dans notre cas nous intéresse le plus est la couche applicative qui permet d’avoir une vision globale des applications d’une entreprise. Comme il est très dur de définir précisément ce qu’est une application en architecture d’entreprise. Nous allons garder une simple, c’est-à-dire une solution qui répond à un besoin exprimé par le métier. L’architecture d'’entreprise a donc tendance à bâtir son référentiel applicatif à partir des applications que la DSI connait, mais pour qu’une démarche d’architecture d’entreprise réussisse il ne faut pas se cantonner à cela. L’architecte est souvent vu comme un pont entre le métier et la DSI, un de ses principaux objectifs est de construire une cible à atteindre pour le système d’information, cible nommée souvent « To Be ». Pour pouvoir atteindre cette cible il est nécessaire de connaitre l’existant, le « As Is » et de comprendre vers quoi le métier voudrait aller, puis comment la DSI va les y aider. On sait que le Shadow IT avait l’avantage de pouvoir indiquer les besoins des utilisateurs métier. Un architecte qui s’intéresse donc à ce phénomène va avoir les pistes à suivre pour réaliser son système d’information cible.

Une bonne démarche d’architecture d’entreprise est donc une démarche qui va en plus de permettre de connaitre son patrimoine applicatif dans le scope de la DSI, va permettre de connaitre son patrimoine de Shadow IT. Il ne faut pas oublier que l’architecture d’entreprise est quelque chose de global qui appartient à toute l’entreprise et non pas seulement à la DSI comme on est tenté de le croire parfois. De plus il est assez difficile de vouloir gérer quelque chose que l’on ne connaît pas. Par sa position transverse aussi bien à l’informatique qu’auprès du métier l’équipe architecture est donc l’équipe destinée à assumer ce rôle de gestion de patrimoine de l’entreprise.

La cible définie en tête, il faut maintenant l’atteindre. Pour cela il est nécessaire de passer le patrimoine applicatif au peigne fin. Quelles applications doit-on faire évoluer ? Dans quelles applications faut-il investir ? Ou quels sont les applications qui doivent être démantelées. Autant de questions qui ne peuvent être résolues qu’avec un référentiel applicatif bien fourni en information.

Le turnover des équipes ou des postes pose aussi un autre problème, il s’agit des applications d’entreprises si vieilles que plus personne ne sait qui s’en occupe, comment elles fonctionnent et de quoi elles dépendent ? Si la documentation est une aide elle n’a pas cependant réponse à tout. Le référentiel applicatif de l’équipe architecture peut donc être le bon endroit pour conserver toujours un responsable qui aura le rôle de sachant.
 

• L’EA et la digitalisation

Nous le répétons encore une fois mais l’architecture d’entreprise appartient à toute l’entreprise. Et la digitalisation est en réalité un besoin métier. Si les DSI font leur transformation digitale, c’est uniquement pour continuer à s’aligner sur le métier. Le rôle d’architecte d’entreprise qui sert donc à aider le système d’information à s’aligner sur les fonctions métier est un rôle clé. Une DSI qui est alignée sur son métier, ce sont des risques de Shadow IT en moins.

Un des principes de l’entreprise d’architecture est de réussir à séparer certains domaines du système d’information pour en faire des briques les plus indépendantes les unes des autres. Un principe que l’on retrouve aussi en programmation. Prenons notamment le design pattern MVC qui arrive à distinguer clairement la partie présentation de la partie traitement, nous sommes ici en présence d’une front-end et d’une back-end. Ce pattern est souvent plébiscité car il permet justement d’avoir un code modulaire. Nous voyons donc que les mêmes problématiques semblent s’appliquer au monde du développement et au monde de l’architecture d’entreprise. Sans surprise on se rend vite compte que l’architecture d’entreprise est allée piocher cette bonne idée de front et back pour modéliser son système d’information.

Dans les cartographies des architectes, abrégées souvent en POS pour plan d’occupation des sols (terminologie prise aux architectes urbains), on retrouve cette découpe du système d’information avec un FrontOffice et un BackOffice. On peut ainsi distinguer en interne la gestion des contrats, des offres et des stocks de la gestion des canaux de contacts, de la relation commerciale et du marketing opérationnel.

 

Exemple de découpe fonctionnel du SI en Front et Back Office

 
Cette séparation permet donc de faire évoluer une seule partie du système d’information sans vraiment affecter l’autre. Une digitalisation réussie étant avant tout la conséquence d’un recentrage sur le client et non plus sur le produit, comme ça pouvait être le cas auparavant, il devient donc intéressant de pouvoir digitaliser avant tout sa partie FrontOffice. La digitalisation est un processus très long. Stéphane Bout, consultant McKinsey qui a participé à la conférence dédiée à la transformation numérique organisée par Microsoft le 19 novembre 2015 a lui-même conseillé de se lancer le plus tôt possible dans la transformation afin de ne pas prendre de retard sur ses concurrents.
Stéphane Bout a même défini 7 axes pour réussir sa transformation numérique, deux d’entre eux sont en lien avec les bénéfices apportés par une démarche d’architecture d’entreprise.

Le premier concerne le financement. En effet une transformation coûte de l’argent à une DSI car en plus continuer à maintenir l’informatique traditionnelle qu’on nomme souvent Core IT, il faut aussi ajouter l’arrivée des nouveaux projets digitaux qu’il faut développer puis maintenir. Ici on espérera alors que l’architecture d’entreprise aidera à réduire les coûts du système d’information en rationalisant le parc applicatif ou même les infrastructures. Si la DSI ne peut pas financer ces nouveaux projets digitaux demandés par le métier, le métier s’adressera alors ailleurs, avec un risque de voir se développer encore un peu plus le Shadow IT.

Second axe : la sécurité, un système d’information digital est de plus en plus ouvert sur l’extérieur. Si l’architecture d’entreprise n’est pas directement responsable de la sécurité de l’entreprise, son référencement sur les applications, les données et les échanges de données que font les applications entre elles, aide beaucoup à mieux sécuriser le système d’information. Nous savons déjà que le Shadow IT pose des problèmes en termes de sécurité. Dans une entreprise où le taux de Shadow IT est donc très présent la digitalisation est pénalisée.

• En résumé

L’architecture d’entreprise est une compétence clé que la plupart des grandes entreprises ont déjà cherchées à acquérir. En effet la connaissance du système d’information à assimiler est énorme et permet de se lancer dans des chantiers de transformation du système d’information de façon plus sûre. Même si le but principal d’un architecte d’entreprise n’est pas de réduire le Shadow IT, il le fait de façon intrinsèque en aidant à clarifier le système d’information existant et le système d’information cible. Il peut notamment avoir pour objectif de créer un système d’information 3-tiers pour qu’il soit plus performant et qui peut porter le coup de grâce à des pratiques de Shadow IT.