guide pratique pour le décommissionnement...

L I V R E B L A N C

Guide pratique pour le décommissionnement applicatif

Le présent document contient des données confidentielles et exclusives, ainsi que des informations constituant des secrets commerciaux (« Informations confidentielles ») d'Informatica Corporation. Il ne peut être copié, distribué, dupliqué ni reproduit de quelque manière que ce soit, sans l'autorisation écrite préalable d'Informatica.

Même si tout a été mis en œuvre pour garantir que les informations contenues dans ce document sont exactes et exhaustives, il est possible qu'il contienne des erreurs typographiques ou des inexactitudes techniques. Informatica ne saurait être tenu responsable des pertes résultant de l'utilisation d'informations figurant dans ce document. Les informations contenues dans le présent document sont susceptibles d'être modifiées sans préavis.

L'intégration des attributs de produits étudiés dans ce document dans une quelconque version ou mise à jour d'un produit logiciel Informatica — ainsi que le calendrier de sortie de ces versions ou mises à jour — sont à la seule discrétion d'Informatica.

Protégé par les brevets américains suivants : 6,032,158 ; 5,794,246 ; 6,014,670 ; 6,339,775 ; 6,044,374 ; 6,208,990 ; 6,208,990 ; 6,850,947 et 6,895,471 ; ou par les brevets américains en instance suivants : 09/644,280 ; 10/966,046 ; 10/727,700.

Édition publiée en juin 2009

1Guide pratique pour le décommissionnement applicatif

Livre Blanc

Table des matièresPrésentation du décommissionnement applicatif . . . . . . . . . . . . . . . . . 2

Leviers pour le retrait d'applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Réduction des coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Consolidation des applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Mise à niveau d'un système hérité vers une solution ERP . . . . . . . . . . . . . . . . . . . . . 3

Conformité réglementaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Déterminer si une application peut être retirée . . . . . . . . . . . . . . . . . . . 4

La valeur métier d'une application héritée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Le coût d'une application héritée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Stratégies de décommissionnement applicatif . . . . . . . . . . . . . . . . . . . 5

Priorisation des applications pouvant être retirées . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Retrait de tout ou partie des données requises pour les besoins métiers et la conformité réglementaire . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Gestion d'application lorsque l'application ou le modèle de données est peu ou pas maîtrisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Sept étapes pour réussir le retrait d'une application . . . . . . . . . . . . . . . 6

1. Création d'une équipe interfonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Compréhension de l'application héritée et des données à retirer. . . . . . . . . . . . . . 7

3. Conservation du contexte métier des données de l'application . . . . . . . . . . . . . . . 7

4. Accès aux données obsolètes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5. Sécurisation des données obsolètes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6. Définition de politiques de conservation - ou de suppression - sur les données obsolètes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

7. Sélection d'un fournisseur pour le retrait des applications . . . . . . . . . . . . . . . . . . 9

Quelle est l'approche d'Informatica en termes de décommissionnement applicatif ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Classement et extraction des enregistrements métiers . . . . . . . . . . . . . . . . . . . . . . . 9

Accès transparent et sécurisé aux données obsolètes . . . . . . . . . . . . . . . . . . . . . . . 9

Conformité aux réglementations de conservation, de suppression et de confidentialité des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Implémentation de stratégies de stockage à plusieurs niveaux . . . . . . . . . . . . . . . . 10

2

Présentation du décommissionnement applicatifAu fur et à mesure que les entreprises se développent, les départements informatiques doivent en permanence rechercher de nouvelles applications qui répondent à des besoins métiers non satisfaits, améliorent l'efficacité et réduisent les coûts. Lorsqu'une entreprise s'adapte aux changements et exploite la technologie la plus récente afin de générer de la valeur ajoutée pour ses clients, son portefeuille d'applications reflète les modifications correspondantes. Il n'est pas rare que des entreprises dans le métier depuis une dizaine d'années disposent de centaines d'applications héritées apportant une valeur marginale à l'entreprise mais représentant des coûts opérationnels et de maintenance considérables.

