Caractéristiques de l’outil ‘IT Process Automation’

III.5.3.1Caractéristiques techniques

Deux installations du logiciel sont prévues :

• Dans un environnement de développement (ou environnement de test), au sein duquel il est possible de créer et de tester les workflows IT.

• Dans un environnement de production. Cet environnement pilotera l’infrastructure ICT de production du SPF Finances. Il doit répondre à toutes les exigences de haute disponibilité et de disaster recovery visées au paragraphe III.5.3.2.

Le soumissionnaire doit :

• Indiquer sur quelles plates-formes le logiciel proposé sera supporté ; conformément aux fondements ICT documentés par le SPF Finances, le logiciel doit pouvoir fonctionner sous Solaris 10 (sparc et/ou x86) ou Windows 2008 R2 server.

• Préciser la plate-forme qui emporte la préférence du soumissionnaire.

• Spécifier les ressources (serveurs, stockage) à prévoir.

• Décrire les procédures qui permettront migrer les workflows de l’environnement de développement vers l’environnement de production. Ces migrations seront confiées au personnel interne du SPF Finances.

III.5.3.2Haute disponibilité, disaster recovery, back-up et restore

Le SPF Finances a mis au point un plan de Disaster recovery : deux sites (North Galaxy – Bruxelles et Diamond Board-Anderlecht) se suppléent mutuellement. La plupart des éléments de l'infrastructure IT sont dédoublés.

La solution ‘IT Process Automation’ fera partie du plan DRP. L’outil devra aussi exécuter différentes procédures DRP.

L’outil doit disposer des possibilités de back-up et restauration des données (fichiers propres à l’outil et base de données).

Le soumissionnaire doit expliquer :

• Comment la solution proposée répond aux exigences de haute disponibilité. Cela suppose notamment que la solution puisse fonctionner dans un environnement en clustering.

• La solution doit aussi pouvoir absorber facilement les pointes de charge. Le soumissionnaire indique dans quelle mesure la solution est évolutive.

• Comment la solution peut être mobilisée techniquement pour supporter les scénarios de disaster recovery.

• Comment les back-ups et restaurations seront effectués. Le soumissionnaire expliquera clairement ce qu’il propose et les possibilités de la solution en la matière. Il doit aussi exposer les possibilités de back-up en ligne ainsi que la compatibilité de la solution avec le logiciel de back-up EMC Networker.

III.5.3.3Évolution de la plate-forme logicielle

Le soumissionnaire est prié de :

• Décrire le cycle de vie de la solution à livrer (notamment cycle de release des nouvelles versions, mises à jour automatiques des intégrations…)

• Décrire l’évolution des bibliothèques de workflows

• Décrire l’évolution des connectors/adapters avec les plates-formes IT intégrées.

III.5.3.4Fonctionnalité workflow et orchestration

La création et la modification des process workflows doit passer par une interface graphique centrale, unique, visuelle, intuitive et conviviale.

L’outil permettra d'élaborer un workflow complet sans connaissance du scripting ni des détails techniques.

Le soumissionnaire doit décrire de quelle façon les process workflows seront créés.

III.5.3.5Définition d’un workflow

Un IT process workflow peut résulter de différents facteurs (URL, monitoring event, calendrier, web service, API...).

Le soumissionnaire doit spécifier :

• Quelles méthodes l’outil supporte pour lancer un workflow. Les paramètres d’entrée nécessaires pour lancer un workflow doivent pouvoir être introduits via ces méthodes.

• Quelles informations peuvent générer une étape de processus en sortie.

• Quelles données (saisie utilisateur, variable d’environnement, XML…) peuvent servir à lancer une étape de processus.

• Comment (variable, fichier, XML…) il est possible de transmettre des données entre les différentes étapes d’un process flow.

Le soumissionnaire explique comment l’outil supporte les situations suivantes :

• Synchronisation entre plusieurs workflows parallèles

• Rapports de statut concernant l’exécution des jobs unitaires (bon/erreur…)

• Intégration en temps réel des situations d’erreur dans le processus event handling existant, basé sur HP OpenView Operations (event handling)

• Exécution d’un workflow alternatif en cas d'erreur (branching)

• Templates standard pour décrire une étape du workflow (p.ex. lancer un assistant pour rassembler les données nécessaires)

• Un process flow doit pouvoir être lancé plusieurs fois simultanément. En guise d’exemple, nous songeons aux compliancy checks (p.ex. contrôle de la version des clients installés) à effectuer sur une liste de serveurs

• Une étape du workflow doit à son tour représenter un sous-workflow existant. Quelles sont les possibilités de classification hiérarchique des workflows ?

