Web oriented enterprises

Simple

Une architecture doit être simple. Pourquoi ? Pour faciliter la maintenance, l'évolutivité Pour maitriser son système d'information (connaissance, coûts, cycle de vie...)

Scalable

Votre entreprise ambitionne de croitre, de développer ses activités, d'augmenter sa base client. Votre SI doit être capable de s'adapter à ces changements Ceci est d'autant plus vrai sur Internet ou votre architecture sera confrontée à des évolutions d'audience parfois exponentielles (voir les exemples récents de Facebook, Twitter ou plus près de nous Dailymotion)

Solide

La robustesse doit être votre première préoccupation. Votre mission est d'assurer une bonne qualité de service à vos clients, en respectant vos engagements (SLA). Cela implique d'adapter votre architecture avec le bon niveau de redondance, des sauvegardes, un plan de reprise d'activités... Tester la tenue en charge, mais aussi la tenue dans le temps (le syndrome des fuites mémoires !) est primordial

Supervisée

Pour pouvoir vérifier que votre système d'informations a les qualités requises vous devez pouvoir l'oscutler sous toutes ses formes: supervision technique et applicative supervision avec une vision utilisateur mais aussi en ajoutant la supervision financière (controle de gestion)

Pas si simple de monter des plateformes de service !

Après Apple qui avait rencontré de gos problèmes lors du lancement de son service MobileMe, c'est aujourd'hui Nokia qui rencontre de sérieuse difficultés dans le lancement de son OVI store.

Que conclure de ces ratés, surprenants au premier abord de la part de géants du secteur comme Apple et Microsoft ?

Premièrement, qu'un changement business (Offir un nouveau service de synchronisation pour Apple, lancer un marketplace pour Nokia) a des conséquences parfois plus fortes qu'on ne l'imagine au premier abord.

Ensuite, que les technologies internet, qui ont apporté simplification et agilité au système d'informations, restent des technologies difficiles à maitriser. Les techniques du type webservices sont assez éloignées de la conception de hardware (mac chez Apple, téléphones chez Nokia) ou d'une activité d'éditeur de logiciel (dont les OS d'Apple et Nokia tous deux plutôt convaicants tant sur l'usuabilité que sur la qualité).

Enfin, qu'Internet change une nouvelle fois la donne. Certes Internet offre un accès à des milliions de consommateurs et une forte visibiltié, mais en contrepartie les plateformes doivent être capbables d'encaisser des charges conséquentes si le produit est une réussite sur le plan de l'adoption. Performance technique, mais aussi (et c'est beaucoup plus difficile à prévoir et à tester) perforamnce fonctionnelle: assurer une expérience utilisatuer à tous sans distinction.

L'architecte d'entreprise voit son importance confirmée: en travaillent sur les gap analysis et les impacts, il va permettre de montrer les conséquences d'une évolution de l'architecture business sur les autres couches, en mettant en avant les zones sur lesquels les tests devront se concentrer.

J'aurais d'ailleurs prochainement l'occasion de vous parler des tests et de leur importance dans le coût et l'agilité du SI.

La problèmatique

L'architecte d'entreprise a le plus souvent une position inconfortable dans l'entreprise. L'organisation de cellules d'archtitecture et/ou d'urbanisme transverse ont le tort d'éloigner l'architecte du métier et de l'IT, donc des projets. Il s'ensuit l'impression (le plus souvent exprimée d'ailleurs !) que l'architecte d'entreprise est dans sa tour d'ivoire, loin des contraintes opérationnelles.

Répondre par la communication

Une partie de la solution consiste à éduquer sur le rôle et les apports de l'architecture d'entreprise dans le développement de ladite entreprise. La revue d'architecture d'entreprise est un outil très adapté à cette communication. Togaf précise à ce titre l'importance de la gouvernance dans l'architecture.

La revue d'architecture doit être l'occasion de réunir les décideurs (la direction de l'entreprise) et les architectes. Il s'agit bien de valider les orientations structurantes de l'organisation de l'entreprise pour l'aligner avec sa stratégie, ce qui nécessite des arbitrages de haut niveau. Les actionnaires et/ou le conseil d'administration peuvent aussi être amenés à s'assurer de la qualité de l'architecture retenue.

Un exemple d'ordre du jour d'une revue d'architecture:

• Présentation de la vision d’architecture d'entreprise cible
• Validation des principes directeurs d’évolution du SI
• Revue des impacts sur les projets / prises de décisions

Etre apporteur de solutions et non un frein aux projets

L'architecte doit être considéré comme facilitateur et non comme un empêcheur de tourner en rond. Si l'architecte est vu comme un frein, il court le risque de voir des projets se développer hors de sa vue, et donc de perdre petit à petit la connaissance de son patrimoine. Au contraire si les projets trouvent dans le continuum des outils leur permettant d'avancer plus rapidement, plus efficacement; alors l'architecte d'entreprise a gagné son pari et renforcé sa crédibilité.

Suivre les évolutions dans l'opérationnel

TOGAF est clair là dessus, au contraire d'autres frameworks ou ensembles de bonnes pratiques, TOGAF insiste sur l'importance de la gouvernance de la réalisation. L'architecte doit

• s’assurer que les projets de réalisation et les autres projets se conforment àl’architecture définie (phase G de l'ADM).
• Mettre en place ou s'assurer de la mise en place de la gestion des changements (sur toutes les couches) (Phase H de l'ADM)

En conclusion, l'architecte d'entrprise doit s'ouvrir à l'organisation et prendre soin d'expliquer son action. Il est au service des projets et non le gardien du temple.