D'après Forrester Research : « La rationalisation du portefeuille d'applications existant est une étape nécessaire pour les entreprises créées il y a dix ans ou plus, en particulier si ces entreprises envisagent de passer à l'architecture orientée services (SOA) — pourquoi reporter toute cette charge au prochain paradigme informatique ? Seules certaines applications héritées seront réutilisables et d'autres ne sont bonnes qu'à être retirées — mais comment les distinguer ? Pourquoi gaspiller de l'argent à la maintenance d'applications qui ne sont plus utiles ? Pourquoi ne pas réaffecter ce budget pour qu'il profite à votre entreprise ? »1 Le retrait d'applications permet de relever ces défis en supprimant l'application héritée ainsi que la structure logicielle et matérielle associée tout en assurant la disponibilité des données pour le reporting, la conformité réglementaire et les besoins métiers réguliers.

Les entreprises dépensent plus de 75 % de leur budget logiciel en opérations du quotidien et à la maintenance.2 Avec seulement 25 % disponibles pour de nouveaux projets, les départements informatiques ont pour défi de financer des projets pouvant avoir un impact significatif. Les DSI avisés chargés du budget savent apprécier les économies réalisées lors du retrait d'applications héritées. De nombreuses entreprises tournées vers l'avenir ont déjà établi une liste des meilleures pratiques et de méthodologies pour réviser régulièrement les portefeuilles applicatifs et déterminer si une application doit être retirée, remplacée, modernisée ou conservée en l'état.3

1 Phil Murphy, « Got Legacy? Four fates awaits your applications », Trends, Forrester Research, 10 janvier 2006, p. 2.

2 Ibid., p. 5.3 Ibid., p. 5.

Livre Blanc


Leviers pour le retrait d'applications

Réduction des coûtsLa réduction des coûts est l'une des principales motivations qui poussent une entreprise à lancer un projet de décommissionnement applicatif. Comme le retrait d'applications permet de mettre hors service l'application et l'infrastructure logicielle et matérielle associée, l'entreprise réduit ses coûts de licence, de maintenance et d'administration. Par ailleurs, les économies réalisées en termes d'espace de stockage et de consommation d'électricité sont remarquables.

Consolidation des applicationsPlusieurs facteurs sont à l'origine de la consolidation des applications. On peut par exemple citer les fusions et acquisitions ainsi que les bureaux ou départements régionaux qui exécutent différentes applications pour les finances, la logistique, la gestion de projets et d'autres départements. La consolidation des applications présente notamment l'avantage de simplifier l'expérience utilisateur et de réduire les coûts.

Mise à niveau d'un système hérité vers une solution ERP Au fur et à mesure que les solutions ERP leader du marché offrent des fonctionnalités étendues et approfondies, de plus en plus d'entreprises recherchent consolidation et normalisation avec une seule suite d'applications. La mise à niveau d'un système hérité est motivée notamment par des coûts élevés, une interruption du support par le fournisseur, une prise en charge limitée des modules et des difficultés à personnaliser la solution.

Conformité réglementaireLes entreprises doivent se conformer à diverses réglementations de conservation des données qui exigent de stocker les données pendant de longues périodes. Il s'agit par exemple de la loi Sarbanes-Oxley, du règlement SEC 17a et des réglementations HIPAA et FDA. L'intensification de l'environnement réglementaire et les nouvelles réglementations nationales et européennes remettent l'accent sur l'identification des données et les stratégies de gestion des informations. Il ne suffit pas de mettre les applications héritées hors service ; les informations contenues dans ces applications doivent être classées, associées à des stratégies de conservation et de suppression ainsi qu'accessibles en cas d'audit ou de litige.

4

Déterminer si une application peut être retiréeDéterminer si une application peut être retirée revient à comparer la valeur métier fournie par l'application avec les coûts de support et de maintenance qu'elle implique. Une application peut être retirée lorsque les coûts de support et de maintenance de l'application sont supérieurs à la valeur métier qu'elle génère.

La valeur métier d'une application héritéePour faire simple, la valeur métier d'une application est une fonction de la problématique métier à laquelle répond l'application et de valeur que l'application fournit à ses utilisateurs et à l'entreprise dans son ensemble. Plusieurs paramètres (voir tableau A) déterminent la valeur métier d'une application. Tous ces paramètres doivent être analysés ensemble pour déterminer la valeur métier d'une application.

