Devops for Growth

Edit: I had completely forgotten that there is a relatively new area of the industry around “data engineering” to support data scientists and analysts. ETL to data engineers is more like bash scripts to most coders. It ought to work well just once or maybe periodically but generally doesn't require much effort. Data engineers help get huge amounts of data around their companies and will use Python or SQL or whatever gets the job done.

There's also a completely different scale of “batch” jobs which is where tools like Spark, Flink, and MapReduce come in. These tools can also be used for significantly more complex processing and analysis in addition to just moving data around.

Comment créer son format pivot ?

Plusieurs démarches sont possibles pour créer son modèle de formats pivot.

La démarche « top-down »

La démarche « top-down consiste à conceptualiser l’existant métier. Elle préconise de construire ces formats pivot à partir de la sémantique métier de l’entreprise. A partir de ces formats pivot, dans les systèmes, on modifie les traitements et les structures pour qu’elles tiennent compte des ces nouveaux formats, qui peuvent être loin de la réalité technique.
L’intérêt de cette méthodologie est qu’elle permet de mieux s’aligner aux besoins métiers, et donc de mieux répondre aux nouveaux challenges de l’entreprise. Elle permet aussi de profiter pleinement des mutualisations de formats pivot, qui sous-entend la mutualisation de services, et donc une architecture SOA optimisée. La contrainte est qu’elle demande une somme de travail considérable (besoin de cartographier tout le métier du SI pour ensuite le décliner sur les couches basses de développement), et peut induire un coût certain de refonte d’une partie du SI.

La démarche « bottom-up »

La démarche « bottom-up » re-conceptualise l’existant technique. Elle guide le concepteur vers une rétro-conception de l’existant technique, à partir des formats manipulés dans les applications, pour en déduire des formats pivot.
Son gain principal est de réutiliser l’existant, et donc de capitaliser et de gagner du temps sur les développements. De plus, dans le cas de Systèmes d’Informations dans laquelle une application centrale manipule des données avec plusieurs autres systèmes, en partant de données échangées par cette application, on dispose d’un format unitaire cohérent et surtout exhaustif. L’inconvénient de cette démarche est qu’on ne s’aligne pas sur le métier de l’entreprise, il y a donc un risque de césure entre les besoins que peut exprimer la direction métier et les réponses que peut lui apporter la DOSI.

La démarche « meet in the middle »

Cette démarche préconise de mener en parallèle un chantier « Top Down » et un chantier « Bottom Up ». Une fois ces deux chantiers en phase finale, l’objectif est de trouver une passerelle entre ces deux résultats et donc entre les formats pivot orientés métier et les formats pivot orientés techniques. Elle présente les avantages des deux premières méthodes : alignement parfait sur le métier et réutilisation de l’existant. Son principal inconvénient est le risque d’effet « tunnel » qu’elle engendre : attendre la fin des deux chantiers pour construire des formats pivot alternatifs entre une approche métier et une approche technique. Le risque principal est que durant le temps de construction de la passerelle, les besoins métier ou plus vraisemblablement les formats pivot techniques aient changé : les formats pivot alternatifs deviennent alors obsolètes.

La démarche « middle-out »

Cette démarche préconise de commencer à mi-chemin (« middle »)  entre le métier et la direction opérationnelle du SI (DOSI), c’est-à-dire à partir d’un vocabulaire commun aux gens du métier et aux informaticiens. Elle s’attaque au problème principal des projets informatiques actuels : la compréhension des problématiques métier côté IT, et vice-versa. Les deux parties trouvent un consensus par l’intermédiaire d’une base d’entités composants-entités métiers nécessaires, à partir duquel découleront les entités haut niveau côté métier (domaines sémantiques, classes sémantiques…), et les entités bas niveau côté DOSI (objets de type Data Transfert Objects).
Cette démarche peut être complémentaire à la mise en place progressive d’une architecture SOA.
Personnellement, je préfère les deux dernières démarches qui allient pragmatisme et efficacité. La meilleure méthode parmi ces deux dernières est à mon avis de privilégier l’une ou l’autre approche selon les cartes en main de l’entreprise sur ce projet :

• Disponibilités du métier ;
• Degré de compréhension entre la DOSI et le métier ;
• Temps et nombre de ressources allouées à la tâche d’urbanisation…

Comme dans beaucoup de situations, il faut simplement faire preuve de bon sens…

Illustration

DataOps is a collection of technical practices, workflows, cultural norms, and architectural patterns that enable:

• Rapid innovation and experimentation, delivering new insights to customers with increasing velocity
• Extremely high quality and very low error rates
• Collaboration across complex arrays of people, technology, and environments
• Clear measurement, monitoring and transparency of results

The best way to explain DataOps is to review its intellectual heritage, explore the problems it is trying to solve, and describe an example of a DataOps team or organization. Our explanations below start at a very conceptual level, but then quickly proceed into pragmatic and practical terms. We find this is the best way to help data professionals to understand the potential benefits of DataOps.