Web oriented enterprises

Beaucoup de théoriciens, abondamment relayés par la littérature de référence sur les sujets d'urbanisation, démontrent par A+B que la réussite des projets d'urbanisaiton repose essentiellement sur l'adhésion du métier; et plus précisément sur un respect plus ou moins strict d'une démarche top down: en partant de la stratégie de l'entreprise on dessine une architecture business qui donne lieu à une architecture fonctionnelle et applicative (information system architecture des anglo saxon) puis à une architecture technique.

Cette belle théorie fonctionne bien sur le papier et effectivement elle présente une bonne démarche théorique, que tout architecte se doit de conserver en arrière pensée. Reste que la pratique vient perturber la belle mécanique.

Premiérement l'architecture technique est de fait assez peu décrite dans les ouvrages consacrés aux sujets de l'urbanisation et de l'architecture d'entreprise. Or cette architecture technique joue un rôle crucial: une infrastructure (j'entends par infrastructure l'ensemble machines, réseaux et équipements et OS / voire hébergement et SGBD) mal définie conduit en général à la catastrophe. Soit le projet d'urbanisation est impacté dans sa trajectoire (difficultés sur les plateformes de qualification, temps d'assemblage trop longs,...), soit et c'est encore pire, le service rendu ne respecte pas en production le contrat de service défini: qualité de service, scalabilité, etc.

D'autre part, et dans un tout autre ordre d'idée, la démarche d'urbanisation se heurte parfois à des difficultés de passage d'une couche à une autre. Si la stratégie de l'entreprise est en général (et c'est heureux !) clairement définie, la définition des axes stratégiques en projets métiers concrets prend parfois plus de temps... ce qui grippe notre belle mécanique d'urbanisation ! Le temps nécessaire à la formalisation des besoins métiers (la liste de nos exigences) puis leur traduction en architectures applicatives et référentiels de données (ou en architecture fonctionnelle) peut se révéler long. Et pendant ce temps, le SI existant continue de vivre, avec ses coûts et ses faiblesses.

Pour répondre à ces constatations, une démarche plus itérative peut se mettre en place. L'urbanisation peut se traiter dans un premier temps par un prisme technique, par des projets qui permettront de donner du souffle au SI dans l'attente de projets métiers formalisés. Ces projets techniques permettront aussi de continuer à développer de nouvelles fonctionnalités sur le SI actuel (pendant les travaux, le business continue...).

Quelques exemples d'axes d'amélioration purement technos qui peuvent donner de l'air à une DSI:

• renouveler une partie de son matériel
• changer de socle applicatif (OS, frameworks, serveurs d'application...)
• préparer son infra à de nouvelles évolutions (réseaux, machines, hébergeur)
• mettre en place des méthodologies nouvelles: agilité (XP, Scrum), intégration continue, TDD/TDR

Surtout n'ayons pas peur de faire des choix qui seront remis en question lorsque le programme d'urbanisaiton sera plus avancé, il coute parfois plus cher de faire du "jetable" que de ne rien faire. Surtout n'ayons pas peur de faire des projets IT, ils ont aussi des bénéfices à apporter à l'entreprise Surtout n'oublions pas de travailler en paralléle avec les métiers pour clarifier les besoins

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.

Un petit billet inspiré par ma certification TOGAF: l'architecture d'entreprise redonne ses lettres de noblesse à la gestion des exigences.

Dans TOGAF, le processus de gestion des exigences est placé au coeur du framework: chaque phase est réliée au processus de gestion des exigences dans le référentiel d'architecture d'entreprise.

L'enjeu est de relier les exigences du référentiel aux solutions qui sont implémentées.

Le recueil des exigences (et attention, il s'agit bien à la fois des exigences business mais aussi bien entendu de toutes autres formes d'exigences sur l'architecture d'entreprise) permet non seulement de concevoir la baseline, mais favorise aussi l'analyse du différentiel entre la baseline cible et celle en cours.

Au delà des étapes de conception, l'analyse d'écart continue sur les phases d'implémentation et d'exploitation pour mesurer la différence entre le souhaité et le réalisé.

La principale difficulté rencontrée est l'hétérogénéité des exigences formulées, que ce soit dans leur granularité ou dans leur mode d'expression (outillage). La nécessité de confier le référentiel d'exigences à la cellule en charge de l'architecure d'entreprise pour en assurer la cohérence fait alors complétement sens.

Je vous conseille d'ajouter dans vos signets le site suivant: http://highscalability.com/

Spécialisé dans les architectures des sites internet à forte audience (et notamment avec un focus sur la scalabilité comme son nom l'indique), il regorge d'informations pratiques et de retours d'expérience.

On y trouve notamment: un descriptif de l'architecture d'Amazon ici des explications sur l'évolution dans le temps de l'architecture d'ebay là