Tableau A : Paramètres déterminant la valeur métier d'une application

PaRaMèTRES DéTERMInanT La vaLEuR MéTIER D'unE aPPLICaTIon

1. À quoi sert l'application héritée ?

2. Combien de salariés, partenaires ou clients utilisent l'application ?

3. L'application est-elle utilisée régulièrement par de nombreux utilisateurs ou seulement par quelques uns ?

4. Date de la dernière utilisation. Quasiment tous les moniteurs de contrôle de production ou d'inventaire d'application enregistrent la date de la dernière utilisation.

5. De quand date l'application ?

6. Le contenu de l'application est-il activement renouvelé ou l'application sert-elle au reporting ?

7. D'autres applications de l'entreprise peuvent-elles remplir la même fonction que l'application en question ? Si oui, combien d'utilisateurs devront être formés au nouveau système et quels seront les coûts de formation et de personnalisation du nouveau système ?

Le coût d'une application héritéePlusieurs paramètres déterminent le coût d'une application héritée. Parmi ces paramètres, on peut par exemple citer les coûts de licence et de maintenance, les coûts d'administration, la complexité de l'application, le coût de personnalisation de l'application ainsi que la disponibilité des ressources pour prendre en charge et personnaliser l'application héritée. Le coût d'une application héritée doit inclure le coût de toute l'infrastructure logicielle et matérielle qui maintien l'application.

Livre Blanc


Stratégies de décommissionnement applicatifLorsque le portefeuille applicatif d'une entreprise est passé en revue pour la première fois, il n'est pas rare de trouver des centaines d'applications qui pourraient être retirées. Lors de la conception de votre stratégie de retrait des applications, il est important de tenir compte des points suivants :

Priorisation des applications pouvant être retiréesPour le retrait des applications, les priorités peuvent être définies par l'un des critères suivants ou les deux :

économies•

En commençant par les applications qui génèrent les plus grandes économies, vous -valorisez le projet de décommissionnement applicatif car vous libérez du budget et des ressources.

Connaissance de l'application et des exigences de reporting des données obsolètes•

Dans les projets de retrait d'applications, l'une des difficultés est le manque de -connaissances fonctionnelles sur l'application. Les applications héritées ayant été déployées il y a des années, une partie des salariés formés à ces applications ont aujourd'hui quitté l'entreprise ou pris leur retraite. Par ailleurs, il est difficile de trouver des personnes présentant les compétences requises lorsque les technologies sont dépassées. En commençant par des applications héritées dont le fonctionnement et les exigences de reporting sont bien maîtrisés, vous augmentez vos chances de réussite et vous ouvrez la voie au retrait d'autres applications.

Retrait de tout ou partie des données requises pour les besoins métiers et la conformité réglementaireVous devez prendre cette décision principalement en fonction de votre connaissance de l'application et des données à conserver pour le reporting, l'audit et la conformité réglementaire. Le retrait des seules données requises pour les besoins métiers est la meilleure approche pour les entreprises qui maîtrisent bien les données des applications et les exigences de reporting. Le retrait de toutes les données d'application est la meilleure approche lorsque ni le modèle de données de l'application ni les exigences de reporting ne sont parfaitement maîtrisés. Dans ce cas, le retrait de toutes les données d'application limite les risques et réduit les coûts. Toutes les données obsolètes étant accessibles, l'entreprise peut affecter des ressources à leur analyse en fonction des besoins plutôt que d'y consacrer du temps et des ressources en amont. Une solution de retrait des applications optimum permet aux clients d'ajouter des relations entre les données et de modifier ultérieurement le reporting même si les données des applications ont déjà été retirées.

Gestion d'application lorsque l'application ou le modèle de données est peu ou pas maîtriséDans ce cas, le retrait d'applications est une bonne stratégie si la valeur métier de l'application est marginale. Le retrait de l'application garantit la conservation de toutes les données. La mise hors service de l'application héritée est source d'économies pour l'entreprise. Comme indiqué ci-dessus, la possibilité d'inclure des relations supplémentaires entre les données même si les données des applications sont retirées protège l'entreprise s'il est nécessaire d'accéder à ces données par la suite.

