La promesse du BigData faite aux entreprises est souvent la suivante :
« En reprenant le contrôle sur vos données, vous pourrez exploiter cette nouvelle ressource et la transformer en source de richesse»
Seulement, la réalité s’avère bien plus complexe… Réussir un projet BigData dépend de plusieurs facteurs – non techniques – qu’il convient de prendre en compte. Bien évidemment, utiliser la bonne technologie au bon moment s’avère décisif. Cependant, les échecs de projets BigData proviennent souvent d’autres raisons, davantage liées à l’urbanisme et à l’organisation du système d’informations (SILe SI désigne le système d'informations d'une organisation.).
La SOA actuelle dans les SI : une mauvaise approche
Régulièrement, cette nouvelle notion – le big data – est associée à l’approche SOA. A tort ou à raison ?
L’approche SOA, architecture orientée services, nous promet de sortir de l’informatique en silos pour aller vers un SI composé de services métiers qu’il suffirait d’orchestrer pour réaliser n’importe quelle application. Ainsi, lorsque l’on réfléchit à la restructuration du système d’information, consultants et architectes armés de leur PowerPoints expliquent généralement qu’il faut réaliser un Big Bang en redécoupant chaque processus métier pour former une myriade de services métiers unitaires.
Une solution conseillée ? Pas nécessairement, d’autant plus que le coût d’une telle réécriture est prohibitif. De plus, toute approche basée sur un Big Bang se termine, en informatique, souvent par un « massacre technique » et un gâchis de temps et d’énergie considérable.
Alors STOP aux idées reçues ! Non, découper son SI en une multitude de petits services ne rendra pas votre SI plus agile. Et non, orchestrer des services n’est pas plus facile que de développer des applications.
Faut-il pour autant mettre la SOA au placard ?
Pas nécessairement et même pas du tout ! Il faut juste redéfinir un peu ses contours pour la mettre à notre service et non l’inverse. Reposant sur une bonne identification des services, la SOA permet l’adaptabilité à l’évolution des activités de l’entreprise, une plus grande tolérance aux pannes et la réutilisation des codes si elle est bien construite. Autant d’opportunités dont on ne doit se passer.
SOA et oubli de la performance
La performance du SI ? C’est la principale finalité recherchée, et elle est possible grâce à la SOA. Seulement, une décomposition des services trop pointue et trop fine, comme elle est souvent faite, ne permet pas d’atteindre les performances attendues.
Prenons l’exemple de projets se basant sur des appels à des services unitaires. Ils se retrouvent souvent avec des performances bien en deçà de l’acceptable (pour des applications mobiles, et encore plus, pour des projets BigData).
La cause ? Un découpage trop fin des services. On se retrouve parfois, pour une seule action de l’utilisateur, à appeler parfois 30 services ! Services, qui, soit dit en passant, se basent souvent sur un ORM. Cet ORM, va lui-même déclencher une centaine de requêtes. Ainsi, pour une simple interaction avec l’utilisateur, le SI va devoir supporter de nombreux appels et un nombre de requêtes conséquent.
Evidement, les performances ne sont pas au rendez-vous et, de facto, les réunions de crise s’installent. Les consultants et architectes ayant quittés le navire depuis longtemps, seules les équipes projets ou d’exploitations tentent de sauver des applications à la dérive.
Il convient donc de ne pas sombrer dans la facilité de vouloir créer des services unitaires trop simples de type CRUD (Create, Read, Update et Delete) mais bien d’urbaniser son SI en créant des services de bon niveau. C’est là que se trouve toute la difficulté et la compétence d’un architecte et non pas dans l’application dogmatique d’un standard.
Alors que faire avec la SOA ?
Inscrire dans les esprits que la SOA n’a pas pour finalité une division maximale des services serait un bon début !
A l’origine la SOA, ou plutôt son esprit, doit se résumer à l’idée suivante : « Faire communiquer facilement les applications entre-elles ». La solution n’est donc pas toujours d’appeler d’autres services à l’autre bout du SI : une bonne application doit avoir ses propres données. Ceci ne veut pas dire que ces données ne proviennent pas d’autres sources, bien au contraire, mais que l’utilisation de ces données se fait en local.
Un second aspect et non des moindres : Il faut apprendre à décorréler les interactions de l’utilisateur avec les interactions du SI.
Pour simplifier grossièrement le phénomène, un clic utilisateur doit retourner instantanément la main à l’utilisateur sans pour autant que l’action soit réalisée dans le SI. L’utilisateur se moque de savoir si, oui ou non, vous avez mis à jour le stock de votre magasin, ou notifié la production. La seule chose que vous devez promettre à votre utilisateur est que l’action a bien été prise en compte, quitte à lui fournir le résultat ultérieurement. Pour faire le lien avec la SOA, le service est l’action de l’utilisateur et pas des services techniques de sauvegardes ! Quand on parle de créer des APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données., c’est à ce niveau qu’elles doivent se situer. Une méthode d’une API = une action utilisateur. Gardez la tambouille informatique pour vous.
Et le BigData dans tout ça ?
En gardant cela en tête, la SOA est un vrai atout pour réussir un projet BigData. Pourquoi ? Car une fois ces services correctement découpés, on peut tirer parti de la puissance des données qui y sont générées. De plus, bien découper son SI en services métiers de haut niveau permet de créer des points de collecte « métiers » faciles pour accumuler des donnée qui peuvent ensuite servir à mener des projets BigData, du moins à réaliser une analyse de haut niveau sur ces données.
En résumé sur la SOA et le BigData :
Avant de reprendre le contrôle sur ses données, il convient de reprendre le contrôle sur son SI en appliquant une transformation SOA. Néanmoins celle-ci doit être murement réfléchie ! Gardez à l’esprit que la SOA est un outil et non une fin en soi.