L'architecture doit s'intégrer au paysage

Si vous voulez optimiser votre architecture SAP, la première question que vous devez vous poser est la suivante : que voulez-vous obtenir avec cette architecture ? Ce n'est que lorsqu'il y aura une réponse à cette question que votre environnement informatique pourra être optimisé.

Souhaitez-vous par exemple réduire en premier lieu les charges administratives élevées ainsi que les coûts de votre exploitation informatique ou plutôt miser sur une plate-forme stratégique pour l'avenir ?

Les entreprises devraient y réfléchir attentivement, car la stratégie qu'elles adopteront et les mesures qu'elles mettront en œuvre dépendront de cette réponse. Elles peuvent soit mener ce processus seules, soit demander conseil à des sociétés de conseil spécialisées.

Dans tous les cas, il est important de disposer d'une base de décision basée sur des faits plutôt que sur des hypothèses et des perceptions. Une condition préalable importante est donc d'analyser l'infrastructure informatique :

Combien de solutions SAP fonctionnent sur la plate-forme et combien devraient-elles être à l'avenir ? Quel est le niveau de disponibilité et de résilience des systèmes, et qu'est-ce qui est prévu ? Des modifications de l'infrastructure sont-elles déjà en cours ? Une conversion in-memory est-elle prévue ?

Sur la base des données ainsi collectées, il est possible d'identifier les points faibles, les goulets d'étranglement ou les exigences des départements spécialisés. Cela permet également de limiter dès le départ le choix des plateformes cibles possibles.

Miroir, miroir sur le mur, ...

... quelle est la meilleure plateforme dans tout le pays ? De nombreuses entreprises se posent cette question, par exemple, lorsque la fin du leasing du matériel informatique approche ou que celui-ci est amorti.

C'est une bonne chose, car la plate-forme est d'une importance capitale pour une architecture optimale des solutions SAP. Dans le domaine classique de l'ERP SAP, il y a le choix entre Microsoft, Linux, HP-UX ou IBM AIX ainsi que OS/400 et Solaris.

Les raisons de passer d'une plateforme à celle d'un autre fournisseur peuvent être multiples : par exemple, parce que cela permet de consolider le paysage informatique ou parce qu'une autre plateforme est considérée comme plus pérenne que celle utilisée actuellement.

Actuellement, les mots-clés dans l'environnement SAP sont Hana et Linux. Il faut également examiner dans quelle mesure les solutions SAP peuvent être échelonnées ou virtualisées sur une plateforme et quels sont les coûts.

Il y a des années, de nombreuses entreprises sont passées d'Unix à Linux, car celui-ci est très stable et compatible avec d'autres systèmes. De plus, les coûts matériels, par exemple pour la puissance du processeur, sont moins élevés que pour d'autres plates-formes.

De plus, lors d'un tel changement, il est possible de conserver de nombreuses procédures et d'utiliser les connaissances existantes, ce qui limite les besoins en formation.

La disponibilité est un sujet épineux. La définition même de ce que l'on entend par haute disponibilité met parfois les entreprises dans l'embarras. La haute disponibilité se réfère-t-elle au fonctionnement garanti d'un système ou inclut-elle la possibilité d'absorber la panne éventuelle d'un centre de calcul entier ?

Pour des raisons de sécurité, la distance physique avec un deuxième centre de calcul doit être suffisamment grande. D'un autre côté, elle ne doit pas dépasser une certaine distance, sinon il est difficile de maintenir la synchronisation des données.

Si un centre de données est situé en Europe et un autre aux États-Unis, ils ne sont pas synchronisés à 100 %, car il est impossible de mettre en miroir les données en temps réel à cette distance sans affecter l'application.

Éviter les monopoles de tête

Moins, c'est parfois plus : en matière d'architecture, il n'y a pas que les hard facts comme le prix du matériel ou la disponibilité qui comptent. À quoi sert une plate-forme moins chère si elle ne soutient pas les processus de manière optimale ou si les collaborateurs n'ont pas la formation nécessaire ?

Lorsque les entreprises souhaitent passer à une autre plateforme, il faut également se demander si les collaborateurs disposent des connaissances nécessaires et, si ce n'est pas le cas, quelles formations ils doivent suivre pour que la nouvelle plateforme soit bien adoptée et exploitée.

Un changement de plate-forme devrait toujours s'accompagner de processus de gestion du changement. Ceux-ci ne devraient pas seulement porter sur la migration technique, mais aussi préparer les collaborateurs aux changements.

Cela permet en outre d'éviter les monopoles de tête, dans lesquels les connaissances sont concentrées sur un seul collaborateur. Si ce dernier est absent ou quitte l'entreprise, son savoir-faire disparaît également.