6

Sept étapes pour réussir le retrait d'une applicationPour réussir le retrait d'une application, suivez les sept étapes suivantes :

1. Création d'une équipe interfonctionnelle

2. Compréhension de l'application héritée et des données à retirer

3. Conservation du contexte métier d'origine des données

4. Compréhension de l'accès aux données obsolètes

5. Sécurisation des données obsolètes

6. Définition de politiques de conservation

7. Sélection d'une solution pour le retrait des applications

1 . Création d'une équipe interfonctionnelleLe personnel chargé des projets de décommissionnement applicatif réussis est généralement composé d'équipes interfonctionnelles représentant la conformité, le(s) département(s) utilisateur(s) de l'application concernée et le service informatique. Le tableau B répertorie certains des rôles types joués par les membres de l'équipe.

SERvICE/fonCTIon

MEMbRES DE L'éQuIPE

RôLE

1. Conformité/audit Responsables de la conformité, auditeurs internes, consultants

Déterminer les données à retirer à des fins de conformité, la période de conservation et les contrôles d'accès sécurisés à associer aux données obsolètes.

2. Responsables de départements

Analystes métiers, responsables de départements

Décrire l'utilisation de l'application héritée ; définir les données à conserver pour les besoins métiers réguliers ainsi que le type d'accès et les rapports à exécuter sur les données obsolètes.

3. Professionnels informatiques

Responsables informatiques, administrateurs de bases de données, développeurs d'applications

Développer la stratégie de retrait des applications, évaluer les solutions pour le retrait d'applications, retirer l'application et mettre l'application héritée hors service.

Livre Blanc


2 . Compréhension de l'application héritée et des données à retirerUne bonne compréhension de l'application et du modèle de données sous-jacent assure le retrait des données requises pour les besoins métiers courants et la conformité réglementaire. Pour mieux comprendre les scénarios d'utilisation d'une application et les avantages métiers, interrogez les salariés, partenaires, clients et auditeurs qui utilisent cette application. Les réponses aux questions suivantes vous aideront à mieux comprendre l'application héritée et les données qui doivent être retirées.

Quel rôle joue aujourd'hui l'application et quel était son rôle lors du déploiement initial ?

Quels modules applicatifs ou fonctionnalités ne sont plus utilisés ?•

Quels rapports sont exécutés sur l'application ?

Si plusieurs rapports sont exécutés, peuvent-ils être consolidés ?•

Existe-t-il des applications similaires dans l'entreprise qui remplissent la fonction de l'application héritée ?

Les données doivent-elles être déplacées vers une autre application ?•

Quelles données doivent être conservées pour des raisons de conformité ?

3 . Conservation du contexte métier des données de l'applicationUne fois que vous avez compris quelles données doivent être conservées, il est important de préserver le contexte métier d'origine de l'objet de données. Par exemple, si vous retirez des bons de commande d'une application financière héritée, toutes les informations transactionnelles, référentielles et d'audit associées doivent être capturées. Les informations transactionnelles associées au bon de commande incluent chaque article acheté, la quantité, le prix et les informations d'expédition. Les informations référentielles comprennent le nom, l'adresse et les coordonnées du fournisseur. La piste d'audit inclut des détails sur la personne qui a approuvé le bon de commande et sur l'utilisateur qui l'a modifié. Ces données sont généralement stockées dans différentes tables de la base de données. Il existe des relations complexes entre les données des tables et les règles métiers qui définissent d'autres sémantiques. Cette complexité est accentuée par le fait que nombre de ces relations et règles métiers sont définies au niveau de la couche applicative et ne peuvent pas être exploitées directement à partir de la base de données.

La conservation du contexte métier d'origine des données d'application exige une connaissance de l'application et des techniques de modélisation de données avancées garantissant l'intégrité des relations entre les données et les règles métiers.

8

