XaaS n’est pas tout – et il n’est pas réparable

C’est, malheureusement, défini comme« tout service informatique fourni via Internet et payé dans le cadre d’un modèle de consommation flexible plutôt que sous la forme d’un achat initial ou d’une licence ».

Faites quelques recherches sur XaaS sur Google et vous trouverez beaucoup de jaillissements répétitifs, mais pour les plus jaunâtres d’entre nous, il est difficile d’éviter de conclure que XaaS est, en fait, un peu plus que l’intersection de l’informatique basée sur le cloud et de la rétrofacturation.

Et pourtant, dans toutes les discussions, le fait que XaaS est le résultat logique de l’architecture orientée services (SOA) semble avoir été ignoré.

Il est également étrange que XaaS exclut la partie de « tout » que les non-initiés pourraient considérer comme l’ensemble de services le plus important fourni par l’informatique, à savoir tout ce que les analystes commerciaux, les consultants internes en informatique et le personnel de développement et de support d’applications font pour gagner leur vie.

Ce qui, je suppose, signifie que « Tout » en tant que service est vraiment « Quelques choses en tant que service » (AFTaaS), ou peut-être « Tout sauf l’effort en tant que service » (EEEaaS).

Ce que XaaS devrait vraiment signifier

Ce à quoi XaaS devrait se référer est l’application logique des principes SOA à presque tout ce qui se fait dans l’entreprise.

Il devrait, par exemple, inclure ce que les entreprises de services appellent l’externalisation des processus métier (BPO). Cela devrait également inclure ce que nous pourrions appeler « l’internalisation des processus métier » mais que nous appelons généralement les « services partagés ».

Travaillez en tant que service (WaaS), n’importe qui ?

C’est-à-dire que XaaS devrait inclure non seulement la technologie elle-même, mais également les résultats commerciaux pris en charge par la technologie.

Mais pas qui paie et comment. L’architecture concerne la façon dont les solutions sont assemblées, pas leur financement.

« Work as a Service » : les services partagés en tant qu’architecture

Voici la chose : BPO n’est pas nouveau et a fait du paiement à la boisson pour le travail une option depuis sa création.

Et tout comme l’informatique peut fournir le SaaS à ses utilisateurs professionnels, soit par le biais d’un cloud commercial, soit par le biais d’applications internes, les fonctions métier peuvent mettre leurs services à la disposition du reste de l’entreprise en s’organisant en tant que services partagés internes, ou par l’utilisation d’un fournisseur BPO.

Mais un groupe de services partagés n’est pas comme un BPO uniquement interne. La différence entre eux ? Contractualiser avec un fournisseur de BPO n’est pas une décision architecturale. L’organisation en tant que service partagé interne l’est assurément.

Comme la plupart des autres sous-traitants, la décision d’engager un fournisseur de BPO est généralement un aveu d’échec de la gestion. Il transfère la responsabilité d’une fonction commerciale que la direction interne ne pouvait pas superviser correctement à un contrat.

Cependant, cela ne signifie pas toujours que l’organisation en tant que collection de services partagés est le bon choix.

Parmi les inconvénients : Une architecture d’entreprise de services partagés en interne, contrairement à un BPO, a, lorsqu’elle est menée à sa conclusion logique, un réduction à l’absurde résultat, où chaque département commercial facture tous les autres départements commerciaux pour les services qu’il fournit. Par exemple, le service informatique peut facturer aux RH des frais mensuels pour l’utilisation du SIRH, tandis que les RH peuvent rendre la pareille en facturant au service informatique des services de recrutement, de gestion des avantages sociaux et de paie.

Les services partagés omniprésents peuvent transformer l’entreprise en un ouroboros financier géant.

Architecture orientée services métiers : une taille unique ne convient à personne

Les BPO et XaaS partagent une caractéristique qui pourrait, dans certaines situations, être un avantage, mais dans la plupart des cas, une limitation, à savoir la nécessité de banaliser. Cette exigence n’est pas non plus une question de préférence du service informatique pour la simplification. Elle est motivée par la préférence des décideurs de l’architecture métier pour la standardisation des processus et des pratiques à tous les niveaux.

Cela peut ne pas sembler être un choix onéreux, mais cela peut l’être. Fournir un service qui fonctionne de la même manière à tous les arrivants, quels que soient leurs besoins spécifiques et uniques, peut réduire les coûts immédiats, mais peut être, à long terme, paralysant.

Imaginez, par exemple, que les ressources humaines adoptent l’approche de l’architecture orientée services métier, offrant des ressources humaines en tant que service à ses clients internes. Dans le cadre de HRaaS, il fournit le recrutement en tant que service (RaaS). Et pour justifier cette transformation, il vante les mérites de la standardisation des processus pour réduire les coûts.

Imaginez, alors, que vous soyez responsable des opérations en magasin pour un détaillant très saisonnier, qui doit augmenter son personnel en magasin du Black Friday au Boxing Day. Imaginez également que le service informatique doit recruter un DBA.

J’espère qu’il est clair que le même processus ne fonctionnera pas à la fois pour le recrutement de personnel de magasin par centaines et pour l’embauche d’un seul professionnel technique hautement spécialisé.

« Standardiser » est facile à dire, mais difficile à faire fonctionner correctement. Et c’est avant que le responsable des ressources humaines chargé du recrutement n’essaie d’expliquer ce qu’il a besoin du SIRH pour faire.

En cela, ce que nous pourrions appeler une architecture orientée services métier n’est pas si différent de l’adoption de la SOA (avec les microservices, ses petits frères), pour votre architecture d’application. Dans les deux cas, appliquer la normalisation à une seule version est une ingénierie unique.