Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Architecture

Architecture

Évolution des systèmes d'information

Mainframe => monolithique, peu évolutif, coût élevé
Screenshot from 2015-04-10 09:30:48

Au début de l'informatique existait le mainframe, une boîte noire qui contenait toute l'intelligence, la mémoire et la puissance de calcul
d'une entreprise. Apparus dans les années 50 et démocratisés dans les années 60-70 les mainframes sont souvent associés à IBM qui tenait
près de 90 % du marché. Cette boite était considérée à l'époque comme le saint Graal d'une entreprise moderne.

Les besoins et les capacités informatiques de l'époque étaient limités et le mainframe apportait une solution clé en main contenue dans un serveur unique. On retrouvait en son sein une application monolithique qui traitait les données, gérait leur persistance et les présentait. Qui
dit serveur unique, dit défi technique, auquel il a fallu répondre dans leur conception pour assurer une haute disponibilité et une intégrité des données. Cela a eu pour conséquence des coûts de développement et donc d'acquisition très élevés pour les entreprises. En contre partie, le système avait l'avantage d'assurer une cohérence et une fiabilité importante au sein du SI.

Client lourd /serveur => silo applicatif, redondance, utilisation complexe
Screenshot from 2015-04-10 09:32:22

Dans les années 80 les ordinateurs individuels font leur apparition. Petit à petit les mainframes disparaissent pour laisser place à un modèle client-serveur. La NASA a ainsi éteint son dernier mainframe, IBM System Z9, en 2012.

Cette nouvelle architecture est basée sur le principe que l'on découple la couche de présentation, gérée directement sur un poste client, et un serveur, conservant les traitements et la gestion de la persistance des données.

Ce découpage a permis de simplifier la conception du côté serveur et à donc eu pour conséquence une baisse des prix et donc un engouement des entreprises pour son utilisation.

L'informatique, jusqu'à présent cantonnée à de très grandes entreprises ou institutions, commence à être utilisée plus largement dans les grandes et moyennes entreprises. Cet
engouement provoque des complications non prévues à l'époque. Une entreprise étant en général constituée de plusieurs métiers ayant des besoins propres, il a fallu multiplier les serveurs et les applications clientes.

L'architecture des systèmes d'information des entreprises s'est brutalement complexifiée. Des silos applicatifs et de la redondance fonctionnelle entre application sont apparus faute de gouvernance. Les couches de présentation sur les postes clients se sont multipliées et, faute d'une réflexion globale, sont extrêmement hétérogènes à l'utilisation. Cela les rend difficilement maîtrisables par les utilisateurs finaux. De nouveaux concepts et métiers sont alors apparus pour éviter l'anarchie. La gouvernance des Systèmes d'information apparaît avec notamment la notion d'urbanisation du SI, ou d'Enterprise Architecture, dans les pays anglo-saxons.

Clients web / serveurs => fragmentation
Screenshot from 2015-04-10 09:34:53

A la fin des années 90, avec le développement des réseaux d'entreprise et de l'internet, apparaît une nouvelle famille applicative : les applications web, plus légères que leurs consœurs car basées sur un outil commun, le navigateur web.

Celles-ci sont en général uniquement composées de fichiers de paramétrages de présentation et d’interaction avec les données (HTML, CSS, JavaScript).

C'est dans un premier temps un petit retour en arrière car le traitement est de nouveau entièrement supporté par des serveurs d'applications.

Cependant, ce retour apporte des gains en termes de flexibilité, de simplicité et réduit donc les coûts de la partie client.

Accompagnant cette révolution, les architectures n-tiers font leur apparition. Elles décomposent le système en modules dédiés à une tâche particulière. La plus utilisée est probablement l'architecture 3-tiers : présentation, métier, accès/stockage des données. Il est ainsi plus facile de maintenir et faire évoluer les différentes briques applicatives mais ce type d'architecture entraîne un effet pervers en augmentant la fragmentation du Système d'information pour lequel une gouvernance devient obligatoire

Cloud computing => non maîtrise de son SI
Screenshot from 2015-04-10 09:36:57

Durant les années 2000, avec l’essor de l'internet, de l'augmentation de la capacité et de la fiabilité des réseaux, un nouveau concept apparaît, le cloud computing. L'idée étant de sous-traiter à des tiers une partie du SI ou des applications spécialisées et de ne payer que leur réelle utilisation. Ces spécialistes mettant leur plate-forme à disposition de plusieurs entreprises clientes, il en résulte une mutualisation des coûts de
structure qui font baisser le coût global des applications.

Cette démarche, pose actuellement des questions sur la sécurisation des données, leur protection juridique et leur difficulté d'intégration avec le SI interne des entreprises. Encore une fois, cette évolution augmente la fragmentation et complexifie la gouvernance des SI par
les entreprises qui de plus deviennent dépendantes de SI tiers.

Urbanisation des systèmes d'information

Dans les années 80, l'urbanisation, jusqu'à présent cantonnée à l'organisation du territoire, est reprise par le secteur bancaire qui se retrouve confronté à des besoins de simplification et de rationalisation de leur SI comportant plusieurs milliers d'applications. Ces entreprises n'ont plus le contrôle de leur SI car il est devenu trop complexe. Elles ont cherché des approches dans d'autres secteurs d'activités qui auraient des problématiques similaires. Ce portage de l'urbanisation du territoire au système d'information est réalisé en parallèle en Europe et aux États-Unis où cette science sera appelée Enterprise Architecture.

