15.1.07

Les urbanistes ? Ils reviennent et ils sont très contents

En 2004, nous nous étions penchés, chez Unilog Management, sur la revalorisation de la fonction de l'urbaniste de système d'information. Nous observions que les travaux d'urbanisme n'étaient pas toujours utilisés, voire, malheureusement, utiles. La mission de l'urbaniste apparaissait dans certains cas déconnectée des préoccupations du commun des mortels, en apesanteur (règles d'urbanisme mal vécues car jamais au bon moment et rarement pour aider), qui plus est parfois teintée d'une forme d'autoritarisme bureaucratique qui ne rendait guère sympathique cette caste d'intouchables, protégée mais sans réel pouvoir et finalement sans écoute. Coûteux et sans pression du resultat, voilà quelle était l'opinion de l'homme de la rue IT en 2003 à ce sujet. Alors pourquoi vouloir ainsi prestement "revaloriser" une fonction en nette perte de vitesse ?

Parce qu'à ce moment-là, en 2004, en pleine euphorie EAI (flux de données transversaux), avec l'émergence des SOA (services mutualisés), avec la tendance au MDA (Model-Driven Architecture) qui se dessinait dans les solutions, il nous a semblé qu'au contraire, l'urbaniste était un témoin privilégié du système d'information. A la croisée du métier et de la technologie. il occupe une place de choix, unique. Disposant d'une vision réellement transversale, il est l'élément de gouvernance qui maintient la cohérence du système d'information.

Nous avons ainsi créé une offre d'Accostage à l'urbanisation, destinée à rapprocher les décisions de l'urbaniste du théâtre des opérations. Cette offre n'a jamais réellement vu le jour. En effet, nous ne faisions qu'anticiper, sans le savoir, ce que les Architectures Orientées Services allaient confirmer.

Dans un contexte SOA, on ne travaille plus uniquement sur des projets, mais aussi, et de plus en plus, sur des programmes. Sur ces programmes, une vision transversale est indispensable : pour délivrer la réutilisation et la mutualisation attendues, pour définir la granularité de services qui mène à l'état stable, pour définir les responsabilités sur les données référentielles, sur les services, les échanges et les processus transversaux. L'urbaniste est désormais directement embarqué dans les équipes projet (programme) et responsabilisé. Sa contribution est directement perceptible, concrète, appliquée au contexte, et capitale puisqu'intervenant en amont de bon nombre de décisions. Et il reste le mieux placé pour être le correspondant des urbanistes "centraux" et travailler parallèlement au maintien de la cohérence.

Je dirai même, et c'était l'un des objectifs de l'accostage, que le centre peut directement bénéficier des apports du terrain pour remodeler et ajuster sa conception, là où les précédents modèles de gouvernance étaient plutôt monodirectionnels et "météoriques" (en provenance unique d'un ciel qui vous tombait alors sur la tête).

Contrairement à ce que prétendent ceux qui crient à la réappropriation de la SOA par des cabinets avides d'opacité et de profit, les SOA ne sont pas le théâtre d'un putsch des urbanistes. Elles sont le théâtre de leur retour en grâce.

5.1.07

L'état SOA stable au service du ROI

Lu ce jour sur la lettre IT2IT publiée par BEA.

