Les grandes entreprises ont besoin de stratégies informatiques, en particulier en matière d’architecture applicative. Voici donc une esquisse de stratégie architecturale.

1. Objectifs stratégiques
   • sécuriser l’environnement informatique : maintenir la sécurité de fonctionnement du système d’information, faire cesser la prolifération désordonnée des technologie, maîtriser l’incendie du e-business
   • optimiser les économies : réduire les coûts sur le long terme, gagner en productivité
   • bâtir un ordre social pour la communauté informatique : ordonner les investissements informatiques, se doter d’une politique, de règles d’architecture, de processus de contrôle, construire une communauté interne pour soutenir et faire appliquer cette politique
   • => « triple bottom line » => comment assurer développement durable d’une architecture informatique ? une architecture « future-proof » ?
2. Objectifs tactiques : construire une architecture applicative durable …
   • … du point de vue économique : à moindre TCO = « scalable » (évolutivité, capacité à supporter des développements futurs à moindre coût), exploitable et maintenable (minimiser les coûts récurrents), à moindre investissement (licences logiciells, …)
   • … du point de vue écologique : sûre et robuste quelles que soient les évolutions du reste de l’environnement informatique (sécurité, interopérabilité, portabilité, évolutivité), sobre en ressources (en ressources réseaux, en infrastructure), assurant une autonomie vis-à-vis de son environnement (indépendance vis-à-vis des politiques commerciales des fournisseurs, indépendante de l’évolution des métiers de l’entreprise, indépendante des évolutions de l’organisation de l’entreprise à moyen terme y compris acquisitions et cessions),
   • … du point de vue social : appuyée sur un modèle de gouvernance durable, qui implique toutes les parties prenantes de la gestion des systèmes d’information (y compris les fournisseurs et éditeurs, les services utilisateurs, les équipes informatiques, la direction générale), offrant des ancrages de l’organisation dans des communautés locales et des réseaux de partenariat étendus (avec d’autres entreprises partenaires, avec les futurs gestionnaires de cette architecture, …)
   • donc appuyée sur les principes architecturaux suivants :
     • couplage faible et couplage tardif : les composants mis en oeuvre doivent offrir une modularité extrême, pouvoir évoluer indépendamment les uns des autres, être « agnostiques » sur l’usage qui sera fait des données qu’ils traitent ou produisent (de manière à en maximiser les opportunités de réutilisation), faire les hypothèses les plus réduites possibles sur les évolutions à venir du S.I., ne pas requérir de vision globale (ni d’étude globale) préalable à leur mise en oeuvre, supporter une dynamique d’évolution « en bazar » plutôt qu’ « en cathédrale », s’assembler selon le modèle REST (REpresentational State Transfer) plutôt que selon le modèle RPC (Remote Procedure Call)
     • l’architecture applicative est isolée des métiers : de même que la fonction financière de l’entreprise peut être rendue indépendante des spécificités de ses métiers, l’architecture applicative, pour être durable, doit être considérée comme indépendante des métiers d’entreprise ; sa portée est universelle dans l’entreprise ; son universalité offre des opportunités de benchmarking et de partenariat étendues avec les acteurs externes
     • respect absolu des standards les plus ouverts possibles : qu’il s’agisse d’un standard de facto (informatique « legacy », monopole commercial, …) ou de jure (spécifié par un organisme de normalisation), un standard est ouvert si :
       • il « vient de l’Internet », i.e. on peut observer un grand nombres de ses implémentations sur l’Internet, ses spécifications détaillées sont publiées sur l’Internet, la communauté qui l’a élaborée privilégie l’Internet comme mode de collaboration,
       • il dispose d’implémentations nombreuses et diverses et l’une de ses implémentations est distribuée sous une licence de type « open source »,
       • ses spécifications sont élaborées par une communauté ouverte : regroupant des acteurs d’origine et de taille diverses, avec une barrière à l’entrée très basse, et sachant tirer partie des contributions qui lui sont adressées sur la base de l’intérêt objectif de celles-ci et non de l’identité du contributeur
3. Objectifs opérationnels
   • contrôler l’architecture par le biais des relations fournisseurs : favoriser systématiquement la mise en concurrence des fournisseurs informatiques, n’acquérir une technologie que lorsqu’elle s’accompagne d’une offre de services supportée par une communauté de prestataires à la fois diversifiée (plusieurs sociétés de services) et dynamique (nombreuses références, nombreuses contributions), ne placer des fournisseurs en situation de monopole (contrats cadres) qu’à condition de préparer le changement futur de fournisseur (si les conditions contractuelles ne sont pas respectées ou bien, tout simplement, à l’issue du contrat), rester systématiquement dans une position de fermier (« je cultive ma terre ») plutôt que de métayer (« je cultive la terre du propriétaire », en l’occurence celle de mon fournisseur), piloter les choix logiciels par les principes architecturaux (couplage faible et tardif, respect des standards)
   • open sourcer l’architecture : c’est-à-dire externaliser les coûts de développement auprès de tiers par le biais d’une redistribution sous lience « open source » des adaptations spécifiques et développements maison, de manière à annuler les coûts d’investissements (pas de coûts de licences à l’achat) et de manière à mutualiser les coûts de développement et de maintenance avec des tiers (autres entreprises utilisatrices, sociétés de services informatiques, informaticiens indépendants) ; pour cela, redistribuer systématiquement les développements maison non stratégiques (non liés à un avantage concurrentiel certain) sous licence « open source »
   • préférer les choix « juste-assez » aux choix « idéaux » (« le mieux est l’ennemi du bien ») : pour évaluer la disponibilité en compétences informatiques nécessaires à l’exploitation et la maintenance de la technologie nouvellement acquise, ne pas confondre la disponibilité suffisante de compétences et la disponibilité maximale de compétences ; appuyer le choix de nouvelles technologies à acquérir non pas sur leur degré absolu de sophistication (ce qui se paie en compétences d’exploitation) et de popularité médiatique (ce qui se paie en coût de licences et de support) mais sur l’adéquation entre celle-ci et le besoin qu’on en a ; si votre système d’information est urbanisé, préférer l’approche « citadine » à l’approche « 4×4 »