Duquesne Group Duquesne Group

English version
Consulting

Nos experts sont des professionnels internationaux de haut niveau, issus de cabinets de conseil renommés, de grandes DSI ou d'acteurs majeurs du secteur technologique. Ils sont au service des clients, dans une démarche caractérisée tout autant par la méthode et la rigueur que par le pragmatisme opérationnel. Contactez-nous pour en savoir +
French version
Consulting

Our experts are top level international professionals, veterans of leading consulting companies, prestigious research firms, large IT organisations or major players in the information technology industry. Focused on client service, their approach is rigorous and methodical, and at the same time pragmatic and operational. Contact us to find out more


Complexité des PRA : comment réagir ?

Un approche structurée élaborée lors de nos interventions en clientèle

L'évolution du SI fait la part belle aux progiciels du marché. Des pans entiers du SI sont progressivement remplacés par des produits sélectionnés sur leur adéquation fonctionnelle. La production informatique se retrouve alors en présence d'une grande diversité technologique à gérer. Comment peut-on penser la continuité d'activité dans ce contexte ?


Les faits :

De nombreuses entreprises, confrontées au vieillissement de leurs applications décident de recourir à des progiciels du marché pour construire leur SI de demain. Il est courant alors de constater les effets suivants :

- un éclatement du modèle de données : les progiciels choisis sont indépendants, ils possèdent leur(s) propre(s) base(s) de données gérée(s) indépendamment les unes des autres. Les intersections entre les bases de données ne sont pas vides, des mécanismes de mise à jour croisées sont donc nécessaires.

- une complexité accrue des flux d'échange : lié à ce qui précède, les échanges entre progiciels deviennent nombreux et complexes. Il faut y ajouter les échanges avec l'extérieur et les échanges provisoirement indispensables avec les anciens systèmes qui ne partent pas immédiatement.

- une multiplication des techniques d'échange : il est fait appel dans ce contexte, aussi bien aux échanges synchrones (un logiciel envoie une information et attend une réponse) qu'aux échanges asynchrones (envoi sans attente) ou à d'autres formes selon les produits utilisés ou les intégrations pratiquées.

- une diversité des plateformes utilisées : le choix s'opérant essentiellement par les fonctionnalités, l'intendance des systèmes suit. Et l'on constate alors une multiplication des architectures utilisées, recourant à un grand nombre de machines sous divers OS (Linux, Windows, AIX, Solaris, etc.) et SGBD (DB2, Oracle, encore Sybase mais aussi mySQL) ainsi qu'une abondance d'autres éléments importants de middleware (WebSphere, TomCat, JBoss, ...), sans parler du stockage qui lui aussi se retrouve éclaté sur des baies RAID, des systèmes NAS en plus des systèmes à contrôleur du passé...

- une absence de pilotage d'ensemble : lorsque cette diversité arrive progressivement en production, force est de constater très souvent que le pilotage de l'ensemble n'a pas été prévu au-delà d'une simple surveillance de chaque système pris isolément. La conception d'une vision d'ensemble avec un pilotage de service n'existe pas.

De cette grande diversité il est très difficile de planifier efficacement des plans de reprise réalistes. Confronté à des problèmes inextricables en cas d'arrêt de certaines machines, il n'est pas rare que la seule solution que les exploitants trouvent soit d'arrêter toutes les machines dans un certain ordre pour limiter les difficultés.

Nos recommandations :

Dans des situations de ce genre, nous préconisons en général trois types de démarche.

1- Réaliser un BIA (Business Impact Analysis) : faire un bilan pour déterminer les activités les plus critiques de l'entreprise qu'il faut traiter en priorité. Cela permettra de focaliser l'attention sur les éléments techniques qui sont utilisés par ces activités. En procédant ainsi avec nos questionnaires, le client se concentre sur la partie la plus critique de son informatique. Les applications sont classées selon leur délai d'interruption maximal admissible (DIMA en minutes, heure, demi-journée, un jour, deux jours etc).

2- Définir techniquement trois plateformes à utiliser. Pour éviter de trop dépendre de faits accomplis techniques, il est utile de typer trois plateformes :
- haute disponibilité (de type cluster actif/actif comme Oracle RAC par exemple)
- moyenne disponibilité (de type actif/passif comme avec Oracle dataGuard) assortie d'un PRA
- disponibilité courante : serveur de base, avec un PRA à définir, voire rien en secours.
Cette typologie est à établir en partant de l'existant du client, nous cherchons à bien nous assurer que ces trois plateformes existent en production, sont pilotées et gérées dans la durée.

3- Établir la correspondance entre les deux : vérifier que les applications exigeantes sont hébergées sur des systèmes de niveau de disponibilité adéquat. Au besoin détecter les écarts et les résoudre avec un plan d'action approprié.

Dans la pratique ces trois démarches concomitantes permettent de structurer les projets et de créer des degrés de liberté entre les études, le système et la production.
Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share

Planifier la continuité des activités | Sécuriser les informations et les systèmes | Optimiser les infrastructures informatiques | Améliorer les services IT aux clients