TOGAF & Application downsizing

Contexte

Basé sur une de mes missions passées, voici un aperçu de la manière dont le business peut considérer l’IT et comment la vision TOGAF peut les aider tous les deux.

Appelons mon client La Compagnie.

La Compagnie a lancé un programme visant à réduire les coûts opérationnels de son SI et à quitter ses environnements propriétaires pour adopter des standards ouverts. Une des étapes clés du programme est de downsizer une énorme Application métier au cœur du SI de z/OZ vers Linux. Je mène une étude de cadrage pour aider La Compagnie à élaborer des scénarios de downsizing comprenant des objectifs à court et moyen terme.
Exemple d’objectif à court terme : se débarrasser de z/OS le plus vite possible.
Exemple d’objectif à moyen terme : utiliser des technologies open source.

TOGAF ADM et cadrage d’un downsizing

Une première question se pose : est-ce que le cycle Architecture Development Method (ADM) de TOGAF est applicable à un downsizing ? Ma réponse courte : Oui !
Même si de prime abord le sujet « downsizing » paraît clairement concerner uniquement des questions IT, on peut au moins utiliser TOGAF comme guide pour poser le problème dans un contexte plus large de transformation du SI.

Et par exemple représenter avec l’ADM les limites de l’exercice « élaborer des scénarios » :

TOGAF for application downsizing

En allant plus loin, et en suivant un procédé équivalent à celui de « TOGAF appliqué à TOGAF » (voir TOGAF 9.1 part VII), on peut tout à fait envisager la problématique d’un downsizing avec les 4 points de vue architecturaux de TOGAF :

• Business = les conséquences pour les équipes IT et leurs processus actuels des exigences IT pour l’architecture cible IT
• Data = les composants et données applicatives (code source code, paramètres applicatifs, etc.) et les composants IT d’exploitation (systèmes d’exploitation, outils de monitoring, etc.). Par contre les « données métier » ne sont pas à traiter comme des « Data ». D’ailleurs sur ce projet elles n’étaient pas du tout concernées puisque la migration/downsizing des données avait déjà eu lieu
• Application = les nouveaux outils et processus de gestion du cycle de vie applicatif – dont ceux concernant la maintenance de l’existant
• Technology = les technologies de la cible = nouveaux langages de programmation, nouveaux outils de développement, nouveaux systèmes d’exploitation, etc.

Si on peut facilement faire cet exercice intellectuel de mapping, c’est une autre paire de manches que de vendre TOGAF en tant que méthodologie de cadrage !

TOGAF pour les cas hors préoccupation métier

C’est en écrivant cet article, a posteriori, que j’ai réalisé que la manière dont j’avais mené l’étude de cadrage avait suivi globalement un pattern ADM TOGAF.
Le principal bénéfice a été d’arriver à obtenir une expression formelle de toutes les attentes et de toutes les craintes des équipes IT de La Compagnie. Aussi bien vis à vis de la cible que de la trajectoire du processus de downsizing. Et aussi d’avoir fait apparaître explicitement des nuances amenant à différencier les trajectoires de certains ensembles de composants source.

Cependant, la question induite par cet article est : est qu’un processus de downsizing qui est normalement iso-business et iso-fonctionnel a, ou devrait avoir, un impact sur le métier ? Une réponse est : les spécifications de la cible architecturale doivent, a minima, ne pas introduire de diminution de capacité pour l’IT vis à vis de la roadmap métier.

Finalement, les attentes métier

J’ai donc posé la question de la roadmap métier aux représentants IT : « Qu’est-ce que le métier dit ou attend de l’Application ? ». J’ai eu trois réponses :

• Exigence 1 : une partie des managers métier aimeraient avoir un progiciel du marché plutôt qu’une application développée en interne
• Exigence 2 : tous les managers métier aimeraient pouvoir diminuer le cout et le temps de formation des équipes de vente
• Exigence 3 : une partie des managers métiers aimeraient avoir un meilleur time to market lorsque le marché évolue puisque les concurrents sont généralement plus rapide que La Compagnie à revoir leur offre

Dans quelle mesure une opération de downsizing peu-elle aider à répondre à ces exigences métier stratégiques ?

Exigence 1 : Progiciel

Manifestement l’exigence 1… n’est pas une exigence !

C’est éventuellement une solution à de réelles exigences qui seraient du type réduction des coûts d’opération IT, amélioration du time to market, etc. Mais en l’état ça ne saurait être accepté comme une exigence métier en tant que telle. Et il faut inviter le métier à être plus précis dans sa demande et ses motivations.

Exigence 2 : Coûts de formation

L’exigence 2 est vraiment une exigence métier. L’Application dispose d’un canal B2C par lequel les clients peuvent acheter des produits directement sur un portail web. Même un nouveau client, habitué à naviguer sur internet, peut y acheter un produit en quelques minutes. Il est donc légitime de se demander pourquoi un vendeur de La Compagnie a besoin de plusieurs semaines de formation avant de pouvoir arriver au même résultat.

Au même résultat ? Vraiment ? Pas si sûr. Il y a probablement des commandes groupées qui nécessite un process plus complexe que ce qu’on peut réaliser sur un portail web. Et si on regarde les statistiques de ventes on peut certainement constater qu’il y a en fait différentes catégories de vendeurs, et que toutes n’ont pas forcément besoin de la même formation.

Dans tout les cas, cette exigence devrait amener La Compagnie à envisager un autre projet de « transformation » centré sur les processus de vente et l’ergonomie du poste de vente. Quel est le rapport entre ce projet de transformation métier et le projet de downsizing ? La cible du downsizing doit être de renforcer les principes SOA déjà adoptés dans La Compagnie, et également donner une forte priorité aux technologies cibles qui permettront de doter les applications d’interfaces homme machine d’une très grande flexibilité. Mais le « nouveau poste de vente » est clairement un projet différent. Ne serait-ce qu’à cause du très important travail préparatoire à mener avec les utilisateurs métier sur leurs attentes. Et qui sera rendu possible grâce au travail préparatoire sur le technologie dans le cadre du downsizing.

Exigence 3 : Time to market

L’exigence ressemble également à une exigence métier… mais c’est plus compliqué que ça en a l’air !

Version courte :
La Compagnie se différencie de ses compétiteurs, entre autres, par son approche spécifique de packaging de produits combinés pour adresser les demandes explicites et anticiper les souhaits probables de ses clients. Cette approche procure des avantages mais aussi des coûts supplémentaires.
La valeur ajoutée mise dans ce packaging de produits induit un temps plus long pour imaginer un nouveau package clés en mains, le spécifier et le mettre en oeuvre. Donc d’un point de vue purement « time to market » La Compagnie sera généralement toujours plus lente à réagir que ses concurrents qui ne réalisent pas ce packaging. Et ce quelle que soit la technologie de l’Application.

En y réfléchissant à deux fois, La Compagnie et ses compétiteurs ne vendent pas tout à fait la même chose finalement. Donc le point clé ici n’est pas tant d’améliorer la capacité de l’IT que de revoir ou d’améliorer les processus métier de création de produit. Et c’est à faire, bien sûr, avant de s’intéresser à la manière de l’implémenter dans le SI !

TOGAF adresse les questions d’Architecture

En conclusion, mais cela me reste à vérifier sur d’autres cas, je crois que TOGAF peut aider à mener des projets de downsizing d’architecture. Des deux côtés : en aidant à organiser la façon d’adresser les attentes IT, et en aidant à faire le tri dans les attentes et contraintes business.
Ces deux côtés sont finalement les deux faces de ce qu’est vraiment au fond l’Architecture d’Entreprise…