4 . accès aux données obsolètesPour réussir votre projet de décommissionnement applicatif, vous devez offrir un accès rapide et efficace aux données obsolètes. Les entreprises doivent avoir la possibilité d'extraire les données quelque soit leur ancienneté quand ils en ont besoin. La capacité à interroger, parcourir et générer des rapports vous permet de répondre aux audits et aux différentes requêtes. Une fois que l'application est hors service, la solution de retrait doit fournir un accès fiable et indépendant de l'application permettant d'exploiter des normes standards ouvertes telles que ODBC/JDBC, XML et SQL ainsi que des outils de reporting tels que Crystal Reports et Cognos. L'accès aux données obsolètes ne doit pas compromettre l'expérience utilisateur. Par exemple, si un système de gestion des polices d'assurance hérité est retiré, les polices doivent rester accessibles dans leur format d'origine. Tenez compte des points suivants lors du développement du plan de définition de l'accès aux données obsolètes :

Comment les utilisateurs métiers et les administrateurs accéderont-ils aux données ? De •quel format ont-ils besoin pour afficher les données obsolètes ?

Comment les auditeurs accéderont-ils aux données ? En général, à quels rapports les •auditeurs accèdent-ils ?

Quels outils de reporting connaissent les utilisateurs et les administrateurs ?•

Comment les utilisateurs rechercheront-ils des données obsolètes ?•

5 . Sécurisation des données obsolètesIl n'est pas rare qu'une application héritée contienne des informations confidentielles. Par exemple, dans une compagnie d'assurance, une application de gestion des polices peut contenir des informations personnelles sensibles. D'autres applications peuvent contenir une propriété intellectuelle qu'il convient de protéger. Lors du retrait d'applications, il est important de protéger les informations confidentielles. Tenez compte des points suivants lors du développement du plan de sécurisation des données archivées :

L'accès aux données obsolètes doit-il être réservé aux administrateurs et aux utilisateurs •privilégiés ou doit-il être autorisé à un groupe plus large ?

Faut-il appliquer la même stratégie de sécurité qui contrôlait l'accès dans l'application •héritée ou bien faut-il la renforcer ou l'assouplir ?

6 . Définition de politiques de conservation - ou de suppression - sur les données obsolètes

De plus en plus d'entreprises prennent conscience des coûts et des risques liés à la conservation des données à l'infini. Tout comme les autres informations de l'entreprise, les données obsolètes doivent être gérées conformément à la stratégie de gestion des informations à l'échelle de l'entreprise. Une solution de retrait des applications doit offrir des fonctions de gestion de stratégie complètes et une intégration avec les plates-formes de stockage qui gèrent la conservation des données ou leur suppression.

Livre Blanc


7 . Sélection d'un fournisseur pour le retrait des applicationsLe retrait des applications exigeant des fonctionnalités avancées de modélisation, d'extraction et de récupération de données, les entreprises ont tout intérêt à rechercher un fournisseur proposant une solution éprouvée de retrait des applications plutôt que de réinventer la roue. Une solution de retrait des applications doit offrir les fonctionnalités suivantes :

Modélisation des données dans l'application héritée•

Création de stratégies définissant les données à retirer•

Extraction des données•

Indexation des données pour une recherche efficace•

Accès et reporting indépendants de l'application•

Chaque entreprise a des besoins uniques en termes de projets de retrait d'applications, ce qui implique souvent un facteur de services considérable. Les fournisseurs disposant d'une expérience approfondie dans l'archivage d'importants volumes de données issues d'applications structurées, de capacités éprouvées en gestion de projets et de meilleures pratiques d'implémentation ont vraiment un avantage indéniable.

Quelle est l'approche d'Informatica en termes de décommissionnement applicatif ?Informatica fournit une gamme de produits qui gère le cycle de vie complet des données dans les applications. Informatica® Application Information Lifecycle Management™ (ILM) est spécialement conçue pour relever le défi que représente le retrait d'applications, et ce grâce à plusieurs fonctionnalités.

Classement et extraction des enregistrements métiersDes techniques de modélisation de données avancées vous permettent de classer et d'extraire des sous-ensembles de données liés qui représentent l'objet métier. Le contexte d'origine de l'objet métier est conservé dans un format compatible avec l'audit et facilement accessible pour la conformité et les besoins métiers réguliers. Au cas où les données obsolètes devraient faire l'objet d'une nouvelle analyse par la suite, des relations supplémentaires peuvent être créées entre les données.

