Au commencement de l’informatisation des entreprises, les premiers ordinateurs étaient destinés à collecter des données sur des périmètres très précis portés par des programmes informatiques. Schématiquement, une personne en charge de la comptabilité travaillait sur un programme comptable etc. Cela signifie que les programmes informatiques fonctionnaient de façon indépendante et qu’il n’y avait pas de communication entre les différents programmes.

 

 

Pourquoi a-t-il été créé ? Le besoin

Au commencement de l’informatisation des entreprises, les premiers ordinateurs étaient destinés à collecter des données sur des périmètres très précis portés par des programmes informatiques. Schématiquement, une personne en charge de la comptabilité travaillait sur un programme comptable etc. Cela signifie que les programmes informatiques fonctionnaient de façon indépendante et qu’il n’y avait pas de communication entre les différents programmes.

La baisse des coûts des infrastructures et matériels a permis de rendre plus accessible l’accès aux outils informatiques. De ce fait, les entreprises ont peu à peu délaissé le papier pour informatiser un certain nombre de processus métier.

• les outils bureautiques  comme les tableurs et les logiciels de traitement de texte ont généré un fort gain de temps. Cela a eu pour effet de goûter aux avantages de la réutilisabilité : je peux réutiliser un document et l’adapter à un nouvel usage, je sauvegarde et j’enrichis de nouvelles versions au fur et à mesure. Mais cela ne permet pas de régler l’effet silo : un collaborateur gère un ensemble de documents ou de programmes mais ne les partage pas. C’est alors que nous avons trouvé des solutions à la fois matérielles et logicielles pouvant répondre à ce besoin. Comment ? En mettant en place des matériels tels que des serveurs partagés et d’un point de vu logiciel en installant des systèmes d’échanges. Ces systèmes ont pour vocation de véhiculer des messages (qui sont composés de données d’une application à l’autre). Nous les appellerons des bus de messages qui comme leur nom l’indique ont un rôle d’acheminement et de transport.
• Mais qui définit les trajets des lignes de bus, les stations et les données qui transitent? Comment gère-t-on les erreurs, problèmes de routage ? On voit bien qu’il faut une coordination, un chef d’orchestre qui organise tout cela. Et puis, pour reprendre la même métaphore, lorsque le système d’information grandit, il faut bien optimiser les lignes de bus, supprimer les stations vétustes et s’assurer que les voyageurs arrivent à bon port dans le même état qu’au début du voyage.

Et c’est là qu’intervient l’architecte qui met en cohérence les systèmes, organise les échanges entre eux et s’assure de répondre à la stratégie de l’entreprise.

 

Les premiers pas techniques

C’est donc sous un angle technique et logique que ces problématiques ont été traitées. On a trouvé des solutions techniques et logicielles pour traiter et ordonnancer les messages entre différentes applications autonomes « en silo » mais formant le tout du système d’information.

Les architectes ont entrepris de prendre du recul pour avoir une vision globale du système d’information et ont commencé à appréhender le SI comme un puzzle. L’idée étant que malgré la mise à disposition de ces systèmes d’échanges, se pose la question de savoir où sont les vraies données et que le temps de circuit de la donnée ne soit pas trop long.

Chemin faisant, le contexte des SI a évolué car les entreprises ont grossi aussi bien par croissance organique que par des rachats et les problématiques d’échanges des données sont devenues de plus en plus prégnantes.

C’est alors que d’autres types d’architectures ont vu le jour, notamment les architectures SOA. Nous n’allons pas traiter dans cet article de ce sujet qui pourrait être un article en soi si cela vous intéresse.

Il faut simplement retenir que ce type d’architecture est modulaire et a pour objectif d’ancrer cette vision « puzzle » du système d’information.

Et on voit bien là que l’architecte devient le métier indispensable pour connaître le patrimoine du SI, bien positionner les pièces du puzzle et identifier les pièces à remplacer et dans quel ordre.

 

Et maintenant ? De l’expansion d’internet…

Ces dernières années, l’expansion d’internet a complètement révolutionné notre société. Nous cherchons tout sur internet, il y a des applications sur tous les sujets et nous croulons sous les contenus. D’autre part, le foisonnement d’informations et de nouveautés pousse à une exigence d’avoir ce que l’on souhaite, quand on le souhaite et tout doit aller de plus en plus vite.

Par ailleurs, les frontières des entreprises sont devenues poreuses : au départ, seules les entreprises full web communiquaient via internet avec leurs clients mais maintenant la plupart des entreprises le font. Et pour envoyer des données à l’extérieur, il faut être en mesure d’ouvrir son SI.