• Traitement d’une approbation dans un process flow

• Traitement d’une situation d’attente (p.ex. attente d’un événement, d’une approbation, non-réception d’une approbation dans le délai…)

• Traitement d’une étape manuelle dans un process flow

• Exécution des compliancy checks : nous entendons par là une comparaison des politiques techniques avec la situation réelle et le traitement des anomalies

• Traitement des e-mails (création, envoi, interprétation de la réponse…)

• Support à l’exécution d’un calendrier prédéfini (p.ex. quotidien, hebdomadaire, exécution dans une période déterminée…)

L’outil offre un ensemble de process flows standard qui couvrent un grand nombre de workflows courants (p.ex. system health check…). Ils peuvent notamment servir de base à la création de nouveaux workflows.

Le soumissionnaire :

• Dresse la liste des workflows prédéfinis et précise dans quels domaines on peut les utiliser

• Explique comment on peut tenir à jour les bibliothèques de workflows prédéfinis

• Spécifie les abonnements nécessaires pour utiliser les workflows prédéfinis.

III.5.3.6Débogage d’un workflow

Après la conception d’un workflow, une session de débogage peut être lancée dans l’interface graphique. Cela signifie que le workflow peut être exécuté avec ou sans les différents systèmes de management. Cela permet de valider pas à pas le déroulement logique de tout le flow (ou d'une partie, à l'aide de breakpoints). Il est possible de forcer l’exécution de certains

branchements du workflow en paramétrant au préalable des variables/statuts.

Le soumissionnaire est prié de préciser dans quelle mesure les fonctionnalités de débogage sont supportées.

III.5.3.7Interface utilisateur graphique

Dans la solution proposée, une distinction est faite entre :

• Une interface graphique pour la conception des workflows.

• Une interface graphique pour l’administration de l’outil.

Cette interface permet de gérer efficacement l’application (gestion des utilisateurs, définition des rapports, paramétrage…)

• Une interface graphique pour le monitoring opérationnel des workflows.

Avec cette interface, les opérateurs peuvent suivre pas à pas l’exécution des processus.

Le pouvoir adjudicateur souhaite une vue sur l’exécution future des processus planifiés, parallèlement aux rapports d’exécution des processus passés.

• Une interface graphique pour les utilisateurs finaux.

Cette interface permet de :

o visualiser les workflows que l’on peut lancer pour un certain type de CI et pour certains CI

o connaître le statut d’une action spécifique qui a été lancée o lancer des workflows à partir d’un contexte spécifique

o visualiser les FAQ qui permettent de choisir le workflow convenant à une situation existante (éventuellement avec la possibilité de lancer un workflow à partir d’un knowledge item).

• Une interface “portlet/widget/webparts” qui permet de faire apparaître des éléments de la solution IT Process Automation sur des portails extérieurs. On songe en particulier à la solution HP BSM (Business Service Management) et à l’IT Service Portal.

L’accès aux fonctionnalités des différentes interfaces doit dépendre des autorisations. L'offre doit préciser le mappage possible d'Active Directory et/ou des groupes LDAP avec les droits

d'utilisation. (voir aussi le paragraphe III.5.4 sur la gestion des utilisateurs).

Le soumissionnaire doit spécifier :

• Les éventuels chevauchements de fonctionnalités dans les interfaces graphiques.

III.5.3.8Gestion des versions

La solution proposée permet de travailler en groupe sur un projet d’automatisation. À cet effet, l’outil doit disposer d’un outil intégré pour la gestion des versions, avec un repository central.

À cet égard, voici les fonctionnalités demandées :

• Les changements sont identifiés par un code, le ‘numéro de révision’.

• Tout changement est associé à un moment dans le temps et à la personne qui a effectué le changement. Chaque fois qu’un changement est chargé dans le système de gestion des versions (check-in), il peut s’accompagner d’un commentaire décrivant la modification.

• Il doit être possible d'extraire les versions antérieures du système de gestion des versions (check-out).

• Il est possible de comparer les changements, de les rétablir et parfois de les conjuguer.

• Un fichier est attribué de façon exclusive à un utilisateur déterminé ; les autres ne peuvent intervenir en même temps sur le même process flow. Lorsque l’utilisateur a fini d’apporter des changements, le code source est remis à la disposition des autres. Ce mécanisme de verrouillage apparaît visuellement aux yeux des autres.

• Les nouvelles versions peuvent être ‘promues’ de l’environnement de développement vers l’environnement de production.

Le soumissionnaire doit indiquer comment la solution offerte met en place les fonctionnalités demandées.