Par extension, l'urbanisation d'un système d'information est une démarche qui consiste à anticiper et à faire évoluer le système d'information d'une entreprise dans son ensemble en fonction de :

  • sa stratégie
  • son organisation
  • ses contraintes internes et externes (délais, coûts, législation, etc.).

Afin de garantir :

  • ses objectifs métiers
  • sa simplicité
  • sa cohérence.

La démarche d'urbanisation va permettre de :

  • se ré-approprier son SI
  • faire évoluer son SI en fonction des besoins
  • harmoniser ses composants
  • maîtriser l’entropie.
  • réaliser des économies

Cette démarche est en général mise en œuvre dans les grandes entreprises au sein d'un cabinet d'urbanisme rattaché à la DSI ou directement à la direction de l'entreprise.

L'urbanisation est basée sur une référence à 4 niveaux de vision :

Screenshot from 2015-04-10 09:41:34
  • Métier : Qui fait quoi et pourquoi ?
  • Fonctionnelle : De quoi a-t-on besoin pour réaliser les processus métiers ?
  • Applicative : Que va-t-on mettre à disposition ? Qui implémentera les fonctionnalités demandées ?
  • Physique : Où se trouvent ces applications ?

Ces niveaux vont permettre de réaliser une cartographie précise du système d'information en utilisant les concepts de l'urbanisation des villes.

On découpera ainsi le SI en :

Screenshot from 2015-04-10 09:43:09
  • Zone : métier de l'entreprise
  • Quartier : contenu dans une zone et ayant un type commun d'informations traitées
  • Îlot : contenu dans un quartier et étant un ensemble de traitement et de données homogènes

Chacun de ces blocs ainsi défini évolue indépendamment et interagit avec les autres via des interfaces publiques et des zones d'échanges, les routes.

SOA: service oriented architecture

Le concept de Service Oriented Architecture, ou SOA, a été inventé par Yefim V. Natis, un analyste de Gartner, qui a publié le 12 avril 1996 une note de recherche1 sur les orientations architecturales des SI portant ce nom. Il définissait le SOA comme : «  une architecture logicielle qui commence par la définition des interfaces et l'élaboration d'une application entièrement basée sur leurs implémentations et les appels à celles-ci. »

Cette publication est restée longtemps inaperçue et ce n'est qu'en 2001 que l'on en entend de nouveau parler avec l’essor des web-services. Dans les années suivantes l'OASIS group et l'Open Group reprennent le concept et s'attaquent en parallèle à sa définition concrète. Ce n'est qu'en octobre 2006 qu'une définition claire de ce qu'est le modèle SOA est officiellement publiée par l'OASIS Group2. En avril 2009 L'Open Group sort sa propre définition au sein de sa publication SOA Source Book3.
SOA n'est pas une architecture mais un concept philosophique qui repose sur l'urbanisation de SI et concrétise sa vue fonctionnelle en une vision de services.

Deux éléments majeurs dans toutes les définitions qui lui sont données sont à respecter :

  • le SI doit être entièrement basé sur des services (web ou non)
  • chaque service doit être autonome et doit avoir un couplage faible avec ses clients

Ces objectifs sont de :

  • rendre flexible le SI (ou agile) pour le faire évoluer rapidement
  • qu'une fonctionnalité ait une unique implémentation qui pourra être réutilisé plusieurs fois
  • réduire les coûts d'intégration en se basant sur des standards de communication et des interfaces publiques
  • pouvoir créer des applications composites qui puissent utiliser plusieurs services.

Attention, SOA n'étant qu'un concept philosophique, il n'impose pas une architecture précise ou les types d'implémentations utilisables. Cela dit, si l'on suit la définition faite par certains groupes ou entreprises, certains protocoles ou patrons architecturaux sont recommandés.

(SOAP, WS-*).

Service

Un service est un composant du SI qui met à disposition un accès vers une ou plusieurs fonctions métiers.

Un service se doit d'être simple d'emploi, réutilisable et interopérable. C'est le lien entre des consommateurs se trouvant dans la couche métier et des fournisseurs qui implémentent une ou plusieurs fonctionnalités. Un service pourvoit ces fonctionnalités en exposant des opérations via une interface publique et respecte un contrat de service.

Un service est sans état, il ne conservera aucune mémoire sur le contexte de son utilisation.

Un service doit respecter au minimum l'un de ces critères :

  • mutualisation : il est utilisé par au minimum 2 clients
  • facilitateur : il permet l’interopérabilité avec un autre SI
  • nécessaire : il est utilisé dans une composition.
Contrat de service

Un contrat de service est clairement défini pour chaque service mis à disposition.
Il contient :

  • son ou ses adresses
  • la signature des opérations (nom, structure et format du message de requête, structure et format du message de réponse)
  • les protocoles disponibles
  • ses garanties via un contrat de Service Level Agreement (SLA)
    • performance
    • disponibilité
    • sécurité
    • temps de rétablissement
    • pénalités de non respect
    • support mis à disposition
    • Etc.
  • les directives à respecter par le client
    • nombre d'erreurs acceptables
    • sécurisation des données d'authentification
    • etc.
  • des outils de mesures mis en œuvre pour vérifier les garanties et les directives.