Corporate Finance, DeFi, Blockchain, Web3 News
Corporate Finance, DeFi, Blockchain News

Quelles applications métier en 2015 ?

Les personnes chargées du support des applications métier subissent des contraintes de plus en plus fortes du fait de l'arrivée des nouvelles technologies et des nouvelles demandes du marché. Quel que soit le secteur dans lequel on évolue, les fusions-acquisitions, les nouvelles réglementations et la concurrence se traduisent par un rythme de changement effréné. Comment mettre au point des applications respectueuses du passé (en évitant les coûts liés au remplacement), qui s'adaptent au présent sans compromettre l'avenir ?


Guido Falkenberg
Guido Falkenberg
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 :
- 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) ;
- 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 ;
- évolue en fonction des contrats de services définis (par ex., temps de réponse, utilisateur simultané) ;
- soit conçue pour permettre la surveillance des activités métier ;
- offre plusieurs possibilités de déploiement des règles métier (par ex. code, moteur de règles) ;
- garantisse la fiabilité et la régularité des transactions même lorsqu'elle doit traiter des volumes de données imprévisibles ;
- 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) ;
- 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 ;
- 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 ;
- 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 ;
- permette de reconnaître et d'enregistrer toutes les applications de façon transparente et gérable ;
- 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.

La réalité va-t-elle dépasser le rêve ?


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 plupart des processus métier comporteront sans doute toujours un mélange de code et de SOA/BPM. La future architecture des applications métier 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 Guido Falkenberg, Vice President, Deputy CTO, Software AG
www.softwareag.com

Dimanche 4 Octobre 2009




OFFRES D'EMPLOI


OFFRES DE STAGES


NOMINATIONS


DERNIERES ACTUALITES


POPULAIRES