Il peut donc être préférable de choisir une plateforme un peu plus simple techniquement, avec laquelle plusieurs collaborateurs sont à l'aise, plutôt qu'une variante premium sophistiquée et hautement disponible qu'un seul collaborateur maîtrise.

Or, les offres des fabricants visent généralement la performance technique. Cela peut conduire à un matériel surdimensionné ou "over-engineered".

La devise pour les entreprises est donc la suivante : la plate-forme doit rester exploitable. Moins, c'est parfois plus. D'autant plus que les dépenses pour des formations supplémentaires peuvent représenter jusqu'à 15% des coûts techniques.

Les sociétés de conseil professionnelles préparent les résultats de l'analyse de la situation actuelle, leurs recommandations ainsi qu'une liste des dépenses nécessaires sous la forme d'une étude pertinente.

En outre, les avantages et les inconvénients des plates-formes envisagées sont énumérés. Sur cette base, il est possible de décider de la marche à suivre en se basant sur des faits.

Lors de la migration, il est recommandé de commencer par un petit système, en quelque sorte à titre de test, suivi par les autres systèmes, éventuellement regroupés.

Après deux mois, les données de performance devraient être collectées afin de mesurer le succès. Si le délai d'attente est plus long, d'autres adaptations - les paysages informatiques sont soumis à des changements permanents - pourraient rendre impossible une mesure comparable.

Exemples de migrations réussies vers Linux

Le groupe Generali a décidé de moderniser son infrastructure SAP. Environ 100 serveurs et bases de données, 24 lignes de systèmes pour 14 pays ainsi que 100 téraoctets de données devaient être transférés sur une nouvelle plateforme cible.

L'infrastructure existante devait être mise à jour avec l'aide d'un prestataire de services, tout en réduisant la dépendance vis-à-vis d'un seul fournisseur de matériel, afin d'assurer la pérennité des investissements.

Après un atelier, une feuille de route, une matrice de risques, une analyse, une estimation des coûts ainsi qu'une preuve de concept, les systèmes ont été migrés vers Linux avec succès et de manière durablement rentable, deux mois plus tôt que prévu initialement.

La preuve de concept a justement été un facteur de succès important pour Generali, car elle a donné au groupe la certitude d'avoir choisi la bonne stratégie.

En moins de 20 mois, Munich Re a également transféré son architecture de serveur, y compris 84 systèmes SAP, sur une plate-forme Linux. Une partie des données a été convertie en Unicode lors de la migration.

La gestion du changement a représenté un défi particulier, car parallèlement à la migration, l'entreprise a introduit la plus grande application SAP au niveau mondial.

En outre, l'exploitation de l'infrastructure a été transférée dans un modèle de délocalisation. Grâce à des plans de coupure spéciaux, il a été possible de migrer simultanément jusqu'à six systèmes SAP en l'espace de quelques semaines.

Tous les objectifs de coûts ont pu être atteints sans que l'activité et la disponibilité des applications n'en soient affectées. Munich Re a réussi à réduire les coûts d'acquisition des serveurs SAP à un cinquième de l'investissement initial.

Depuis la migration, les applications et les bases de données fonctionnent sur des serveurs dotés d'une architecture de processus uniforme. La standardisation a en outre permis de réduire considérablement les coûts d'exploitation.

L'exigence va augmenter

Un conseil global en architecture tient compte non seulement d'aspects tels que l'évolutivité et la disponibilité, mais aussi de facteurs organisationnels et financiers. Si une entreprise de conseil ne commercialise pas également du matériel, le client peut être sûr de bénéficier d'un conseil indépendant.

Lors de la migration vers une nouvelle plate-forme, il ne faut plus seulement tenir compte de la performance technique, mais aussi mettre l'accent sur des composants stratégiques comme la pérennité.

En outre, il est recommandé de vérifier les processus et éventuellement de les adapter. Une approche basée sur l'ITIL s'impose à cet effet. Dans l'environnement SAP, Hana et les possibilités offertes par le cloud vont faire augmenter les exigences en matière de conseil en architecture dans les années à venir. Un savoir-faire supplémentaire sera nécessaire.

Un conseil en architecture basé sur une stratégie et une vision à long terme vous conduira néanmoins sereinement vers votre nouvelle architecture cible grâce à un concept cohérent.

Néanmoins, le mot d'ordre reste le même : ce n'est pas ce qui est techniquement réalisable qui devrait être déterminant, mais toujours ce qui convient au paysage. Voir l'opéra norvégien.