L’infrastructure technique d’après les principaux Framework

Gaël HérentCet article présente l’infrastructure technique telle qu’elle est décrite dans les principaux Framework. Dans cette optique, il est intéressant d’aborder dans un premier temps les différents usages types de cette vue afin d’en saisir les principaux enjeux puis, les réponses apportées par ces Framework.

Dans quels cas l’infrastructure technique s’applique-t-elle ?

D’après le Club-Urba EA1, les principaux emplois de l’axe d’analyse infrastructure technique consistent à définir les grandes orientations concernant l’infrastructure technique, qualifier le dimensionnement des artères, des plateformes et des réseaux sur la base des éléments volumétriques recueillis au niveau applicatif, définir les dispositifs de l’architecture technique en fonction des niveaux de service à atteindre. On s’intéressera ainsi à la performance des applications, les délais de remise en état en cas de dysfonctionnement, ou le niveau de sécurisation à concrétiser.

Cette analyse permet également d’élaborer des recommandations d’outils d’infrastructure technologique, permettant de converger vers une plus grande standardisation, et de traiter les thèmes techniques concernant :

– Le choix des modèles d’architecture technique logique en N couches
– La communication inter applicative et inter-SI
– L’organisation des données
– La supervision, les performances et la sécurité

Les réponses apportées par les différents Framework

Le Club-Urba EA

Le Club-Urba EA, dans l’ouvrage « Urbanisation du SI« 2 , définit l’architecture technique de la manière suivante:

« Il s’agit de la structuration des moyens d’infrastructure technique à mettre en œuvre pour informatiser l’activité de l’entreprise ou de l’organisme. Il s’agit donc de la description et de l’organisation des différents moyens matériels (central, serveur, poste…), des logiciels de base (système d’exploitation, SGBD, etc.) ainsi que des moyens de communication entre elles (réseaux).« 

De plus, il distingue trois niveaux d’infrastructure technologique :
– Primaire : joue un rôle pour l’ensemble du SI
– Secondaire : joue un rôle pour une zone fonctionnelle ou quelques quartiers fonctionnels
– Tertiaire : joue un rôle pour un îlot fonctionnel ou un groupe d’îlots fonctionnels

Et précise que dans le cadre d’un projet d’urbanisation du SI, il convient de ne tenir compte que des niveaux primaires et éventuellement secondaires pour quelques points fondamentaux. Au-delà, les niveaux secondaire et tertiaire dans leur ensemble relèvent plutôt de l’architecture technique à proprement parler que du niveau d’architecture technique du cadre de référence de l’urbanisme.

TOGAF

TOGAF propose l’utilisation de la taxonomie3 du référentiel TOGAF Technical Reference Model (TRM) pour la structuration de la vue technique, nommée « Application Platform« .

Technical reference model

Les différents niveaux sont :
– « Applications » : représente les applications offrant des fonctionnalités de haut niveau répondant aux besoins métier de l’entreprise. Elles sont réparties en deux sous-groupes en fonction de leur degré de spécialisation, « Business Applications » pour les applications propres à un métier comme la modélisation de données géologiques, et « Infrastructure Applications » pour les applications plus répandues de type calendrier ou édition de documents.

– « Application Platform » : représente les services techniques offerts afin de permettre le fonctionnement des « Applications »
– « Communications Infrastructure » : représente tous les éléments matériels et logiciels de communication utilisés par les couches basses du modèle OSI4
– Les interfaces : représentent la façon dont on appelle les services des différentes couches (signature des services : argument d’appel, type de retour) mais aussi les structures de données et les protocoles utilisés afin de favoriser au maximum un couplage faible entre les différents niveaux

La taxonomie est structurée de façon à ce que chaque service technique appartienne à une unique catégorie tout en représentant tous les services techniques possibles. Ainsi, un composant technique cible n’implémentera que les services nécessaires au bon fonctionnement des fonctions de haut niveau (« Applications »). Cette taxonomie est, pour l’infrastructure technique, l’équivalent de ce qu’est la couche fonctionnelle à la vue applicative : un modèle fortement cohérent, faiblement couplé et intangible posant une base solide indispensable à toute analyse des redondances entre applications.

