Blog de Michaël Mary

Un article de panda31    Pas de commentaires

Bonjour à tous,

Je suis de retour!

Ce billet simplement pour discuter du vaste sujet d’automatisation.
L’automatisation c’est simplement modéliser assez finement un processus afin de le rendre plus simple, plus accessible et plus rapide en exécution. Il en naît une rationalisation du processus en question ainsi que -lorsque c’est bien fait- un gain en rapidité de traitement et une facilité à propager ce processus.

Ma réflexion a donné naissance à un concept d’automatisation simple : ASMR
Adaptation / Submission / Monitoring / Reporting

=> Ne sont-ce pas là des besoins que l’on rencontre tous les jours ? Pourtant, une approche si simple n’est pas adoptée par tous ! Certains se compliquent la vie à mon goût. Rappelez-vous que dans les 80% des métiers de l’informatique de type service logiciel, on part sur ces phases-là. ASMR !

Je m’explique, si un processus est connu pour sa complexité, et sa difficulté à être appréhendé, c’est qu’il lui manque une « newbie-oriented frontend ». Si on ne comprend pas un sujet c’est qu’il est diffus et travaille avec beaucoup de concepts. On ne peut pas tout comprendre et maîtriser. Mais a-t-on besoin de tout maîtriser ?
Certains processus ne sont importants et utiles que parce qu’ils donnent des reporting utilisables. Ce sont ces reporting qui sont des résultats effectifs pas le processus en soit. Alors pourquoi ne pas le masquer derrière un bouton « Run », cliquable par n’importe quel collaborateur ?

Mais comment procéder ?

Tout part d’une bonne compréhension. Il est important de toucher au processus dans ses entrailles. Comment faire ? Des entrevues avec les key-users, ou devenir un key-user est très utile. Ensuite, il faut bien sûr dimensionner les phases, identifier les états… bref tout ce que l’on sait faire dans notre métier de consultant ou d’AMOA ou autre.

Mais plus simplement, ne pourrait-on pas trouver une approche générique ?

La mienne est la suivante :

• J’identifie les tâches à produire, les E/S, le degré de reporting nécessaire, les goulots d’étranglement… bref je comprends le process et je cherche le superflus et les besoins
• Je crée un lanceur de tâches multi-threadé. Ne nécessite que très peu de temps en développement.
• Je crée des tâches pouvant être intégrés dans des templates (XML pour la description). Ces tâches sont exécutables et sont regroupés selon 4 groupes Adaptation, Submission, Monitoring, Reporting

=> ASMR est né !

Le concept est sympa mais par quoi commencer ?
1. Identifier le processus de A à Z
2. Le décomposer selon A, S, M, R
3. Intégrer les tâches définies en les optimisant si possible selon leur boîte d’appartenance (ASMR toujours !)
3.1 Gestion d’E/S => Adaptation (A)
3.2 Soumission d’une tâche d’exécution (je parle d’une tâche générique pour le moment) => Submission (S)
3.3 Suivi de l’état de cette tâche => Monitoring (M)
3.4 Analyse des résultats de la tâches et soumission des données obtenues dans un moteur de reporting => Reporting (R)

4. Intégration
4.1 On obtient un workflow d’automatisation
4.2 Dans notre processus initial, on a des états et des conditions à respecter.
4.3 On dégage des « domaines » pour construire des plugins respectant les points du §3
4.4 Ces plugins doivent pouvoir être ajoutés/retirés/mis à jour
4.5 Un plugin se construit selon les points suivant
4.5.1 Développement d’un formulaire d’entrée
4.5.2 Conditionnement de l’exécution
4.5.3 Moteur d’exécution fourni par l’outil appelant les plugins (pool de threads, batch pour calculs, queues d’exécution, …)
4.5.4 Monitoring fourni par l’outil appelant donc nécessité de donner des KPIs (indicateurs, déclencheurs…)
4.5.5 Tous les plugins doivent avoir la même forme pour garder de la simplicité que ce soit dans le front end (GUI du plugin).

5. Constuction de l’IHM de l’outil
5.1 l’IHM doit être simple pour toutes les vues pour tous les plugins
5.2 l’IHM doit fournir des formulaires simples, courts autant que possibles
5.3 l’IHM ne doit pas afficher trop d’information. Souvenez-vous du KISS (Keep It Simple Stupid!)
5.4 l’IHM doit founir un état de progression et des KPIs simples, sélectionnables
5.5 Le passage d’une vue plugin à une autre doit être simple (navigateur sur le côté)
5.6 La partie reporting doit pouvoir afficher des graphes et aider l’utilisateur à construire des rapports personnalisés

6. Coût d’un tel outil
6.1 Le moteur ASMR doit être assez générique pour être réutilisable à volonté !!! Restons simples et orientés plugin
6.2 Les plugins doivent aussi être génériques ! Décomposez tant que vous le pouvez. Si ça sert de faire des sous-étapes. Même s’il s’agit de gérer la création de répertoire ou juste de gérer des soumissions de jobs batch ou d’ouvrir un fichier Excel pour lire une information particulière. Ce n’est pas une API ! Mais un plugin !
6.3 L’appel d’un processus particulier passe pas sa description dans un fichier XML (par exemple).
6.4 Chaque étape appelle UN plugin avec des arguments et signifie des dépendances vis-à-vis des étapes la précédant ou son indépendance et sa possibilité d’être joué en parallèle.

NB : Il faut pouvoir récupérer un déclencheur pour les étapes suivantes dépendantes de cette étape.

6.5 Il est important de faire des templates de fichiers de descriptions et de prévoir une IHM dédiée pour les instancier avec des données réelles

=> CONCLUSION
Au final, on se retrouve avec un coût « important » pour la coquille de l’outil mais pas pour les plugins !
Les plugins sont développés au fur et à mesure selon un formalisme simple (objet!) et identique pour tous (besoin d’une interface stricte à implémenter par chaque plugin).
Si votre plugin fait plus de 2 actions, c’est qu’il faut le découper !

Les processus ou sous-processus sont ensuite décrits dans des fichiers XML. L’IHM est mise à jour grâce aux méthodes graphiques des plugins. On peut imaginer que les plugins fournissent des composants graphiques par simple appel à une fonction que l’on peut placer dans une zone d’accueil pour les plugins.

Je compléterai ceci avec un exemple concret dès que possible pour vous montrer qu’un peu de développement interne dans une SSII par exemple peut rapporter pas mal de budget en respectant cette approche ! Ca marche pour moi pour donc pourquoi pas vous ?