« Les initiatives SOA sont généralement motivées par le besoin de réaliser, de soutenir et de gérer des changements plus fréquents (et souvent imprévus) », indique un rapport Gartner de mai 2006 intitulé Key Metrics Can Help Justify Investments in SOA (Les indicateurs clés peuvent permettre de justifier l'investissement dans la SOA).

Complètement d'accord avec cela.

En effet, concrètement, dans quel sens souffle le vent de l'industrie et de la relation métier/IT ? Vers des cycles de livraison d'application de plus en plus courts (pour gérer ce fameux changement permanent dont on vous rebat constamment les oreilles).
Gartner estime que d'ici quelques années, le temps nécessaire pour livrer une nouvelle fonctionnalité se comptera en jours. Fumisterie ? Peut-être.

Ou peut-être pas ! Ce temps s'est déjà considérablement réduit. Le temps moyen d'un premier delivery SOA est de 3 à 4 mois pour les grands projets. Et ce delivery "n'est qu'un" socle à partir duquel de nouvelles demandes métier pourront être intégrées encore plus rapidement, sur la base de la réutilisation des services, des technologies et des pratiques.

Et là est toute l'essence de SOA : quel est le socle de services qui me permet de décrire un état stable de mon système d'information, à partir duquel toute nouvelle demande pourra être intégrée rapidement et à moindre coût (cela revient notamment à poser la question de la granularité des services et des liens avec les référentiels de données, mais c'est une autre histoire) ? C'est précisément ce que nous faisons chez nos clients : rechercher l'état stable, la bonne granularité qui assure l'évolutivité. On voit immédiatement les liens avec l'architecture d'entreprise et avec des initiatives telles que Praxeme (http://praxime.club-blog.fr/praxime/2006/05/praxeme_et_soa.html).

Ce qui cloche dans l'article du Gartner, en revanche, c'est sa conclusion.

« Par conséquent, mesurer les avantages de la SOA par le biais d'approches traditionnelles du ROI ne suffit pas (c'est même impossible dans certains cas) car le projet reste une cible mobile. »

Je ne sais pas ce qu'est une approche traditionnelle du ROI. Par contre, je pense qu'une fois l'état stable atteint, le projet ne constitue pas une cible mobile mais bien un socle à partir duquel il devient très aidée de chiffrer les nouvelles demandes et les bénéfices à en attendre. C'est tout l'objet des études de cadrage que d'arriver à déterminer en amont ces éléments essentiels.

3.1.07

Le cadrage SOA : un vent qui souffle

Bienvenue en 2007 et meilleurs voeux à tous.

Cette année voit se lancer un certain nombre d'études de cadrage SOA chez des entreprises de tous les secteurs. Nous avons passé la période des fêtes à répondre à de nombreux appels d'offres envoyés courant décembre. Pour ma part, j'ai répondu à quatre d'entre eux : deux pures missions de cadrgae SOA et deux mixtes (système d'échange d'entreprise incluant SOA). Même si nous aurions préféré passer davantage de temps en agapes (quoique, la saturation guette), ces multiples sollicitations témoignent de bien plus qu'un simple intérêt. Il se confirme ce que nous avions tous ressenti à la rentrée 2006 : les opérations sont lancées. Le SOA est peut-être bien ce 'chantier ouvert pour 10 ans" dont parle l'un des derniers numéros de 01 DSI.

Que recherchent les entreprises au travers de ces études ? Fondamentalement, deux choses, toujours plus ou moins les mêmes :
- SOA : pour quoi faire ? Pour quels bénéfices ?
- Quels impacts sur mon système d'information et sur l'organisation de ma DSI ?



On constate que ce sont des drivers métier qui pilotent la démarche : comment accroître les ventes sur un site e-Commerce ? Comment intégrer rapidement et à peu de frais un nouveau fournisseur ou un nouveau produit ? Comment fournir à mes client un nouveau service, de façon homogène à l'international ? Autant de drivers qui impliquent dans des études de cadrage parfois remises aux dirigeants (pas seulement IT) des entreprises d'évaluer le ROI. Mais ce ne sont pas les seuls. Le passage vers les NSSI se fait parfois à marche forcée.
Ainsi, l'arrêt du support de versions d'EAI à court/moyen terme (18 mois) par certains éditeurs du marché pousse les entreprises vers la migration obligée. Et cette migration vers les nouvelles versions des produits passe obligatoirement par la case SOA, structure de base de ces nouvelles constructions. Ce qui peut s'avérer gênant lorsque l'on constate que les produits ne sont pas encore tout à fait prêts - ou en tout cas, que l'avance prise par le marketing sur la technique dépasse les 6 mois traditionnellement admis.
On pourra alors réfléchir brièvement sur les bienfaits de l'innovation quand celle-ci est simultanément imparfaite et dictée. C'est toute la singularité de notre industrie que de voir les responsables Innovation si peu libres de leurs choix, voire otage. Or cette fonction, autrefois déconsidérée, tend à revenir fortement au goût du jour dans l'rganigramme des DSI (c'est d'ailleurs l'une des conclusions de notre prochain livre blanc qui sort le 22 janvier). On ne sera alors pas surpris de constater que certaines migrations forcées conduisent des entreprises à adjoindre à leurs études de cadrage une intéressante phase d'étude de choix de produit. Une façon comme une autre de se libérer de certains pesants carcans.

Libellés : , ,