Introduction
Contexte : sur un grand projet, un
architecte s'énerve au sujet d'un responsable technique qui
insiste pour utiliser tel serveur d'application.
« Mais c'est incroyable ça ?! Pourquoi
partir d'emblée sur cette techno ? A-t-il mesuré l'impact
que cela aura sur l'architecture globale du projet ? Sur
l'intégration avec les outils de développement, de tests
unitaires et d'intégration ? Sans parler du budget et des
formations nécessaires : tous ne sont pas des spécialistes
comme lui ! Et puis les besoins applicatifs montrent que l'on
n'aura pas besoin de tous les niveaux de services offerts par
cet outils...
Pourquoi lui laisser la
décision sur un tel point ??? Parce que c'est un expert
technique ?
C'est
pourtant une simple question de bon sens !
Quand
vous faites refaire votre cuisine, vous n'appelez pas le
réparateur du frigo ou le plombier, vous faites venir un
cuisiniste ! ».
Et voilà. Ce discourt date de début 2002
et illustre encore la difficulté du rôle de l'architecte,
obligé "d'imposer" une vision globale (qui dépasse
largement le cadre du seul serveur d'application). Or le
problème, c'est qu'un architecte n'est pas là pour imposer,
mais pour coordonner, valider, guider. Cela faisait
dire à Philippe KRUCHTEN (dans l'article sur un exemple
de guide d'architecture) :
« The architect doesn't talk, he
acts. When this is done, the team says : "Amazing : we
dit it, all by ourselves !" »
Cela rejoint le discourt tenu par
[Burton]
dans son introduction de "Who needs Architecture",
en VO (le dessin est également issu de leur article!) et
cette introduction souligne encore la différence entre architecte et programmeur :
|
Imagine a house where the plumbers, masons, carpenters,
heating and cooling contractors, painters, and electricians
are each given free reign to design and construct their
own portion of the house with little or no
coordination between them. Each skilled craftsman or
subcontractor is concerned only with the most cost-effective
and expeditious construction or installation of a
particular subsystem of the house.
Now, let’s
also assume that the family that lives in the house is
continually adding new rooms or altering the room
configurations to meet changing space requirements.
The resulting house, in addition to
being less than
aesthetically pleasing to look at, would be virtually
impossible to maintain or improve, and would certainly
be an undesirable place in which to live. |
Surely no
one would think of building a house that way.
And yet what we’ve just described is
not all that different from the way that most
organizations have
"designed" their collections of information
systems and networks.
|
Les paragraphes suivants présentent
quatre facteurs
importants d'évolution d'une architecture, avant de les
résumer dans le paragraphe de conclusion.
Ces facteurs sont :
- le legacy
(existant)
-
la technique
(hétérogène)
- le marché
(évolutif)
- le process
(de développement)
Legacies (existants)
Notez bien le pluriel à
"legacy" (d'où des existants). Cela est
souvent issu de l'évolution de l'entreprise qui, au fil des
années, agrège... Cette agrégation augmente le seuil
de complexité rappelé dans l'article sur la définition
de l'Architecture.
Le schéma ci-dessus (tiré de
[EAIeb])
illustre les "péripéties" suivantes :
- 1 - Mainframe (
[Developpez])
- ~ 1980 - : ordinateur central aux applications monolithiques,
représentant un système centralisé qui concentre toute l'intelligence
du programme. Il gère également un réseau (le plus souvent
en étoile) où sont connectés des terminaux passifs de
requêtes. Ces derniers n'ayant aucune intelligence, le
système central se charge également de la partie interface
utilisateur.
- 2 - Déploiement
centralisé - ~ mi-80 -
: il s'agit du déploiement d'une nouvelle application (donc
avec de nouvelles données), mais toujours sur le mainframe
(donc centralisé). Cela implique des problématique de
synchronisation et de réplication entre les 2 bases de données
pour assurer la cohérence des données.
- 3 - Déploiement
décentralisé - ~ fin 80 -
: il faut attendre la fin des années 1980 pour voir
l'apparition des serveurs locaux et de la micro-informatique,
facilitée par l'apparition des moniteurs.
Cela induit des problèmes de migration de données et de
code, comme le rappelle notre ingénieur
de 30 ans de métier !
- 4 - Fusion -
début 90 - : si l'entreprise rachète un concurrent,
elle retrouve les problèmes de synchronisations évoqués précédemment,
avec en plus l'obligation de porter un certain nombre
d'application sur des environnements hétérogènes...
Les étapes suivantes trouvent une explication dans Organisations
(informatiques) & Cycles (économiques).
- 5 - Exploitation des
données - mi- 90 -
: des logiciels comme des ERP (Enterprise Ressource Planning,
gestion des ressources de l'entreprise) ou SRM (Supplier
Relationship Management, gestion de la relation fournisseur) ,
ou SCM (Supply Chain Management), ... ont pour but d'exploiter
les données à des fin de planification / prévision /etc...
Cela implique que ce système (ERP, SRM, SCM, ...) s'interfacent
avec tous les autres systèmes et gère la synchronisation entre
les différentes bases et son propre référentiel ! Il s'agit
aussi pour ces systèmes de s'ouvrir aux acteurs du marché
(fournisseurs, partenaires, clients, départements fonctionnels
internes) tels qu'ils sont présentés dans le facteur
d'évolution architecturale ci-dessous, à savoir le marché.
- 6 - Datawarehouse
- ~ 2/3-90 - : une première
réponse que l'on peut apporter aux problèmes du point
précédent réside dans un référentiel unique qui extrait des
données du central et des région vers une base d'infocentre...
ce qui sous-entend que l'on peut homogénéiser des données
venant de sources hétérogènes !
- 7 - Extranet / Internet
- ~ fin 90 - : mise à disposition
des services métiers via les interfaces web, avec ce que cela
suppose d'encapsulation des systèmes anciens vers les nouveaux
serveurs web et serveurs d'application. l'EAI (Enterprise
Application Integration) perce à ce moment pour apporter
l'autre réponse aux problèmes soulevé par 5, à savoir la
communication entre des systèmes hétérogènes. CORBA arrive
aussi, mais uniquement pour de la communication synchrone
d'objets... ce qui est loin de répondre à tous les cas de
figure !
- 8 - e-businness, B2B,
B2C - début 2000 - :
rappelons que le canal B2B est déjà exploité depuis au moins 20 ans.
Le web permet de toucher beaucoup plus de client, ouvrant la
voix du B2C et de l'e-business en général... donc de jolies
interfaces centralisées avec derrières une coopérations de
services métiers d'une entreprise... voire même de plusieurs
entreprises ! (comme des services de prêts bancaires couplés
à des assurances). Là encore, faire communiquer tout cela avec
des données homogènes, synchrones et non-dupliquées et
capables de passer les différentes couches technologiques (de
l'applet java jusqu'au mainframe COBOL) devient un challenge...
heu... intéressant ! La crise de la bourse (à partir d'avril
2000) a rappelé à tout le monde que le seul canal
envisageable était le P2P (path to profitability)
!
Autre vérité qu'il est facile d'oublier
:
« Tout nouveau système devient du legacy dans les 3 ans ».
C'est-à-dire : quelque soit le système
que vous développiez (avec les dernières technos du
marché), il va rentrer en production dans les 2 ans qui
suivent son lancement (pour les gros systèmes)... et dans
l'année qui suit, cela devient du legacy, donc une partie
intégrante de l'existant, avec les mêmes problématiques
d'exploitation et de compatibilités avec les autres
composants de l'entreprise!...
Hétérogénéité technique
Évidemment, chaque architecture business
ou fonctionnelle est différente d'un système à l'autre, le
métier et les services attendus n'étant pas les mêmes. Cela
participe aussi à l'augmentation du seuil
de complexité présenté dans l'article sur la définition
de l'Architecture.
C'est lors du fameux passage
de l'AF vers l'AT (les 2
points de vue) que les choses se compliquent.
Sur le plan purement techniques,
[PJCS] distingue au minimum les hétérogénéités :
- des configuration de
réseau : piles TCP/IP (serveur Unix), Novell IPX/SPX
(Serveur Novell Netware), Microsoft NetBEUI (Serveur Microsoft
Windows NT), IBM SNA/APC (Mainframe IBM).
Pîlotes client, serveur et ressources diverses (exécutables,
émulateurs, ...) souvent incompatibles sur un même client ou
un même serveur.
- des bases de données :
Oracle, Sybase (Unix), Novell, DB2 (IBM), SQL Server
(Microsoft)
- des systèmes d'exploitation et
logiciels intermédiaires : OS serveurs comme NT,
OS/2, VM, Unix, Netware,... et middlewares différents, avec
une couche de présentation hétérogène (TN3270, Telnet,
Motif - XWindows, Windows GUI, MacOS, Netscape ou IE, ...).
Mais sur le plan applicatifs, on notera
également différents architectures
applicatives hétérogènes comme les applications
monolithiques, maître-esclave, client-serveur, pair à pair
et distribuées... (comme le mentionne
[Menez])
Évolution du marché
Si l'on reprend le diagramme d'organisation
de l'architecture
métier, on se rend compte que le marché n'est pas
constitué uniquement des clients.
Il faut savoir composer avec 3
"marchés" différents :
- celui des fournisseurs;
- celui des partenaires ;
- celui des clients.
Or ces marchés ont des points communs qui
ont des impacts structurants sur l'entreprise et le cas
échéant sur son système d'information :
• Contrainte concurrentielle forte
• Globalisation
• Nouveaux modèles (B2C, B2B, etc... même s'il s'agit
souvent d'une nouvelle façon technique de présenter un
marché qui existait déjà depuis plus de 20 ans, comme nous
le fait remarquer cet ingénieur
de 30 ans de métier).
Ces nouveaux canaux marchent bien, alors que
le marché de l'informatique retient son souffle pendant une
période bien
creuse. Le
[JournalDuNet]
du 24 mai 2002 signale que, selon le
dernier rapport publié par eMarketer sur la situation et l'évolution
du e-commerce en Europe, le marché du B to C a atteint
16,48 milliards de dollars en 2001 contre 8,06 milliards en
2000, soit une progression annuelle de 104 %. Pour 2002,
eMarketer table sur une croissance davantage soutenue (124 %)
avec un chiffre d'affaires total de 37,07 milliards de dollars.
Une tendance qui devrait se maintenir les années suivantes :
à l'horizon 2004, les revenus du e-commerce européen devraient
atteindre les 182,54 milliards de dollars.
En associant au B to C les revenus
du B to B, eMarketer estime qu'en 2002, le chiffre
d'affaires global du e-commerce paneuropéen devrait atteindre
les 169,81 milliards de dollars (+146 % par rapport à 2001).
Cette forte prédominance du B to B, qui devrait
totaliser à lui seul 132,74 milliards de dollars cette année,
est confirmée par les résultats d'une étude menée par Pro
Active International sur quatorze pays européens. Si le nombre
de transactions réalisées par les particuliers est nettement
supérieur à celui des entreprises (265 millions contre 100
millions) la valeur des achats inter-entreprises est 43 %
plus élevée que celle des particuliers (40 milliards d'euros
pour les entreprises contre 28 milliards pour les particuliers).
Industrialisation du process
Au milieu, l'entreprise doit
maîtriser son process de développement (enchaînement
d'activités) et y faire correspondre les domaines
architecturaux.
Le cycle de développement présenté
ci-dessus est en V, mais ne présage en rien du cycle final :
il peut être en V (pour un projet simple), en "vvvv"
Itératif,
ou en des cycles itératifs plus fouillés. Il faut bien
retenir le fait suivant : quelque soit le cycle retenu, les activités
(modélisation, conception, codage, intégration, mise en
production) sont toujours présentes.
Sur ces activités viennent se greffer les
4 sphères architecturales, qui concernent les projets.
Une sphère
évolue selon deux axes:
- transversal pour assurer la cohérence d'un domaine
architecturale entre les différents projets;
- projet par projet pour apporter un soutien concret issu de
de son étude globale (souvent étude préliminaire, mais qui
se continue et se raffine tout au long du projet).
Ces sphères ont pour but de faciliter
l'évolutivité de leurs domaines respectifs.
Typiquement :
- l'architecture
métier (BA pour "Business Arch."),
généralement transversale entre les différents projets,
aide à la définition ou redéfinition des nouveaux besoins
métiers;
- l'architecture
fonctionnelle (FA pour "Functional Arch.")
précise les fonctionnalités qui se rajoutent ou se modifient
et participe à la délimitation précise des frontières de
chaque système;
- l'architecture
applicative
(AA pour "Applicative Arch.") intervient plus au
niveau de chaque projet pour bien intégrer les services
applicatifs (persistance, sécurité, etc...), sachant qu'ils
évoluent en même temps que l'environnement technique qui, on
l'a vu ci-dessus, change au cours du temps ;
- l'architecture
technique (TA pour "Technical Arch.") intervient
projet par projet pour leur apporter une définition précise
du cycle de développement, des outils associés et des
framework qui doivent supporter les technologies retenues
(elles aussi changent régulièrement du fait d'un cycle de
développement de plus en plus court)...
Conclusion :
Facteurs d'évolutions d'une architecture
Le schéma suivant (issu de
[Menez])
récapitule ces facteurs ainsi :
Les trois pôles reprennent les
paragraphes legacy
, technique
et marché.
Au centre, on retrouve le
"système" de l'entreprise (un ou des SI, plus les
différentes applications métiers) qui découle directement
du process
de développement, quatrième facteur d'évolution d'une
architecture. Ce système doit répondre à un certain nombre
de critères dont les principaux sont rappelés dans ce
schéma (maintenabilité, extensibilité, etc.), mais qui sont
également détaillés dans les Principes
Généraux de l'Architecture
Technique.
Les paragraphes précédents (legacy
, technique
et marché
et process)
mettent en évidence 2 types d'architectures :
- une architecture d'intégration
qui va avoir pour objectif de préserver l'investissement
initial, de maintenir et faire collaborer l'existant ;
- une architecture d'extension
qui favorise l'évolution du legacy et l'intégration de
nouveaux systèmes.
Cela rejoints les 2
enjeux de l'Architecture ('architecture' dans son sens
général), à savoir
- le guide
et l'évolutivité.
|