Et enfin, il y a un autre type d’ouverture qui est plus subtil : nous sommes de plus en plus sur des modèles économiques à la demande qui s’ajustent en fonction des besoins. Auparavant, lorsqu’une entreprise achetait un logiciel, elle signait un contrat pour un nombre de licences et une maintenance sur une durée déterminée. Le logiciel était ensuite installé sur les postes et voilà! Mais ce temps est révolu et la tendance est d’acquérir des solutions SaaS: L’entreprise contracte auprès de l’éditeur l’usage de son logiciel mais ne l’installe pas puisqu’il est dans les nuages, c’est ce qu’on appelle du Cloud. Mais il faut quand même “intégrer” cette solution dans le SI pour assurer la fluidité de la circulation des données et éviter l’effet silo abordé précédemment. Cela revient à considérer que la solution Saas qui est donc extérieure doit être vue comme une pièce du puzzle interne en sachant qu’elle est finalement à la fois à l’intérieur et à l’extérieur. Vous voyez la subtilité? Sachant que dans la plupart des SI de grande taille, ce n’est pas une solution SaaS mais plusieurs qu’il faut intégrer.

 

Pour bien envisager cette ouverture, il faut s’assurer de trois fondamentaux:

• l’entreprise qui ouvre son SI ne doit pas se mettre en danger. Elle doit donc sécuriser cette ouverture et fixer le cadre de son ouverture (qui a accès à quoi et comment)
• les données qui sont communiquées à des tiers (clients ou fournisseurs) doivent être justes et de qualité car rien de pire pour un client que de lui communiquer des informations erronées
• l’entreprise qui utilise des solutions SaaS doit bien réfléchir à la gouvernance de ses données et à la valeur des données qui sont envoyées dans le cloud. Nous voyons bien que nous passons d’un SI “interne” à un SI qui a tendance à se déporter vers l’extérieur. Cela présente certes de nombreux avantages mais encore faut-il rester capitaine de son navire.

 

…A l’APIsation

Depuis ces dernières années, les cartes sont rebattues et le rôle de l’architecte se transforme car il développe une vision à l’intérieur et à l’extérieur de l’entreprise.

Il définit à la fois le cadre technique dans lequel les différentes équipes doivent travailler, s’assure que le SI est à même de répondre aux enjeux de l’entreprise de façon immédiate et à moyen terme et doit également se tenir au courant des tendances, des technologies qui arrivent et qui peuvent bousculer nos certitudes, nous offrir des avantages ou nous mettre en danger.

Le chef d’orchestre n’est pas un spécialiste de ces thématiques mais sa vision d’ensemble lui permet d’être facilitateur et de mettre de l’huile dans les rouages. Il donne du sens et permet d’éclairer les choix de façon globale.

 

En ce qui nous concerne, nous pensons que l’APIsation de notre monde n’est pas un sujet technique mais bien un sujet sociétal qui est une composante majeure de la transformation digitale.

Pour faire simple (mais nous y consacrerons prochainement un article), il existe un standard qui permet de développer des petites briques de fonctionnalités que l’on pourrait comparer à des petites briques de lego qui sont mises à disposition de certains voire de tous : ce sont les API. L’impact sur les entreprises est révolutionnaire car ce standard permet de ne pas réinventer la roue et d’utiliser déjà des API prêtes à l’emploi. Le sujet n’est plus d’être expert mais juste de mettre en place le cadre qui permet de mettre en cohérence et de saupoudrer du petit plus qui fera la différence. Et une fois de plus, qui peut avoir le recul pour faciliter cette mise en cohérence…oui, toujours l’architecte!

 

Pour aller plus loin : les grands profils d’architectes

 

L’architecte est le chef d’orchestre du SI qui a la vision transverse nécessaire pour coordonner tout cela. Les équipes projet ont la vision et la maîtrise de leur terrain de jeu mais c’est l’architecte qui “dé-zoome” et donne la vision d’ensemble.

L’architecte SI est donc le facilitateur qui donne le cap, met en place le cadre pour laisser ensuite la créativité et l’expertise s’exprimer.

Ses compétences et son champ d’action étant assez vastes, les grands SI ont différents profils d’architectes et on compte principalement :

• l’architecte d’entreprise : autrefois appelé urbaniste du SI, il travaille sur la stratégie du SI et grâce à sa vision globale, il essaie d’avoir toujours un coup d’avance en projetant le SI dans le futur afin de s’assurer qu’il sera toujours en cohérence avec son époque et la stratégie de l’entreprise
• l’architecte fonctionnel : selon les entreprises, c’est un architecte d’entreprise ou bien un architecte d’entreprise dédié à un domaine métier particulier (par exemple RH, Finances etc)
• l’architecte applicatif : il adresse les sujets à la vue applicative et définit les “pattern” qui sont les cadres de développement que doivent utiliser les développeurs afin de s’assurer de la cohérence globale du SI. Il anticipe également les obsolescences technologiques et proposer des solutions de remplacement afin de veiller à ce que le SI ne soit pas vieillissant, voire obsolète. Il travaille avec l’architecte d’entreprise pour répondre aux problématiques d’ouverture du SI et de gouvernance de la donnée
• l’architecte technique : Il adresse les sujets d’architecture au niveau infra, c’est à dire à un niveau technique plus détaillé et formalise les exigences du SI.