Sous les applications neuves, dont vous êtes fiers, se cachent certainement les couches de services ou d'applications héritées du passé. Faut-il tout raser pour autant ? Certainement pas, car c'est dans la persévérance et la vision que l'on réalise les plus grandes œuvres, surtout si on y laisse une part au hasard et à l'innovation.
C'est bien d'urbanisation du SI dont GreenSI veut vous parler.
Urbanisation. Un terme emprunté par les informaticiens aux architectes de la ville pour décrire le SI en quartiers, zones et ilots, et préparer son évolution harmonieuse et coordonnée.Un art "noble" que les architectes d'entreprises essayent de pratiquer avec chaque nouveau projet qui se présente à leur porte, pour que ces projets s'inscrivent dans l'existant et permettent aussi de préparer le futur du système d'information de l'entreprise.
Des architectes qui parfois n'ont qu'un seul regret, celui ne pas avoir vécu au temps du Baron Haussmann préfet du département de la Seine (devenu l'Ile de France), quand de façon autoritaire il a dirigé la rénovation de Paris sous le Second Empire (1854-58) et s'est imposé comme une des figures de l'urbanisme moderne.
C'est en perçant les grandes avenues de la capitale, et notamment les Champs Elysées, que Paris est devenue une ville plus étalée, avec une meilleure circulation de l'air (question d'hygiène à l'époque) qui pouvait développer des transports en commun... et y faire envoyer la garde à cheval réprimer les éventuelles manifestations du peuple.
Une image qui reste encore un idéal dans la tête de beaucoup d'architectes du SI, que l'on retrouve régulièrement formalisée dans leurs "Powerpoint". Tout y est harmonieusement connecté.
Mais attention, l'urbanisation n'est pas neutre. Ces rénovations ont entraîné à Paris, quelques années plus tard, la hausse des loyers, l'émergence des zones de "beaux quartiers" et le déplacement des populations plus modestes vers l'Est. Les nouveaux arrivants ne pouvant plus prétendre aux prix du centre rénové.
Une question à méditer aussi à la DSI quand on impose a une nouvelle application des contraintes de sécurité, de raccordement aux référentiels, ... qu'elle ne peut tout simplement pas se payer parfois avec les budgets qui lui ont été alloués. Ou pour le dire différemment, qui démontre à chaque projet qu'on sait raccorder une nouvelle application au SI (en lui consacrant une bonne partie du budget), au lieu de se concentrer sur l'essentiel (par essence): démontrer l'intérêt de la fonctionnalité pour les utilisateurs et la meilleure façon de la réaliser pour leur adhésion.
Ne devrait-on pas avoir une "zone/quartier de création d'applications" ? Une zone ou ne préjuge pas à l'avance des besoins futurs que l'on ne connait pas. Car l'urbanisation sait prévoir des zones à développer, mais elle trop vite les organiser en fonction de données ou de risques futurs.
Avoir un "incubateur" comme diraient ceux engagés dans l'innovation, pour faire ses preuves et tester son modèle, avant de tout de suite devoir être totalement aligné avec les lignes de construction de l'ensemble du SI et en adopter le modèle de couts des services mutualisés qu'il sous-tend ? C'est, pour GreenSI, ce manque qui explique en partie que certains projets soient réalisés en dehors de la DSI (l'autre explication étant la recherche de la pluridisciplinarité des équipes et les démarches agiles ou de design trouvées à l'extérieur ).
Et puis Rome ne s'est pas faite en un jour.
L'idée souvent véhiculée dans les divers comités techniques, c'est qu'une fois le prochain projet d'architecture structurant posé tout serait pour le mieux dans le meilleur des mondes. C'est certainement un idéal enviable, ou une bouée de sauvetage intellectuelle, pour ceux qui comme le Baron Haussmann aspirent à une "hygiène du SI" avec une place pour chaque chose et toutes les choses à leur place.
Mais les grands projets sans valeur directe pour le client ont de plus en plus de mal à trouver un financement de la DG. Ils sont lents à partir et n'avance pas toujours très vite.
Or la réalité de l'entreprise et de son environnement est tout autre. Fusions, acquisitions, nouveaux services, cycles technologiques plus courts,... les raisons ne manquent pas pour générer de l'hétérogénéité permanente dans l'entreprise.
Enfin, toutes les décisions ne sont plus prises par l'entreprise seule, notamment dans les nouveaux ecosystèmes digitaux. Il manque donc certainement beaucoup de monde à la table des comités techniques pour que les décisions prises soient pérennes.
Hétérogénéité structurelle, temps ressource critique, ecosystèmes complexes, le foisonnement existera donc toujours dans le SI, quoi que la gouvernance en pense... ou en rêve !
Par exemple pour faire évoluer les business modèles avant de mieux structurer et industrialiser les services numériques qui finalement auront démontré leur pérennité. Tout n'a pas besoin, tout de suite, d'être raccordé au gaz, à l'eau, aux ordures ménagères et à l'électricité !
Et puis en 2016 c'est toute l'entreprise qui devient agile. Pas uniquement les projets pour les clients qui mettent en place des sites internet.
Toutes les Directions porteront progressivement ces nouveaux projets de services disruptifs, à tester avant industrialisation. Que ce soit dans les RH avec des services personnalisés aux employés, aux achats avec les fournisseurs et pourquoi pas de nouvelles applications mobiles pour les actionnaires ou les associations influentes.
La question posée par GreenSI est donc finalement toute simple : l'urbanisation est t-elle compatible avec l'agilité ?
Doit-on privilégier les grands plans ou les constructions itératives ?
L'urbanisation est-elle du côte du problème ou du côté de la solution ?
Une question importante à l'ère de la transformation digitale où la contrainte d'évolution du SI est forte. Même quand cette transformation n'est pas pilotée par la DSI mais par un CDO - Chief Digital Officer - rattaché à la DG.
C'est pourtant une question paradoxale. Car pour GreenSI, l'urbanisation est justement ce qui permet au SI de devenir agile. Le stade ultime, après les applications et les données, étant l'urbanisation des APIs souvent discutées dans ce blog, qui permet par exemple à Facebook de croître vite en fonctionnalités et d'animer une communauté de développeurs à l'échelle mondiale.
Et à l'inverse il y a peu d'agilité sans urbanisation avec des progiciels monoblocs interfacés par exemple.
C'est donc plus la démarche d'urbanisation qui est en question aujourd'hui, que l'urbanisation elle même, dans un monde économique où les cycles se raccourcissent et où l'innovation est une exigence. L' "Haussemanisation" ne sera plus tolérée, que ponctuellement, quand l'entreprise sera au pied du mur... ou du dépôt de bilan.
Les architectes vont devoir imaginer un modèle où l'urbanisation est à la fois une force et un accélérateur, qui saura prendre en compte le cycle de développement des applications, et non pas uniquement un ensemble de règles figées dans le temps et pour tout le monde.
Il est donc temps de quitter le Paris du XIXe et la Rome antique de la vieille Europe, qui ont oublié depuis longtemps l'hyper-croissance, pour se tourner vers des villes plus "vivantes" en terme d'évolution, comme celles de l'Amérique du Sud.
Des villes qui savent gérer une croissance très forte, souvent suite à un exode rural massif des populations, comme Sao Paulo au Brésil par exemple.
Des villes où les nouvelles populations qui arrivent ne sont pas aussi riches que celles qui sont déjà installées, pour ne pas dire sont pauvres, ce qui peut choquer, mais finalement reflète la réalité des applications du SI. On met parfois beaucoup plus d'argent dans l'entretien de systèmes anciens que dans le lancement de nouveaux systèmes. Les riches ce sont les applications bien installées qui vivent du confort des mises à jour règlementaires. Gardez-le en tête !
Et si les architectes SI intégraient le "bidonville" ou la "favelas" comme une forme naturelle d'évolution du SI ? Car si on met de côté le modèle social et la connotation négative des termes, ils reflètent une capacité d'évolution nouvelle de la ville.
Et par là même reconnaître que l'accès à l'ensemble des services n'est pas atteignable, en délais ou en coût, par toutes les initiatives du SI. Car c'est bien ce qui permet à ces mégapoles de se développer rapidement, beaucoup moins les plans des urbanistes. Ces derniers arrivent ensuite quand il faut rationaliser ou légaliser les choses :
- Le bidonville est une forme de production de logements populaires, dont le raccordement à la ville se fait à moindre cout. Tout le monde n'a pas au départ accès à l'ensemble des services de la ville. Mais surtout la prise de décision et la construction est fortement décentralisée, avec des matériaux légers, et permet une vitesse de développement rapide.
- L'alternative au bidonville étant l’autoconstruction périphérique avec des artisans embauchés en dehors des circuits marchands formels. C'est rarement très légal en terme de construction et de propriété, mais régulièrement des campagnes enregistrent officiellement ces nouvelles habitations. C'est ce qui se passe dans l'entreprise quand les agences marketing, par exemple, construisent des applications sans passer par la DSI ou quand une direction métier met en place ses propres applications en SaaS.
Ces nouveaux quartiers portent certainement les germes de nombreuses "non conformités intellectuelles" dans les méthodes et dans la planification. Mais ils sont aussi la source de nouvelles innovations, de la vitesse d'adaptation et de l'agilité qui pourra peut être ensuite renouveler tout le SI, au moins les zones qui leur sont limitrophes avec qui ils échangent.
L'architecture du SI doit donc être une démarche bienveillante, transverse à l'entreprise, dont la mission déborde largement de le périmètre de la DSI quand une transformation numérique engagée.