Remarque : Il est important de préciser que cette taxonomie permet principalement la définition des terminologies puisque la catégorisation en elle-même peut/doit être adaptée aux besoins de l’entreprise.

DoDAF V2.0

DoDAF5 présente les données composant le référentiel par point de vue. Deux de ces points de vue contiennent des informations concernant la vue technique : « Standards Viewpoint » et « Systems Viewpoint« .

A/ Standards Viewpoint

Les modèles produits représentent un ensemble de règles gouvernant les interactions et les interdépendances. Ces ensembles de règles sont capturés au niveau de l’entreprise et appliqués à toutes les solutions. Cela concerne, entre autres, les technologies :

– Standard de notation tels UML ou UML Profile for DoDAF/MODAF (UPDM)
– Normes réseau (protocoles) de type IP et TCP
– Standard de sécurité comme RSA ou PKI

Cela inclut les technologies matures (et leurs évolutions à court/moyen/long terme) et les technologies émergentes. Le cycle de vie des technologies est donc pris en compte.
De plus, pour structurer ce point de vue, DoDAF impose l’utilisation du référentiel des standards IT « DoD Information Technology Standards and Profile Registry » (DISR).

B/ Systems Viewpoint

Ce point de vue contient un modèle (« SV-9 Systems Technology & Skills Forecast ») définissant les technologies actuelles et à venir6 et décrit pour cela :
– Les moyens émergents
– Les tendances industrielles
– Les prédictions concernant la disponibilité et la maturité de logiciels et matériels spécifiques

Praxeme7

D’après Praxeme, « L’architecture technique, en tant qu’art, est une discipline de conception qui porte sur le système, dans son entier« . Elle couvre alors les aspects suivants :
– L’aspect matériel : Ensemble des machines et autres moyens matériels, composants l’infrastructure comme les capacités ou les coûts
– L’aspect proprement technique ou technologique : Logiciels de base, composants techniques et règles de développement qui en découlent
– L’aspect physique : L’architecte technique se borne à fixer les règles de localisation des composants logiciels sur l’architecture matérielle. Il ne saurait décrire complètement l’architecture physique, car, pour cela, il faudrait connaître la totalité des composants logiciels

Cinq types d’infrastructures techniques, deux vecteurs d’analyse

Ces différents Framework font apparaître cinq types d’infrastructures techniques considérées comme distinctes :
– Logicielle : SGBD, système d’exploitation…
– Matérielle : Serveur, poste de travail…
– Réseau : Switch, routeur, protocole…
– Technologique, qu’elle soit standard ou non : UML, IP…
– Service technique

La notion de service technique ne sera pas prise en compte puisque qu’elle est déjà représentée au niveau de la zone support de l’axe d’analyse fonctionnel. Parmi les quatre autres types d’infrastructures techniques, nous pouvons constater qu’il existe des similitudes. Il paraît donc opportun de réduire cette typologie à deux sous-ensembles :
– Matériel : Serveur, poste de travail, switch ou routeur
– Technologique : SGBD, système d’exploitation, protocole, UML et IP

Ainsi, en parallèle d’une vue infrastructure physique comprenant le matériel8 , il faudra développer une vue technologique comprenant les différentes technologies. Chacun de ces axes d’analyse aura une caractéristique commune : la notion de cycle de vie introduite par DoDAF pour les technologies, qu’il est intéressant d’étendre au matériel.

C’est la combinaison de ces deux axes avec la vue applicative qui nous permettra de répondre aux différents cas d’utilisation.
Pour nous aider à structurer ces vues, nous pourrons nous appuyer sur le référentiel des standards IT DISR et la taxonomie proposée par TRM.

———————————————————————————-

1 – http://www.urba-ea.org/
2 – Christophe Longépé, Urbanisation du SI
3 – http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap43.html
4 – http://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI
5 – http://dodcio.defense.gov/dodaf20
6 – Tout en faisant le lien avec les compétences nécessaires pour les mettre en œuvre
7 – http://www.praxeme.org/
8 – Qui à terme pourra éventuellement contenir du matériel autre qui celui lié aux systèmes d’information

———————————————————————————-

Auteur : Gaël Hérent – Consultant et Urbaniste du SI chez BPMS

L’infrastructure technique d’après les principaux Framework