L'entreprise dispose d'un Système d'Information de Production (SIP). Ce SI est en grande partie caché aux utilisateurs métier, mais bien présent. Il est composé d'outils tels que les logiciels de centre d'appel, suivi des incidents, CMDB, supervision, ordonnanceur, BI de production, usines de développement, asset managers, cloud controllers… Le SIP traite les actifs logiciels et matériels comme ses propres objets métier. Le Système d'Information de Production est donc bien différent du Système d’information métier : Il le fait vivre.
La figure suivante montre que le système d’information métier s’appuie sur le SIP afin de bénéficier des processus de management (ITSM). Le SIP est accessible aux utilisateurs au sens large, aussi bien métier (via le helpdesk, accès aux tableaux de bord...) qu'à l’exploitant (supervision, déploiement, capacity planning...). Il est cependant grandement orienté vers l'exploitant.
Le SIP n’est généralement pas reconnu comme un système d’information à part entière. Faiblement visible du métier et ne dégageant pas de valeur métier directe, il est en conséquence le parent pauvre de l’IT d’entreprise.
Il est bien souvent qu'un amoncellement d’outils hétéroclites qui collaborent plus ou moins entre eux. Ces outils sont achetés pour résoudre des problématiques conjoncturelles. Je vois couramment dans des grandes entreprises 3 ou 4 outils de supervision différents, plusieurs ordonnanceurs, des outils de suivi des incidents variés et spécialisés par problématique ou domaine technologique (réseau, application...). La résolution des problèmes d’exploitation est cauchemardesque car les outils fournissent des informations incomplètes ou difficiles à corréler, voire non cohérentes en apparence car de sémantiques faiblement maîtrisées.
Les outils sont achetés par des domaines de responsabilité de l’organisation différents, sans souci de cohérence architecturale globale du SIP. J’ai un jour rencontré un patron d’une grande production qui m’a déclaré “Ici, il y a tous les outils disponibles sur le marché !”.
Mais j’ai aussi vu des situations beaucoup plus rationnelles qui prouvent que le SIP hétéroclite et désordonné n’est pas une fatalité.
Bref, tous ces symptômes sont ceux bien connus des architectes de SI qui sont en présence d’un système non urbanisé. Les conséquences sont évidentes : faible efficacité, renchérissement des coûts, frustration et métier peu satisfait !
Cette situation était communément acceptée, jusqu’à ce que le métier devienne plus exigeant sur le Time To Market et le Time To Repair. En effet, lorsqu’une release majeure met un an à sortir, les conséquences d’un SIP mal architecturé sont globalement noyées dans la masse des délais et retards.
Avec des exigences bien supérieures en termes de TTM (temps de release de l’ordre de la semaine ou du mois), les défauts d’architecture du SIP apparaissent. Pire encore, avec la réussite de l’agile et la vague DevOps, les défauts sont exposés au grand jour.
Reste au patron de production à appliquer au SIP ce que le métier applique pour son SI métier !
Chez OCTO, nous sommes des architectes de système d’information métier : bancaire, distribution, industrie, média, médical… et aussi du SIP ! En effet, la production informatique est un métier comme les autres ! Les savoir-faire de l’architecte et les cadres d'architecture s’appliquent naturellement au SIP. Nous allons utiliser la grille d’analyse appelée “ Matrice d’architecture OCTO ”. Elle présente les 5 domaines et les 4 couches d’architecture (voir le Livre Blanc OCTO sur l'architecture http://www.octo.com).
Chaque case représente un thème d’architecture que nous allons aborder pour décrire l’architecture générique du SIP.
Le SIP est accédé par de nombreux rôles (exploitant, utilisateur métier, développeurs…). La traçabilité et la ségrégation des rôles est fondamentale. Par exemple, les accès aux logs des applicatifs métier avec la garantie de leur non falsification est requise par des exigences réglementaires telles que SOX, Solvency, sur la vie privée, les données de santé… Les exigences en GDI et contrôle d’accès s’avèrent donc nombreuses et compliquées. Des bonnes bases d'analyse que j'utilise sont l’”ITIL Security Management” et "Open Security Architecture".
Les intervenants sur le SIP ont des cas d’usage très variés : entre l’accès au système de gestion des demandes pour voir l’avancement des prestations et la publication du tableau de bord SLA pour le management, les cas d’usage requièrent des besoins variés tant sur le plan du canal (Internet, Intranet, Téléphone, SMS…) que de l’ergonomie (visualisation de cubes, graphiques, alerting…). On fera attention plus spécialement aux fonctions de push et d'acquittement (des notifications) dont la fiabilité peut être essentielle. J'utilise systématiquement les processus ITIL pour établir les cas d'usage du SIP et en déduire les IHM. Mais dans bien des cas, je suis amené à raffiner et compléter par des processus spécifiques. Je recommande souvent des IHMs développées en spécifique afin de parfaire l'ergonomie et d'assurer la satisfaction des équipes d'exploitation.
Le choix du cadre de formalisation (ITIL...) guide la conception de la carte applicative. Voici le modèle de référence que j'utilise lorsque je cartographie des services d'un SIP :
On y distingue :
Les fonctions relatives aux actifs concernent la gestion du matériel et logiciel en termes de parc et de configuration.
Les fonctions d’opération sont celles visant à exploiter les services offerts.
Les fonctions finances traitent aussi bien les flux monétaires sortants (achats, investissements) que les flux entrants (paiement des services).
Les fonctions support adressent toutes interactions d’aide aux populations qui accèdent au SI métier et au SIP.
Les fonction de design concernent la conception, la réalisation et la maintenance du SIP.
Les fonctions d’achat adressent les aspects de prospections, d’achat, d’approvisionnement et de contrats.
Quels sont les objets métier dans le SIP ? Les cadres tels qu’ITIL proposent des modèles de données qui permettent de fixer les idées sur les éléments. Un des modèles les plus riches est celui du DMTF “Common Information Model”. Il décrit de façon générique les objets managés du SIP et leurs relations. Le plus haut niveau d'abstraction est représenté sur la figure suivante :
Source : http://www2.informatik.hu-berlin.de/
Ce modèle offre l’avantage d’un vocabulaire partagé et une possibilité de réaliser des systèmes interopérables. Je m'en inspire largement dans les projets en prenant ce qui est utile, voire en ajustant les relations entre objets. Ce modèle par sa complétude évite les oublis.
Le SIP supporte de nombreux processus métiers (métier du déploiement, de l’exploitation, de la gestion des demandes…) , bref du management des actifs (décrits dans le CIM). Ces processus sont clairement répertoriés dans les frameworks tels que ITIL et CobiT. Je n'hésite jamais à rajouter des processus hors cadre normatif (ou mieux encore à en enlever !) car seul le bon sens et le besoin du terrain doivent être pris en compte !
Sur ce niveau d’architecture la situation est beaucoup moins claire car les applications qui portent les fonctions décrites plus haut sont en général réalisées par des logiciels d’éditeurs ou open source plus ou moins en chevauchement. La conception applicative du SIP est donc une tâche difficile qui demande une connaissance fine des produits (modèle conceptuel, services offerts...).
L’intégration à la gestion d’identité d’entreprise est une question cruciale : Faut il un système de gestion d’identité (GDI) spécifique au SIP ou séparé de la GDI d’entreprise ? L’application de politiques de sécurité différentes entre la GDI métier et la GDI SIP constitue l’argument le plus pertinent pour la séparation. On arrive fréquemment à constituer un SOC (Security Operating Center) pour réaliser les exigences de sécurité communes à l’ensemble SI métier - SIP. Ce débat fait rage dans bon nombre de DSI soumises aux réglementaires contraignants (Santé, bancaire, défense…).
Les applications du SIP (service desk, cloud control, supervision, stockage…) disposent en général de leur propre interfaces homme-machine (IHM). Cependant, les stratégies d’intégration globale (portail, bureau intégré, poste de conduite de production) sont en général possibles car les produits exposent souvent des API qui permettent la construction des IHM spécifiques souhaitées. Ainsi, le choix de produits exposant des API efficaces est fondamental pour rendre l’usage aisé. Les IHM spécifiques sont facteur d’ergonomie et de productivité. J'applique une politique stricte sur ce point : je rejette systématiquement tout produit n'exposant pas d'API permettant l'intégration et l'automatisation.
La cartographie suivante montre une exemple de grands blocs applicatifs de services que l’on retrouve dans la plupart des SIP. Les flèches représentent des flux d’information entre composants applicatifs.
L’exemple de la duplication des référentiels du SIP est un exemple flagrant de la difficulté de la conception de l'architecture. Pour illustrer cet exemple, les produits tels que le configuration manager (Puppet, Chef, CFEngine…), le cloud controleur, disposent de leur propre base de configuration en "compétition" avec la CMDB. De même, on peut discuter du fait que la CMDB commande le provisioning des ressources ou qu’elle reçoit les informations d’inventaire suite à déclenchement de provisioning par un autre canal. Ainsi le recouvrement des produits, les décalages de modèles conceptuels et les capacités des API rendent particulièrement ardu la conception et d’intégration du système. Là encore, la solution vient d'une vision claire du modèle conceptuel du métier de la production et de ses processus.
La carte applicative ci-dessus indique de nombreux échanges. Comme dans tout système d’information deux écoles existent: Faire des flux point à point avec un médiateur d’API, sachant que l’orchestration est de type “libre” (réalisée par les déclenchements successifs) sans orchestration centrale. C’est ce mode qui est largement prédominant dans les SIP actuels, car c’est la solution naturelle sans urbanisation. A contrario, les processus demandant à être orchestrés pourraient bénéficier d’un orchestrateur central. Ceci est particulièrement exacerbé dans les fonctions du release management (orchestration métier, technique et d’infrastructure).
Ainsi, l'entreprise n'a pas un Système d'information mais deux : le SI Métier et le SIP. Avec les contraintes de “Time to Market” et “Time to Repair”, le niveau d’exigence sur le SIP devient tel que les entreprises ne l'ayant pas urbanisé ne peuvent plus suivre le rythme demandé.
Une démarche DevOps apportera 100% de sa valeur si elle est supportée par une réflexion d’architecture du SIP. La difficulté majeure consiste à réaliser le modèle d’architecture cible avec les produits d’ITSM que l’on achète et qu’on intègre. L'utilisation d'un cadre d'architecture pour le SIP est alors un guide majeur vers le succès.