accès transparent et sécurisé aux données obsolètesLa solution Application ILM d'Informatica propose différentes façons de garantir la sécurité suffisante des données obsolètes et leur accessibilité à la demande dans le cadre des activités courantes ainsi que pour les audits et autres requêtes. Informatica fournit plusieurs options d'accès et de sécurisation des données inactives :

Les données obsolètes sont accessibles via des méthodes de reporting standards telles que •ODBC/JDBC et SQL et des outils de reporting tels que Crystal Reports.

La recherche de données d'applications obsolètes peut être effectuée à l'aide du module •de recherche de données disponible avec la solution Application ILM d'Informatica.

10

Conformité aux réglementations de conservation, de suppression et de confidentialité des donnéesLa solution Application ILM d'Informatica fournit un ensemble complet de fonctionnalités garantissant la sécurisation des données obsolètes et leur conservation, ou leur suppression, pendant la période spécifiée par les réglementations. Un gestionnaire de polices associe les données obsolètes aux périodes de conservation appropriées. L'intégration à des plates-formes de stockage haut de gamme telles que NetApp Enterprise Storage, EMC Centera, IBM Tivoli et Sun StorageTek protège les données obsolètes et la période de conservation de toute modification mal intentionnée. Le reporting et la recherche d'information garantissent l'accessibilité des données obsolètes en cas d'audit ou de litige.

Implémentation de stratégies de stockage à plusieurs niveauxL'accès aux données obsolètes étant peu fréquent et la modification de ces données généralement inexistante, il est possible de les stocker dans une infrastructure moins onéreuse. Les entreprises réalisent des économies et libèrent du stockage haut débit pour leurs besoins métiers critiques. De plus, une fois que les données obsolètes sont stockées dans plusieurs petits fichiers XML/CSV, elles peuvent être gérées plus efficacement par des périphériques HSM ou un gestionnaire de stockage à plusieurs niveaux.

Diagramme présentant l'architecture de la solution Informatica pour le retrait d'applications

CRM

ERP

Ressource numérique

Systèmes mainframe

MoteurInformaticaData ArchiveConservation,archivage etdestruction

basés sur une politique

Données,Métadonnées,Conservation,

Sécurité

eDiscovery Gateway

Storage Gateway

NetApp / EMC / HDS / Sun

Fast Google Dieselport Kazeon

RequêtesConformité/

AuditProduction

Objet archiveRègle métierStratégies

Collections d'index

NAS DAS SAN CAS

Flux de processus Flux de processus

Création de contenuStratégie d'archivage et extraction de données Indexation et stockage Demandes d'information

Applications héritées

Archivagede fichiersoptimisé

Livre Blanc


À PRoPoS D'InfoRMaTICa

Informatica permet aux entreprises de fonctionner plus efficacement dans un contexte d'économie mondialisée, en leur donnant les moyens d'accéder et d'intégrer leurs multiples ressources de données en toute confiance. Leader indépendant de l'intégration de données, Informatica a prouvé sa capacité à aider les plus grandes entreprises dans l'exploitation de toutes leurs données pour accroître leur chiffre d'affaires, leur rentabilité et la fidélité de leurs clients.

L I V R E B L A N C

Siège mondial, 100 Cardinal Way, Redwood City, CA 94063, États-UnisTéléphone : +33 1 42 04 89 00 (France) www.informatica.com/fr

Informatica dans le monde : Allemagne • Australie • Belgique • Canada • Chine • Corée • Espagne • États-Unis • France • Irlande • Italie •Japon • Pays-Bas • Portugal • Royaume-Uni • Singapour • Suisse

© 2009 Informatica Corporation. Tous droits réservés. Imprimé aux États-Unis. Informatica, le logo Informatica et The Data Integration Company sont des marques commerciales ou déposées appartenant à Informatica Corporation aux États-Unis et dans d'autres pays. Tous les autres noms de sociétés et de produits sont la propriété de leurs détenteurs respectifs et peuvent avoir fait l'objet d'un dépôt de marque.

6957FR (30/03/2011)

guide pratique pour le décommissionnement...

Documents