Que seront devenues les applications métier en 2015 ?

Par Guido Falkenberg, Vice President, Deputy CTO, Software AG

La réactivité technologique aujourd’hui

Avant d’envisager de nouveaux modèles, il est important de comprendre comment les applications métier sont aujourd’hui mises en œuvre. La majeure partie de la logique métier (processus, workflows, règles et fonctions) est encore contenue dans des applications personnalisées ou clés en main. Les architectures d’applications multi niveaux (par exemple client-serveur) et les solutions d’intégration (comme le middleware, l’ETL, les processus de traitement par lots) étendent cette logique métier à d’autres systèmes informatiques, qui, à leur tour, interagissent avec cette logique ou ces informations métier et poursuivent son traitement à des fins d’interaction avec l’utilisateur final, de génération d’états, d’analyse, d’échange de données ou de calculs complémentaires.

Dans un contexte de changement, toutes ces applications n’ont pas la même souplesse, sachant que les évolutions interviennent généralement dans l’un des domaines suivants :
•    Modification du code source ou développement d’un nouveau code source
•    Modification des paramètres de personnalisation (par exemple dans les applications clés en main)
•    Application de modifications à chaque niveau d’application, notamment en cas de modification des structures de données
•    Adoption de l’infrastructure système (pour une meilleure évolutivité, par exemple)

En outre, les informations et les données constituant une entité logique (comme un client ou une commande) sont pratiquement toujours réparties sur différents systèmes d’information (bases de données, fichiers, systèmes de gestion de documents, entrepôt de données), et il est donc difficile d’obtenir une vue complète d’un client ou d’une commande.
Ces approches sont dépassées et erronées car elles continuent de cloisonner une logique complexe dans des silos (en choisissant la voie de la facilité quitte à compromettre la réactivité future). Il est beaucoup plus facile de ne rien changer que d’imaginer une meilleure façon de résoudre les problèmes actuels (sans faire peser de menaces sur l’avenir). Toutefois, vous aurez peut-être toujours besoin des qualités opérationnelles de ces applications (notamment leurs performances ou leur disponibilité) en ce XXIe siècle.

La réactivité demain… et plus tard

Si l’on fait passer la logique des grands systèmes vers les systèmes distribués, on ne fait que déplacer les coûts et la complexité. Cette méthode n’engendre aucune nouvelle fonctionnalité ou réactivité commerciale et ne permet pas de tirer vraiment parti des investissements déjà réalisés.
Au lieu de déplacer la logique d’un code complexe à un autre, on a tendance aujourd’hui à lui donner de l’importance au sein de l’entreprise et à mettre en avant les services et processus métier de sorte que chacun prenne conscience de leur valeur.

Imaginez que vous puissiez mettre au point une application métier :
•    qui applique dynamiquement les changements de structures de données à tous les niveaux des applications (par exemple, d’une base de données jusqu’à une couche interface utilisateur) ;
•    qui restitue automatiquement les informations, en fonction du dispositif utilisateur final connecté (PC, Netbook, PDA, téléphone portable) et du contexte dans lequel se trouve l’utilisateur final ;
•    qui évolue en fonction des contrats de services définis (par ex., temps de réponse, utilisateur simultané) ;
•    qui soit conçue pour permettre la surveillance des activités métier ;
•    qui offre plusieurs possibilités de déploiement des règles métier (par ex. code, moteur de règles) ;
•    qui garantisse la fiabilité et la régularité des transactions même lorsqu’elle doit traiter des volumes de données imprévisibles ;
•    qui offre des capacités de traitement unifiées, quels que soient l’emplacement de stockage des données et leur structure (par ex. enregistrements de base de données, systèmes de gestion de documents, feuille de calcul Excel, archives, entrepôt de données) ;
•    qui développe des services et des événements réutilisables quel que soit le modèle de langage de programmation ou le protocole de communication sous-jacent ;
•    qui exécute les processus métier en continu, même lorsque le portefeuille d’applications évolue ou que de nouvelles stratégies de sourcing sont adoptées ;
•    qui synchronise et automatise les processus métier sur l’ensemble des applications informatiques, systèmes de télécommunication et environnements de traitement par lots ;
•    qui permette de reconnaître et d’enregistrer toutes les applications de façon transparente et gérable ;
•    qui fasse participer activement les utilisateurs finals de l’entreprise au processus de développement, par exemple en leur faisant concevoir les interfaces utilisateur et les règles et processus métier en mode interactif et collaboratif.

Cela semble trop beau pour être vrai ? Vous avez peut-être raison, mais rapprochons certains éléments stratégiques que nous observons déjà dans le monde de l’informatique actuel. Il y a dix ans, pensiez-vous que vous utiliseriez votre application bureautique dans un « nuage » (grâce à la technologie SaaS, ou « Software as a Service »), sans savoir où elle est hébergée, et qu’elle serait toujours suffisamment souple pour évoluer en fonction de vos besoins en termes de volumes de données ? Aviez-vous imaginé que les entreprises pourraient bénéficier d’une transparence totale sur toute leur chaîne logistique et prendre en temps réel le pouls de leurs activités ? Ou encore, aviez-vous imaginé que les processus métier pourraient ne pas être affectés par les modifications apportées aux applications et changer de façon dynamique leur comportement en fonction des analyses de tendance/prédictives ou des décisions ponctuelles des parties intéressées ?
La réponse à presque toutes ces questions est vraisemblablement un « NON » franc et massif, ou du moins un « peut-être » sceptique, selon le type d’application métier qui vous concerne (par exemple RH, ERP ou CRM).

Dans le domaine informatique, les tendances actuelles telles que l’architecture orientée services (SOA), la gestion des processus métier (BPM), le pilotage des activités métier (BAM), les applications Internet riches (RIA), le Software as a Service (SaaS), la virtualisation et dimensionnement à base de règles des ressources système, sont aujourd’hui accessibles et ont prouvé leur efficacité dans de véritables scénarios client. Ce sont là quelques-uns des premiers composants de base des applications qui vont construire notre avenir, et en s’interconnectant de plus en plus harmonieusement, les éléments stratégiques du monde informatique renforceront la dynamique des applications métier.

Les futures architectures des applications métier seront construites sur un modèle hybride variable dans lequel la technologie sera utilisée selon la meilleure approche dynamique en fonction des types de processus métier à prendre en charge. La figure 1 montre comment différents types de processus restent dans une zone de mise en œuvre axée sur le code (le processus A correspond par exemple à des processus de traitement par lots avec une clôture des comptes en fin de mois) ou dans une zone axée sur la SOA/BPM (le processus C pouvant correspondre à des processus d’approbation de commandes axés sur le workflow et faisa
nt intervenir plusieurs applications).

La plupart des processus métier comporteront sans doute toujours un mélange de code et de SOA/BPM (avec ainsi, pour le processus métier C, une proportion de 20 % de code et de 80 % de logique SOA/BPM). La future architecture des applications métier vous offrira la souplesse nécessaire pour déplacer les processus d’une zone à une autre, ce qui sera essentiel du point de vue de la rapidité et de l’adaptation au changement (par exemple de A à B). Software AG s’est donnée pour mission de relier entre eux ces composants de base afin de vous aider à mettre au point des applications métier prêtes pour 2015 et au-delà.