Vous êtes sur la page 1sur 27

L’adoption des principes d’architecture orientée services (SOAÄ)

à la Banque Mutuelle du Québec


Services Oriented Architecture* Adoption Principles
at the Banque Mutuelle of Quebec
par
Michel Thiboutot, M.Sc. Informatique de gestion
et
Albert Lejeune, Professeur ESG-UQAM, département de management et technologie
315, St-Catherine Est, Montréal, (QC) CANADA, H3C3P8
Tel : 514 987 3000 4844, Fax: 514 987 3343
RESUME
Évoluant dans l’industrie des services financiers, la Banque Mutuelle du Québec
poursuit sa quête des meilleures pratiques en technologies de l’information (TI) afin de
développer ses capacités stratégiques. Les nouveaux principes de l’architecture orientée
services (SOA dans le monde anglo-saxon) nécessitent une gouvernance des TI qui va au-delà
des aspects technologiques. Dans le but de procurer un solide fondement aux pratiques SOA,
ce papier explore les notions d’architecture d’entreprise (maturité) et d’architecture
organisationnelle (vision créative). Les bénéfices tant promis par la pratique SOA proviennent
de la réutilisation des services suite à une réflexion architecturale visant la modélisation
optimale des processus d’affaires. Le succès de l’entreprise repose sur son habileté à définir le
niveau de granularité des services, favorisant ainsi l’agilité de l’entreprise.
ABSTRACT
Evolving into the financial industry, the Mutual Bank of Quebec, in order to meet its
goals, continues to investigate the best practices to maintain its strategic capabilities. The
SOA (Services Oriented Architecture) concepts require IT governance beyond the technical
aspects. To establish a solid foundation for the SOA practices, this paper explores the
concepts of the enterprise architecture (maturity architectural level) and the organisational
architecture (high level picture). The benefits most promised by the SOA come from the reuse
of the services by the most suitable modeling business processes. The success is based on the
ability to define the best granularity of services to focus on an enterprise called «agile».

MOT-CLES : ARCHITECTURE D’ENTREPRISE, ARCHITECTURE ORIENTEE SERVICES,


ARCHITECTURE ORGANISATIONNELLE, GOUVERNANCE TI, MATURITÉ.

KEYWORDS: ENTERPRISE ARCHITECTURE, IT GOVERNANCE, MATURITY LEVEL,


ORGANISATIONAL ARCHITECTURE, SERVICE-ORIENTED ARCHITECTURE.

1 INTRODUCTION
Les Canadiens adoptent rapidement les nouvelles technologies bancaires (Lejeune et
Roehl, 2003; Lejeune, 1994). Depuis l’avènement des guichets automatiques en 1986, les

Ä
service-oriented architecture
Canadiens exigent le choix et la commodité offerts par les services bancaires électroniques et
bénéficient de nouvelles options de services mises en place par les banques du Canada. Pour
les experts de l’industrie, l’adoption d’une architecture orientée vers les services, en anglais
SOA pour Services Oriented Architecture, s’impose.
On peut définir l’approche conceptuelle SOA comme étant « une stratégie informatique
qui organise les fonctions offertes par les applications d’entreprises en services interopérables,
basés sur des standards qui peuvent être combinés et réutilisés rapidement pour répondre aux
besoins métiers ». C’est également « une approche architecturale, indépendante de la
technologie, qui permet aux organisations de développer, déployer et gérer des services
métiers partagés pour créer des applications composites » (BEA World 2006).
L’offre des grands éditeurs de logiciels d’entreprise est profondément modifiée par ces
nouveaux standards. Des grands joueurs comme SAP, mais aussi IBM, Oracle et Microsoft,
redéfinissent l’ensemble de leur offre conformément à cette nouvelle vision de l’architecture
des applications (Federico, 2006).
Les grandes entreprises vont suivre. Ainsi, le groupe Gartner (2005) mentionne que
d’ici la fin 2007, les institutions financières qui auront réussi avec brio la mise en place des
pratiques SOA jouiront d’un avantage concurrentiel significatif, en termes de rapidité et
d’agilité. La pratique SOA permet de répondre rapidement aux changements imprévisibles
des marchés, aux besoins des consommateurs ainsi qu’à l’évolution des canaux de
distributions. De plus, Gartner croit que les investissements en principes et infrastructures
SOA sont essentiels afin de réaliser des gains d’efficience opérationnelle en lien, par exemple,
avec la mise en marché de nouveaux produits et services.

2 CONTEXTE
Depuis le début des années 1990, la Banque Mutuelle vit une révolution des mentalités.
Les besoins des consommateurs sont fragmentés, la gamme des produits et services est très
large, le temps de réaction compte vraiment; le marketing doit être décentralisé vers les
succursales qui, en travaillant avec leurs propres bases de données, doivent devenir des
expertes dans leur marché. La notion de temps est tellement forte qu’elle explique la
disparition – provisoire - des fonctions traditionnelles (ressources humaines, marketing et
finance) à la Banque Mutuelle : l’expert dans le marché doit pouvoir rapidement mettre en
branle l’organisation pour qu’elle réagisse aux urgences perçues à la base. Dans cet esprit un
maximum d’expertise doit être transféré directement à la succursale. Ainsi, le siège social se
voit comme un ensemble d’équipes interdisciplinaires de support à l’action locale (notamment
pour les nouveaux produits); d’un autre côté, il redistribue l’information sur les clients vers la
succursale. L’ensemble doit permettre des réflexes plus rapides parce que la rentabilité et la
performance viennent maintenant du temps de réaction.
Depuis 2000, une nouvelle plateforme informatisée permet aux succursales de gérer
l'ensemble des applications locales et les équipements requis. La Banque Mutuelle dispose
ainsi d’une technologie simple à utiliser, transparente, évolutive, facile à gérer par les usagers.
Il ne saurait plus y être question d'une centralisation du développement ou de l'information,

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 2 
situation qui prévalait dans le passé. Comment, près de dix ans plus tard, l’approche SOA
viendra-t-elle bouleverser tous ces acquis?
L’approche SOA vient d’abord questionner le mode de planification des systèmes. Le
secteur des technologies de la Banque Mutuelle assure un suivi du plan global d’évolution des
TI (stratégies TI) dans le but de faire profiter l’entreprise des opportunités offertes par les
nouvelles technologies. Ce plan global d’évolution TI comprend les processus de
développement, les processus de gestion des pratiques et les normes technologiques,
l’élaboration d’un plan d’évolution incluant par exemple les principes directeurs.
Les stratégies TI sont composées principalement de principes directeurs et sont
formulées afin d’appuyer les enjeux et orientations stratégiques. À titre d’exemple, ces enjeux
sont l’optimisation des coûts en lien avec les solutions TI, le niveau de disponibilité des
applications, l’accès inter-applications, la sécurité, etc. Parmi les orientations, on retrouve
l’optimisation des coûts des solutions d’affaires, la définition des besoins, la flexibilité, etc.
Tous ces éléments sont répertoriés dans un document nommé « Architecture cible TI».
Cette architecture documente également l’inventaire de l’ensemble du portefeuille
d’investissement en TI et présente les plans d’action et les initiatives TI.

3 PROBLEMATIQUE
Concrètement, la mise en pratique des concepts SOA a des impacts sur le processus
global d’évolution des TI. Par exemple, lorsqu’il s’agit d’introduire les concepts SOA et de
comprendre leurs effets sur les éléments tels que les initiatives d’affaires et les initiatives TI,
l’alignement stratégique, la gouvernance TI, les normes et orientations, etc.
L’implémentation de ces concepts semble assez complexe et il s’avère difficile de
savoir par où débuter. Stal (2006) précise que la plupart des entreprises mettent l’emphase sur
les technologies et leur implantation, au lieu de mettre l’accent sur l’architecture. Il mentionne
aussi que pour bien comprendre les implications des concepts SOA au niveau des
applications, il faut d'abord définir un ensemble de principes d’architecture. Dans ce contexte,
la planification traditionnelle des TI devient de plus en plus inappropriée pour la Banque
Mutuelle.
Cet inconfort prend naissance dans la définition même des concepts SOA, de son
implémentation dans le contexte architectural actuel, des impacts sur l’infrastructure
technologique ainsi que sur les principaux livrables du processus d’évolution global des
technologies de l’information. De plus, la Banque Mutuelle s’interroge à savoir quels seraient
les bénéfices potentiels de SOA pour l’entreprise. Gartner (2005) précise que le déploiement
des concepts SOA est un incontournable et que la Banque Mutuelle a grandement intérêt à s’y
intéresser si elle veut suivre les tendances du marché. En fait, la mise en place des principes
SOA promet la rapidité et l’agilité de l’entreprise face aux changements imprévisibles des
marchés tout en soutenant le principe de l’organisation apprenante. Ces promesses se
réaliseront-elles ? Et comment faire en sorte qu’elles puissent se réaliser ?

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 3 
La littérature nous apprend que, pour mettre en place des principes SOA en lien avec la
modularité des services métiers, l’entreprise doit avoir atteint un certain niveau de maturité
architecturale. Cette maturité s’apprécie au moyen des concepts de l’architecture d’entreprise.
La modularité des services métiers exige la participation des domaines d’affaires. En
fait, en amont des stratégies d’alignement, l’idée est de construire une architecture capable de
supporter les visions de l’entreprise. Cette forme de «capacité» peut s’introduire par une
réflexion sur l’architecture organisationnelle (Sauer et al. 2002).
Le niveau de l’architecture organisationnelle représente l’entreprise dans son ensemble
et permet de concevoir les interfaces entre les différents domaines des processus, de la
culture, de la stratégie etc.
La présente recherche suggère d’explorer la mise en place des concepts SOA en
abordant l’étude de l’architecture organisationnelle, ouvrant ainsi la porte sur une vision plus
complète de l’organisation : la culture de l’entreprise, son environnement, ses domaines
d’affaires, ses ressources humaines, sa structure etc.

4 BUT ET OBJECTIFS DE LA RECHERCHE


Le but de la recherche est de proposer un cadre méthodologique, adapté au contexte
organisationnel et financier de la Banque Mutuelle, afin de définir concrètement une
architecture et une infrastructure technologique (architecture cible TI) permettant la mise en
application de l’approche conceptuelle SOA.
Dans un premier temps, l’objectif de la recherche est de présenter un état de l’art
concernant l’architecture organisationnelle, l’architecture d’entreprise, les meilleures
pratiques en approche SOA, l’alignement des stratégies d’affaires aux stratégies TI, la
gouvernance des TI et la gouvernance SOA.
Dans un deuxième temps, l’étude présente le nouveau contexte d’affaires de la Banque
Mutuelle. Ce contexte est présenté au moyen de l’application des principes d’architecture
organisationnelle et d’architecture d’entreprise (niveau de maturité architecturale et
modularité des processus d’affaires).
Finalement, la recherche propose un plan d’action visant la mise en application des
concepts SOA et présente les bénéfices d’une telle approche pour la Banque Mutuelle. Au-
delà de la mise en application des concepts SOA et du déploiement de nouvelles technologies
supportant ces concepts, la recherche vise une synthèse allant de l’architecture d’entreprise à
l’architecture organisationnelle afin d’offrir tous les bénéfices promis par l’approche SOA,
mais aussi tous les bénéfices liés aux principes d’architecture d’entreprise et d’architecture
organisationnelle.

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 4 
5 QUESTIONS ET METHODOLOGIE DE RECHERCHE
Notre question de recherche est celle-ci : Comment appliquer les fondements et
principes d’architecture d’entreprise et d’architecture organisationnelle permettant la mise en
place des concepts d’architecture orientée service (SOA) à la Banque Mutuelle du Québec ?
• En quoi l’architecture organisationnelle peut-elle soutenir les SOA ?
• Comment tirer profit de l’apport de l’architecture d’entreprise ?
• Comment aborder la mise en place des principes SOA ?
5.1 Démarche de la recherche
La présente recherche suggère une recherche basée sur l’action en appliquant le cadre
théorique proposé par Ross et al. (2006), intitulé « Enterprise Architecture as Strategy »
(fondation pour l’exécution des affaires) et le cadre théorique de modélisation de
l’organisation, introduit par Morabito et al. (1999). La recherche est également soutenue par
une revue de la littérature pour appuyer ces cadres théoriques, tout en abordant les meilleurs
pratiques pour l’implémentation d’une approche SOA. Enfin, cette recherche vise à
implémenter les concepts SOA basés sur la fondation pour l’exécution des affaires
(architecture d’entreprise) avec, comme toile de fond, les concepts de l’architecture
organisationnelle.

5.2 Planification de l’intervention


Les interventions ont été réalisées sous la forme d’entrevues et d’ateliers. Le but des
entrevues était d’obtenir l’assurance que le cadre théorique fasse du sens pour les architectes
d’affaires et d’application œuvrant dans le contexte de la Banque Mutuelle. Dans un premier
temps, une fois l’architecture organisationnelle complétée, l’observation des résultats a permis
de tirer profit du cadre théorique. Deuxièmement, la modélisation de l’architecture
d’entreprise a mise en lumière les capacités de l’organisation à soutenir les stratégies
d’affaires, dorénavant selon les principes d’architecture orientée services.
Les ateliers ont été convoqués, au besoin, tout au long de la présente recherche. Le but
de ces ateliers était d’identifier les impacts de la mise en place des principes d’architecture
orientée services dans le processus global d’évolution des technologies de l’information de la
Banque Mutuelle.

6 ÉTAT DE L’ART
6.1 Présentation des concepts-clés
Le but de la revue de la littérature est d’identifier les pistes de solutions concernant la
mise en application de l’approche SOA. À la lumière de la revue de la littérature, la mise en
application des concepts SOA implique les concepts d’alignement stratégique entre stratégies
d’affaires et stratégies TI, et implique aussi la gouvernance des TI, la gestion des risques et

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 5 
l’adoption de nouvelles technologies. Comme nous l’avons déjà mentionné, plusieurs auteurs
stipulent aussi que l’entreprise doit avoir acquis un certain niveau de maturité et de modularité
en termes d’architecture d’entreprise et d’architecture organisationnelle. Les concepts de la
revue de la littérature se présentent comme suit :
(1) Architecture orientée services (SOA) : définition, principes et concepts, gouvernance
SOA, standards technologiques, modélisation des services métiers, coûts et bénéfices.
(2) Architecture d’entreprise : cadres théoriques, gouvernance TI, niveau de maturité
architecturale.
(3) Architecture organisationnelle : cadres théoriques, notion de modularité.
La revue de la littérature débute avec les principes et concepts SOA, pour ensuite visiter
l’architecture d’entreprise principalement en termes de maturité, et finalement, pour terminer
avec l’architecture organisationnelle, à la conquête des services métiers, en termes de
modularité.

6.2 L’architecture orientée services


Le but principal de l’architecture orientée services (SOA) est de présenter une nouvelle
approche afin de réduire la complexité, d’augmenter la flexibilité et d’accommoder
l’entreprise rapidement face aux changements. Cette approche suggère également de dessiner
les fonctions d’affaires en modules permettant la réutilisation. Les services web et les
standards sont les clés technologiques pour la mise en place des concepts SOA (Homann et
al., 2004). Les concepts SOA permettent à l’entreprise d’assembler dynamiquement de
nouvelles applications avec un minimum de développement (Patrick et al., 2006).
Les domaines d’affaires demeurent toujours un environnement très fluide.
L’information est un actif stratégique pour l’entreprise et la gestion de cette information est de
plus en plus importante. Patrick et al. (2006) décrivent les impacts majeurs associés à
l’introduction des SOA et les effets sur l’architecture d’entreprise. En bref, les entreprises ont
constamment le souci de rentabiliser leurs acquis technologiques ainsi que les investissements
et ce, dans le but d’augmenter la productivité des affaires. Le tableau suivant traduit les
attentes en termes de besoins d’affaires et de besoins TI face aux SOA. (Statistiques tirées
d’InfoWorld 2006, présentées au BEA World 2006).

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 6 
Les attentes vis à vis les SOA
Besoins d'affaires Besoins TI
Réagir rapidement aux changements des dynamiques
60% 71% Flexibilité architecturale
de marché
Gérér des processus et "business models" inter et
56% 67% Intégration aux applications existantes
intra entreprise
49% Décider à partir d'information en temps réel 62% Intégration des données

45% Développer des initiatives de services clients 59% Intégration des services
Se conformer à un contexte légal en évolution
33% continue 53% Développement d'applications composites

Tableau 1 : Attentes face aux SOA (BEA World 2006)

Bieberstein et al. (2006) définissent l’architecture orientée service comme étant un cadre
théorique intégrant les processus d’affaires et fournissant les infrastructures TI requises. Ces
dernières supportent les notions de sécurité, les composants standards dits « services » ayant
comme but de permettre la réutilisation et la combinaison pour ensuite faire face rapidement
aux changements et aux priorités des besoins d’affaires. Les principaux buts de l’architecture
orientée services, tel qu’introduit par Bieberstein et al. (2006) sont :

− Anticiper les changements dans les marchés


− Développer de nouvelles relations avec les clients et partenaires
− Augmenter la rapidité de mise en marché (time-to-market)
− Créer de nouvelles solutions à haute valeur ajoutée
− Réduire les coûts d’opérations

SOA peut changer fondamentalement les façons de faire d’une entreprise pour
développer et déployer de nouvelles solutions d’affaires et ce, dans le but de soutenir les
avantages concurrentiels. Les marchés poussent les entreprises à être de plus en plus
dynamique. La clé de la flexibilité des affaires repose sur l’interaction entre les unités
d’affaires et les unités TI, Bieberstein et al. (2006).
Homann et al. (2004) définissent le terme modularité comme suit : chaque module
représente un service encapsulant une série de fonctions d’affaires répondant à un objectif
spécifique (« core business capability »). Par exemple, dans le contexte de la Banque
Mutuelle, un service de type « module » pourrait prendre le sens d’une interrogation d’un
compte bancaire. En fait, ce même module pourrait intervenir peu importe le canal de
distribution soit, par le biais des succursales, les services téléphoniques et aussi via le service
en ligne Internet. C’est ici que l’approche SOA prend un sens, car actuellement, chacun des
canaux de distribution possède ses applications, sa technologie et ce, même si les données
sont centralisées.
Les prochaines pages introduisent les principes et concepts SOA en termes de

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 7 
gouvernance. En fait, la gouvernance SOA inclut principalement différents aspects tels que
l’alignement stratégique, l’évaluation et l’adoption de nouvelles technologies, les notions de
services ainsi que les notions de sécurité et les risques en gestion de projets. Cette
gouvernance est en quelque sorte l’adaptation de la gouvernance des TI actuelle, mais en
tenant compte des considérations découlant des principes et concepts SOA.
La gouvernance SOA représente le contrôle du modèle d’entreprise en termes de
composantes et processus d’affaires découpés en modules et dont la priorité est basée sur la
valeur d’affaires que représente cette forme de modularité.

Années Auteurs Contribution de l’article en lien avec la problématique


2006 BEA Systems Inc. Modèle et Roadmap afin d’introduire les concepts SOA
2006 Bieberstein et al. Cadre théorique sur les concepts SOA
2005 Patrick Paul SOA : Flexibilité, extensibilité et intégration.
2006 Homann Ulrich et al. Comment SOA peut contribuer à atteindre les objectifs d’affaires
Tableau 2 : Les concepts SOA, en bref
En résumé, le modèle de gouvernance SOA est une combinaison de la structure
organisationnelle, des processus ainsi que de la relation entre ces éléments. Le modèle est
également basé sur des règles intitulées « principes de gouvernance », qui tiennent compte de
la direction stratégique. En plus des items énumérés à la page précédente, la gouvernance
SOA comprend la définition des rôles, responsabilités, structures et procédures existantes
permettant l’établissement de la priorité des projets d’affaires ainsi que des projets TI. De
plus, la gouvernance SOA devrait indiquer quel changement d’affaires l’entreprise désire tirer
profit des principes SOA. Quelle est la meilleure utilisation des infrastructures actuelles aux
plus faibles coûts possibles? Quelle est la cible d’affaires à atteindre? Si l’organisation
entreprend un virage SOA, il est primordial de revoir ses processus de gouvernance.
Bieberstein et al. (2006) mentionnent l’importance de l’alignement stratégique entre les
unités d’affaires et les unités TI. La mise en place des concepts SOA nécessite un
renforcement de l’alignement. Il est intéressant d’observer que la mise en place des concepts
SOA aura certainement des impacts sur plusieurs aspects du modèle d’Henderson et
Venkatraman (1993).
En fait, la gouvernance des affaires et la gouvernance des TI sont dans la cible ainsi que
les processus, les concepts d’architecture, les opportunités d’affaires et les possibilités TI.
Ainsi, l’alignement stratégique des stratégies d’affaires et des stratégies TI est au cœur de la
mise en place des concepts SOA.

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 8 
Années Auteurs Contribution de l’article en lien avec la problématique
2006 IBM (Redbooks) Patterns : SOA foundation service creation scenario
2006 Pereira et al. Présente les résultats du non alignement. Meilleur approfondissement.
2006 Versteeg et al. Contribution à une définition adéquate de la gouvernance des TI
2005 ICCA Création de valeurs par l’alignement des capacités TI avec objectifs de
l’entreprises
1993 Venkatraman et al. Modèle illustrant 4 perspectives d’alignement des stratégies TI et
d’affaires
Tableau 3 : L'alignement stratégique, en bref
Les notions de « services » en architecture orientée services est en quelque sorte une
finalité en soi. En fait, c’est la réutilisation de ces services qui rend les principes et concepts
SOA attrayant en termes de bénéfices. De plus, l’agilité et la flexibilité de ces services
permettent à l’entreprise de répondre rapidement à de nouveaux besoins d’affaires. Un
service peut se définir comme étant une tâche répétitive, par exemple l’ouverture d’un compte
bancaire ou encore la vérification de la cote de crédit d’un client. L’orientation services a
donc pour but l’intégration des tâches avec comme objectif de lier les services entre eux.
Ainsi, l’architecture orientée services est en fait un style d’architecture supportant
l’orientation services. Et pour conclure, une application est désormais une série de services
reliés et intégrés supportant un processus d’affaires construit sur une architecture SOA (IBM,
2006). L’architecture SOA est basée principalement sur trois composantes (figure 4) : le
fournisseur de services (développement TI), le consommateur de services (utilisateurs),
l’annuaire de services (registre de tous les services disponibles).

Registraire
Annuaire de
de services Consulte
Contrat services
UDDI UDDI
1 2
Interface de
services
WSDL
Fournisseur Consommateur
de services de services
3
Composantes
Relie, exécute les services et
retourne les résultats
SOAP

Figure 1 : Composantes SOA et Web Services Standards (Craig, 2006), traduction libre

Un des buts de la réutilisation est de diminuer les coûts liés à la maintenance des
applications. D’après Benson et al. (2004), les coûts TI accordés à la maintenance (lights-on)
des applications devraient être basés sur l’actualisation des réels besoins en lien avec les

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 9 
besoins stratégiques et opérationnels. Mais qu’en est-il des coûts initiaux, c'est-à-dire les coûts
d’adoption et de mise en place des concepts et principes SOA ?
De plus, il faut gérer les risques associés aux coûts des nouvelles technologies
émergentesi. Tel que discuté précédemment, l’adoption précoce de nouvelles technologies
peut engendrer des coûts supplémentaires en tant que pionnier (être les premiers à utiliser les
récentes technologies) de ces technologies immatures (Bieberstein et al. 2005).
Basé sur les standards de l’industrie, l’intégration des technologies est plus rapide, plus
efficace et moins coûteuse. Les bénéfices sont réels du fait que les applications se parlent
entre elles, l’intégration est simplifiée et on retrouve une économie de temps et de coûts en
termes de programmationii. Bref, SOA permet de construire une présentation standard de
services pour l’ensemble du portefeuille d’application (Marshall, 2006). L’auteur ajoute que
la vraie valeur du SOA est son implantation par ligne d’affaires et que cette valeur est en lien
avec les processus et non pas seulement en lien avec les technologies disponibles.
Pour conclure sur les bénéfices, les banques misent sur l’approche SOA afin d’intégrer
les canaux de distribution dans le but d’améliorer le service à la clientèle en termes de rapidité
pour la mise en marché de produits et pour la croissance de l’organisation (Feig, 2006).

6.3 L’architecture d’entreprise


Ross et al. (2006) définissent l’architecture de deux façons très distinctes, en opposant
l’architecture d’entreprise et l’architecture technologique. L’architecture d’entreprise, basée
sur un modèle d’opération des affaires, représente une vue à haut niveau de l’ensemble des
processus d’affaires ainsi que des technologies requises pour supporter ces processus. Tandis
que l’architecture technologique est plus détaillée, elle se découpe en quatre familles dont
l’architecture des processus d’affaires, l’architecture des données, l’architecture applicative et
l’architecture technologique.
La mise en place des concepts SOA requiert un certain niveau de maturité
architecturale. Ce niveau de maturité est obtenu par la standardisation et l’intégration des
processus d’affaires. Renken (2004) déplore aussi le manque d’intégration relatif à la gestion
des TI et ce, parmi l’ensemble des nouvelles initiatives TI. Le problème soulevé par l’auteur
est le manque de vision globale entre la planification stratégique TI, la gestion de projets, le
développement de SI, l’architecture, l’acquisition d’équipement, la maintenance, la formation
et le support aux utilisateurs. D’ailleurs, certains auteurs (Leist 2006, Lindström et al. 2006,
Fatohali et al. 2006, Goethals et al. 2006) critiquent le modèle de Zachman, lui reprochant ce
manque d’interdépendance entre les éléments.
La plupart des cadres théoriques font appel à la capacité des TI d’intégrer les
composantes dans le but de rencontrer les besoins d’affaires Lyer et al. (2004). Ceci dit,
l’approche SOA vise l’intégration, c'est-à-dire le niveau de maturité requis. Dans ce sens,
Goethals et al. (2006) mentionnent que les entreprises nécessitent constamment d’être ré-

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 10 
architecturées de façon à maintenir leur agilité, leur alignement ainsi que leur intégration. Ces
auteurs présentent le modèle FAD(E)E signifiant « Framework for the Architecture
Development of the Extended Enterprise ». Ce modèle soutien entre autres le besoin d’aligner
les besoins d’affaires et les initiatives TI, l’intégration et l’agilité de l’organisation (de « AS-
IS architecture » à « To-BE architecture »). Les auteurs soulignent aussi l’importance de
l’architecture d’entreprise en précisant que ce n’est pas l’unique responsabilité des gens TI,
mais aussi celle des gens d’affaires. Cependant, les auteurs précisent que c’est parfois très
difficile d’avoir l’engagement des gens d’affaires. Et pourtant, les organisations veulent des
implémentations rapides et évolutives.
Le cadre théorique retenu pour la présente recherche est celui de Ross et al. (2006). Ce
modèle a fait l’objet d’études dans plus de 400 entreprises réparties dans plusieurs industries.
L’étude de ce modèle, dans le contexte de la Banque Mutuelle, est en lien avec la
problématique. Les pistes de solutions tendent justement à implémenter les concepts SOA
utilisant les principes de l’architecture d’entreprise.

Années Auteurs Contribution de l’article en lien avec la problématique


2006 Goethals et al. Importance sur l’alignement et l’intégration. Introduction d’IEEE 1471
2004 Lyer et al. « Four domain architecture ». Capacité d’intégrer les composantes TI
2004 Renken Modèle sous la forme d’une toile d’araignée, 7 composantes
2006 Ross et al. Fondation pour l’exécution des affaires. Modèle d’opération, 4 stades
1992 Zachman J.A Modèle le plus populaire. Découpé en disciplines. 5 * 6 = 30 éléments
Tableau 4 : L'architecture d'entreprise : cadres théoriques, en bref

À propos des différents modèles et de leur apport en termes d’efficacité à définir


l’architecture d’entreprise, Greefhorst et al. (2006) discutent de plusieurs cadres théoriques et
soulèvent le fait qu’il y a beaucoup de contradictions dans la terminologie. Ces auteurs font la
comparaison de plus de vingt modèles et présentent neuf dimensions servant de base à des
fins de comparaison. Cet article est intéressant dans la mesure où il permet de constater la
valeur des modèles via les dimensions étudiées. Jonkers et al. (2006) proposent une vue
intégrée de l’entreprise par l’architecture d’entreprise. En fait, ils présentent différents points
de vue selon les parties prenantes intéressées.
L’architecture d’entreprise capture l’essentiel des affaires, des TI et de leur évolution.
Cette architecture fournit aussi une base pour la discussion et la prise de décision. D’ailleurs,
la réglementation américaine exige désormais que les organisations disposent d’une
architecture d’entreprise. La problématique énoncée dans cette présente recherche soulève un
aspect très important lié à la difficulté des dirigeants à prendre les décisions face à ces
nouvelles approches et technologies. Dans les faits, les entreprises désirent réduire les coûts

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 11 
liés aux investissements TI.
Lindström et al. (2006) ont étudié les problèmes associés aux rôles et aux
responsabilités des dirigeants en lien avec la gestion des TI. À l’aide d’un sondage, les auteurs
établissent trois priorités dont premièrement, la réduction des coûts, deuxièmement,
l’augmentation de la qualité des liens entre les unités TI et les unités d’affaires et finalement,
fournir une architecture TI supportant les affaires.
La comparaison entre les priorités et le but des modèles de Zachman et DoDAF
démontre un large fossé, lié au manque d’outils d’aide à la décision pour supporter
adéquatement les organisations. Lindström et al. (2006) concluent en proposant que les
modèles devraient couvrir davantage les notions de gouvernance TI, de processus de
développement, de gestion de portefeuilles de projets et d’organisations TI. Ils mentionnent
également que le but ultime de l’architecture d’entreprise devrait répondre aux besoins
d’alignement des stratégies d’affaires et stratégies TI, de couvrir efficacement l’utilisation et
le déploiement des ressources TI, de calculer le ROI ainsi que la réduction des coûts, de
l’intégration TI et des opérations TI.

Année Auteurs Contribution de l’article en lien avec la problématique


2006 Greefhorst et al. Présentation de 9 dimensions, basées sur les cadres existants

2006 Jonkers et al. EA capture l’essentiel des domaines d’affaires, des TI et de leur évolution

2006 Leist et al. Fournir une bonne appréciation pour lequel une théorie est mieux qu’une autre

2006 Lindström et al. Argumentation de l’importance du CIO dans l’architecture d’entreprise

2005 Patrick Paul Décrit les impacts majeurs associés aux SOA et des effets sur l’entreprise

Tableau 5 : L'architecture d'entreprise : comparaison des cadres, en bref

Tel que présenté par l’Institut Canadien des comptables agrées, (lCCA, 2005), le
premier objectif de la gouvernance des TI est la création de valeur par l’alignement des
capacités TI sur les objectifs de l’entreprise. Le deuxième objectif est le maintien de cette
valeur par une gestion efficace du portefeuille d’investissement TI. D’après l’ICCA (2005),
une gouvernance TI est indispensable afin de générer des rendements intéressants ainsi que
d’atténuer les risques liés aux investissements TI.
Avison et al. (2006) abordent les échecs des projets TI sur la performance de
l’entreprise et précisent l’importance de la gouvernance TI pour la réussite des projets. En
fait, d’après eux, la gouvernance TI doit considérer l’infrastructure TI, l’utilisation des TI
ainsi que la gestion de projets en développement TI.
Du coté de la Banque Mutuelle, la gouvernance TI touche principalement les normes et
orientations TI. D’après Sherer (2004), la gouvernance TI devrait aussi inclure un processus
ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 12 
de décision d’investissement TI. L’auteur propose donc un modèle de sélection dans le but de
prioriser les projets TI en lien avec les initiatives TI. Broadbent (2002) présente cinq grands
domaines liés à la gouvernance TI. On retrouve les principes directeurs, les stratégies
d’infrastructure TI, l’architecture TI, les besoins d’affaires à combler ainsi que les initiatives
TI et la gestion des priorités.
Années Auteurs Contribution de l’article en lien avec la problématique
2006 Avison et al. Importance de la gouvernance des TI sur la réussite des projets TI.
2005 ICCA Politiques et pratiques. Implique la surveillance des fonctions de gestion de
l’info.
2004 Sherer Processus de sélection des investissements TI inclus dans la gouvernance
2002 Broadbent L’importance de la gouvernance, pourquoi c’est critique, les composantes
1993 Venkatraman et al. Tout ce qui inclut les TI : Stratégies, politiques, impartitions, etc.
Tableau 6 : La gouvernance TI, en bref

Comme nous l’avons déjà mentionné à quelques reprises, la mise en application des
concepts SOA nécessite un certain niveau de maturité architecturale. Ross et al. (2006)
définissent la maturité comme étant le déplacement des investissements TI d’un point de vue
local (business silos) vers une architecture globale où l’on retrouve le partage des données,
des infrastructures, des systèmes d’entreprise (business modularity). Cependant, Kaisler et al.
(2005) dénoncent l’immaturité de la discipline en termes de problèmes liés à l’architecture
d’entreprise. Les défis sont rarement techniques et touchent principalement les politiques
d’entreprise, la gestion de projets ainsi que certaines faiblesses au niveau de l’organisation.
Une des principales lacunes des modèles d’architecture d’entreprise est sa représentation
statique (non dynamique). Une infrastructure SOA à maturité aide à éliminer le fossé entre les
structures en silos, les systèmes (« legacy »), les données ainsi que les processus d’affaires.
L’approche SOA procure l’alignement entre les unités TI et les unités d’affaires (Labrot,
2006). La figure suivante présente sept niveaux afin d’évaluer le degré de maturité vers un
modèle SOA. On y retrouve les principaux aspects d’une architecture d’entreprise. La
présente recherche s’intéresse aux niveaux quatre et cinq car c’est à partir des ces niveaux que
l’on commence à aborder les aspects SOA.

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 13 
Mise en Services Services Services Services
Silo Intégré composantes
composites virtualisés Dynamiquement
reconfigurable

Orienté Orienté Orienté Orienté Orienté Orienté Orienté


Vue affaires fonctions fonctions fonctions services services services services

Ad-hoc Ad-hoc Ad-hoc Gouvernance Alignement Alignement Alignement


Gouvernance Gouvernance Gouvernance SOA en SOA et TI SOA et TI SOA et TI
Organisation TI TI TI émergence gouvernance gouvernance gouvernance

Analyse et Modélisation Développement Modélisation Modélisation Modélisation Modélisation


Méthodes conception
structurée
Orientée
objet
Par
composantes
orientée
services
orientée
services
orientée
services
orientée
sélectif

Intégration des Intégration des Assemblage


Applications Modules Objets Composantes Services processus via
services
processus via
services
dynamique des
applications

Architecture à
Architecture Architecture Architecture par SOA en SOA matricielle
Architecture monolithique en couche composantes émergence
SOA
(GRID)
reconfiguration
dynamique

Infrastructure Plateforme
spécifique
Plateforme
spécifique
Plateforme
spécifique
Plateforme
spécifique
Plateforme
spécifique
Portable
S’adapte
dynamiquement

Niveau 1 2 3 4 5 6 7

Figure 2 : Niveaux de maturité SOA (IBM, Redbooks 2006), traduction libre

6.4 L’architecture organisationnelle


D’après Sauer et al. (2002), une déconnection persiste toujours entre les stratégies
d’affaires et les stratégies TI. À titre d’exemple, une institution bancaire, qui a imparti ses
fonctions TI dans les années 90, est toujours mécontente plusieurs années plus tard. Les
capacités TI ont évolué, mais par contre, ces processus d’affaires ont stagné. Une partie du
problème est que les stratégies d’affaires sont une cible mouvante. Ainsi, il est difficile de
construire une plateforme technologique afin de supporter la vision de l’entreprise. Cette
vision étant basée sur des capacités que l’entreprise pourrait mettre en place. Les auteurs
présentent ainsi un schéma illustrant comment une organisation peut traduire sa vision
d’affaires en plateforme technologique flexible. Ce schéma introduit la notion du concret vers
l’abstrait – et de l’abstrait vers le concret - en architecture organisationnelle.
Abstrait
Souhaitable

Vision

Souhaitable
Attributs
organisationnels et
capacités
Résultats Attributs de la Souhaitable
atteints plateforme TI et
capacités
Résultats
atteints Plateforme
technologique
Résultats actuelle
atteints

Concret

Figure 3 : Vision d'affaires (Sauer et al. 2002), (traduction libre)

Ainsi, Sauer et al. (2002) argumentent longuement sur l’importance de l’alignement des
stratégies d’affaires et stratégies TI en termes d’architecture organisationnelle. Un des
principaux problèmes est la rigidité des organisations afin de rencontrer les changements des
ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 14 
marchés et les nouveaux besoins des clients. Les entreprises sont limitées dans leurs réponses
aux tendances des marchés car elles manquent de flexibilité et d’adaptabilité (Versteeg et al.,
2006). C’est dans ce contexte que la mise en place des principes SOA, en embrassant les
principes de modularité des affaires (étape 4 de Ross et al., 2006), permettra à l’entreprise
d’atteindre ses objectifs en termes de bénéfices liés aux SOA. Quant à eux, Morabito et al.
(1999) introduisent les concepts de culture, d’apprentissage et d’individus à leur modèle
d’architecture de l’organisation.

Figure 4 : Modèle d'architecture de l'entreprise du 21ième siècle (Morabito et al. 1999)

Années Auteurs Contribution de l’article en lien avec la problématique


1999 Morabito et al. Introduit les principes de molécules (composantes de l’organisation)
2002 Sauer et al. Argumentation pour une meilleure transformation organisationnelle
2006 Versteeg et al. Clarifie la complexité de l’organisation. Structure les responsabilités
2004 Rivard et al. Le facteur humain est très important à la flexibilité de l’entreprise
Tableau 7 : L'architecture organisationnelle : Cadres théoriques, en bref

6.4.1 Notion de modularité


La notion de modularité est importante, car elle invite à visiter les aspects d’architecture
organisationnelle. Les notions de modularité sont un pré-requis à la mise en place des
concepts SOA. Cette modularité se définit comme étant la capacité d’une certaine agilité
stratégique permettant la personnalisation et la réutilisation des modules, c'est-à-dire les
services métiers Ross et al. (2006). L’approche modulaire réduit également la complexité des
systèmes d’information, Versteeg et al. (2006). D’ailleurs, ces auteurs présentent un modèle
d’architecture d’affaires basé sur la définition de décomposition des processus en services par
le découpage des procédures en activités et en tâches (lien avec le « Business Process
Management »).

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 15 
7 ANALYSE DE L’INTERVENTION
Nous présentons ici les cadres théoriques retenus à partir de certaines notions plus
abstraites pour ensuite nous diriger vers la mise en place des concepts et principes
d’architecture orientée services (SOA), incluant tous les éléments susceptibles d’influencer le
processus global d’évolution TI de la Banque Mutuelle. Ainsi, ce chapitre débute par
l’architecture organisationnelle, en passant par l’architecture d’entreprise pour conclure avec
les SOA.

7.1 Architecture organisationnelle


7.1.1 Introduction au modèle de Morabito et al. (1999)
En quoi l’architecture organisationnelle peut-elle soutenir les SOA? Morabito et al.
(1999) présentent un cadre théorique (architectural framework) afin de modéliser
l’organisation dans son ensemble. La figure suivante illustre les composantes ou domaines
faisant partie du cadre théorique. L’étude du cadre théorique de Morabito et al. permet de
mettre en perspective, d’une façon plus abstraite, le contexte de la Banque Mutuelle incluant
les diverses composantes.
Avant d’aborder les concepts d’architecture orientée services, il s’avère intéressant
d’avoir une vision à haut niveau de certaines facettes de l’organisation. Ainsi, les
composantes impactées sont raffinées afin d’obtenir une vision des changements nécessaires à
la mise en place des concepts SOA. On retrouve donc ces mêmes composantes dans les
concepts de molécules. La figure suivante illustre un exemple de molécules. On y retrouve les
molécules de culture, de processus et d’information. Ainsi, une molécule est un regroupement
de composantes qui peuvent être raffinées au besoin.
Un des aspects les plus intéressants du modèle de molécules est non seulement
l’implication des processus et des systèmes d’information (applications et données), mais
aussi l’implication des ressources humaines, de la culture de l’entreprise, de la structure de
l’organisation, son environnement ainsi que les stratégies d’affaires.
Donc, l’exploration du modèle de Morabito et al. permet de faire les liens entre les
différentes composantes tout en spécifiant les différents alignements possibles entre ces
mêmes composantes avec comme principal objectif : la réutilisation des services.

7.1.2 Définition du concept de molécule


Le concept de molécule est un dérivé de la recherche organisationnelle, facilitant la
compréhension, l’analyse et le design. Les molécules ont la propriété d’abstraction offrant le
niveau d’analyse désiré. Elles offrent la facilité d’arranger l’organisation de façon à mettre
l’emphase sur un problème spécifique incluant de multiples facettes de l’organisation.

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 16 
Morabito et al. (1999) expriment le concept de molécule à partir de la métaphore de la
molécule d’eau. En fait, l’eau est composée de deux éléments soit l’hydrogène et l’oxygène
(H2O). C’est ce principe de combinaison d’éléments qui une fois assemblés constitue la
molécule. La combinaison d’éléments s’intitule la cristallisation et initie les notions de
caractéristiques émergentes.
La cristallisation des domaines d’affaires en molécule est un processus qui part de
l’imprécis vers le précis, du plus ou moins défini à défini, du chaos vers l’ordre. Donc, l’idée
de cristalliser peut être appliquée à tous les différents domaines de l’organisation. Ces
domaines sont par exemple l’environnement, le pouvoir, la culture, les processus d’affaires, la
prise de décision, les stratégies, etc. Donc, une molécule peut être composée de différents
domaines de l’organisation et être représentée selon différents niveaux de granularité.
La modélisation de l’organisation procure donc une notion importante : la notion de
caractéristiques émergentes. Ainsi, le processus de cristallisation de différents domaines
provoque l’émergence de caractéristiques organisationnelles. Ces caractéristiques ont
l’avantage d’être reconnues par le monde extérieur à l’entreprise, par exemple le succès, la
réputation. À l’interne, ces caractéristiques peuvent être la qualité des produits, la loyauté des
employés, etc. Donc, une molécule se dessine selon le contexte de l’organisation, est
composée de un ou plusieurs domaines et se raffine au besoin.

7.1.3 Alignement entre molécules et composantes


Le modèle de Morabito et al. illustre les alignements possibles entre les diverses
composantes. Ce concept est exploité dans le but de rapprocher les stratégies, la structure, les
acteurs, les responsables, les processus ainsi que les applications (outils) de la Banque
Mutuelle. La figure suivante présente les alignements tout en raffinant la modélisation des
processus d’affaires afin de détailler les liens entre les diverses composantes.

7.1.4 Élaboration d’un contrat spécifique


Une fois l’exercice complété, l’idée est d’identifier certains services (contrats) qui sont
ultimement réutilisables par plusieurs secteurs de l’organisation. Le but de l’élaboration des
contrats est de permettre l’identification des services et le niveau de granularité de ceux-ci,
ainsi que l’évaluation des bénéfices en termes de réutilisation.
La modélisation organisationnelle de la Banque Mutuelle du Québec permettra
d’obtenir une vision d’affaires en termes de structure technologique capable de répondre et
soutenir ces visions d’affaires (stratégies). Il est important de rappeler cependant que la
modélisation organisationnelle demeure à un niveau plus abstrait et sert essentiellement
comme toile de fond à l’étude de l’architecture d’entreprise ainsi que pour la mise en place
des concepts d’architecture orientée services.
ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 17 
Banque
Mutuelle

CS

Information Processus Stratégies Humain Environnement


- Régimes fiscaux
Amélioration de l’offre
- Planif. Financière Services en Épargne Industrie des services
en épargne et Secteurs d’affaires
- Fonds de placement et placement financiers
placement
- Conformité

Réglementation sur
opérations en fonds
CS de placement

Processus Processus Processus


Épargne à terme
Gestion des
Processus
représentants en
Déterminer l’offre Autres type de
épargne collective
véhicules de
placement

CS CS
Humain Structure Information Outils Humain Structure Information Outils
- Identifier le client
- Succursale (Offre) - Outil d’analyse Conseiller en - Succ. :1er niveau - Identifier le REC - Gestion des
Planificateurs - Portrait financier
- Registraire (approche développement - Courtier, 2ième niv. - Niveau Supervision représentants
financiers - Connaître le client
portefeuille) soutien au Cabinet - Gérer # de permis (BD Notes)
- Portefeuille cible

CS CS
Humain Structure Outils Humain Structure Outils

Connaissance en Équipe de Systèmes Systèmes


Connaissance en
approche portefeuille représentants en - Dossier Clients Courtier - Conformité
épargne collective
(plan d’actions) épargne collective - Centrale - Centrale

Processus
Processus
Fonds de placement
(produit par la
Banque Mutuelle)

CS
Humain Structure Information Outils
1- Planificateurs
- (Offre) - Adhérer au régime Systèmes
financiers
- (Producteur) - Ouvrir le compte - Registraire Fonds
2- Responsable de la
- (Conformité) - Transiger - Conformité
conformité

CS
Humain Structure Outils
Administration des
Connaissance des Systèmes
produits Processus
régimes fiscaux, - Registraire Fonds
(Producteur)
fonds de placements
(Registraire) Processus
Fonds externes

CS
Humain Structure Information Outils
1- Planificateurs
- Offre - Adhérer au régime - Formulaires
financiers
- Registraire - Ouvrir le compte électroniques (Actuel)
2- Responsable de la
- Conformité - Transiger - Nouveau système
conformité

CS
Humain Structure Outils

Connaissance des Administration des Systèmes


régimes fiscaux, produits - Système de gestion
Alignement futur fonds de placements (Registraire) - Fund ServTM
CS : « Composition Sub-type »

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 18 
En quoi l’architecture organisationnelle peut-elle soutenir les SOA ? Nous avons
appliqué dans notre recherche le modèle de Morabito et al. En fait, son utilisation approfondie
pourrait facilement faire l’objet d’une étude en particulier. Les résultats recherchés étaient des
pistes de solutions en termes de modularité des services métiers (élaboration des services
d’affaires à haut niveau) dans un contexte bien précis. D’ailleurs, Morabito et al. encouragent
la modélisation d’une façon ad-hoc afin de documenter une situation bien particulière.
L’application de ce cadre théorique a permis d’illustrer, à l’aide d’un exemple concret portant
sur efficience des opérations sur les fonds externes, la représentation détaillée des molécules,
la similitude des processus entre les fonds « Maison » et les fonds externes et aussi de mettre
en évidence la disparité des outils supportant ces processus.
De plus, la réflexion portant sur les caractéristiques émergentes introduit le rôle de la
Banque Mutuelle en termes de coordination, par rapport aux unités d’affaires, composantes et
filiales. Ainsi, la modélisation met bien en évidence le besoin d’intégrer les processus en
épargne et placement, car le client est au centre de l’offre de services et les différents services
sont supportés par des composantes et unités d’affaires. Également, il devient intéressant de
remarquer que le développement d’application se fait par produit, et même par ligne
d’affaires. On constate aisément que les besoins d’affaires sont majoritairement répondus « en
silos ». D’ailleurs, la prochaine section portant sur l’architecture d’entreprise, creusera
davantage ces faits.

7.2 Architecture d’entreprise


7.2.1 Introduction au modèle de Ross et al. (2006)
Ross et al. (2006) introduisent un cadre méthodologique qui vise la mise en place d’une
fondation pour l’exécution des affaires. Cette fondation définit les infrastructures
technologiques et les processus d’affaires digitalisés (ou à digitaliser) permettant
d’automatiser les principaux métiers et permettant aussi d’augmenter les capacités et aptitudes
de l’entreprise. La construction d’une fondation pour l’exécution des affaires nécessite la
maîtrise de trois disciplines clés : modèle d’opération, architecture d’entreprise et modèle
d’engagement TI.
En lien avec la modélisation organisationnelle et les initiatives stratégiques, la
modélisation de la fondation pour l’exécution des affaires permet de mettre en lumière, d’une
façon un peu moins abstraite, mais toujours à un certain niveau, les capacités TI de
l’organisation ainsi que l’évolution de l’architecture (niveau de maturité architecturale). De
plus, le modèle suivant est étudié dans le but de faire ressortir les limites de la stratégie et
l’établissement des priorités et ce, de façon à obtenir une vue d’ensemble de la fondation pour
l’exécution des affaires.

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 19 
7.2.2 Fondation pour l’exécution des affaires
L’élaboration et la représentation de la fondation pour l’exécution des affaires est un
exercice qui permet de mieux cerner, sur une seule page, l’organisation en termes
d’architecture d’entreprise. Le modèle est une approche étape par étape. Cette approche
permet de discuter des éléments et questions suivantes :
− Quels sont les symptômes les plus significatifs?
− Service à la clientèle : différentes réponses pour une même question
− Effort majeur pour soutenir les nouvelles règlementations
− Agilité des affaires difficiles et initiatives non profitables
− Les TI sont constamment un goulot d’étranglement
− Différents processus et systèmes pour une même activité
− Information décisionnelle non disponible
− Saisies de la même information dans plus d’un système
− Les gestionnaires appréhendent les discussions sur les investissements TI
− Les gestionnaires ne connaissent pas la valeur que peut procurer les TI
− Quel est le modèle d’opération théoriquement applicable?
− Comment illustrer l’architecture d’entreprise, selon le modèle?
− À quel stade, en termes de maturité d’architecture, la Banque Mutuelle
figure-t-elle?
− Le modèle d’opération et le stade actuel, toujours en termes de maturité
d’architecture d’entreprise, permettent-ils une démarche SOA?
− Comment progresser dans la maturité, c'est-à-dire comment évoluer d’un
stade vers un autre?
− Comment amener la fondation pour l’exécution au quatrième stade de
modularité?
− Comment innover avec cette fondation pour l’exécution des affaires?

7.2.3 Première discipline : le modèle d’opération


Le modèle d’opération est la première discipline qui précise à quel niveau d’intégration
et de standardisation des processus, que l’entreprise doit opérer parmi ses unités d’affaires.

7.2.4 Deuxième discipline : l’architecture d’entreprise vue selon quatre stades de maturité
La deuxième discipline propose de définir une architecture d’entreprise, construite
selon quatre grands étapes ou phases d’architecture, qui tendent les uns après les autres, (d’où
l’importance de respecter l’ordre) vers une maturité architecturale. La première étape est une
architecture en silos qui consiste à maximiser individuellement les investissements par unités
d’affaires. La deuxième étape propose une standardisation de la technologie parmi ces unités
d’affaires. La troisième optimise les infrastructures dans le but de partager les données et les
processus d’affaires à l’ensemble de l’entreprise. Enfin, la quatrième étape introduit la
modularité des processus d’affaires. C’est ce dernier stade qui rejoint l’approche conceptuelle

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 20 
SOA en termes de découpage des processus d’affaires en services ou modules métiers.

COORDINATION UNIFICATION

- Partage des clients, produits et fournisseurs - Clients et fournisseurs peuvent être local ou global
- Impact sur les autres unités d’affaires opérationnelles - Processus d’affaires complètement intégrés
- Unité d’affaire opérationnelle unique - Unités d’affaires similaires
- Gestion d’entreprises autonomes - Gestion centralisée
- Contrôle des unités d’affaires au dessus des processus - Processus standards
- Partage des données clients, produits, fournisseurs - Décisions TI centralisées
- Consensus sur le design des infrastructures TI,
- Décisions prises par les unités d’affaires au sujet des
applications

DIVERSIFICATION RÉPLICATION

- Faible partage de clients et fournisseurs - Faible partage des données clients


- Transactions indépendantes - Transactions indépendantes agrégées à un niveau sup.
- Unités d’affaires opérationnelles uniques - Unités d’affaires similaires
- Gestion d’entreprises autonomes - Gestion d’affaires autonomes mais avec certaines limites
- Contrôle des unités d’affaires au-dessus des processus - Contrôle centralisé des processus d’affaires
- Faible partage des données clients, fournisseurs, produits - Définition des données centralisées et agrégées au
- La plupart des décisions TI sont faites par les unités niveau corporatif
d’affaires - Mandat TI centralisé

Faible Forte

Standardisation des processus d’affaires

Figure 5 : Définition des modèles d'opération (Ross et al. 2006), traduction libre

7.2.5 Troisième discipline : le modèle d’engagement TI


La troisième et dernière discipline est le modèle d’engagement TI, c'est-à-dire les
mécanismes de gouvernance qui assurent que les investissements TI et les projets d’affaires
atteignent les objectifs de l’entreprise. Le modèle d’engagement concerne les mécanismes de
gouvernance qui assurent que les investissements TI ainsi que les investissements d’affaires
atteignent les objectifs de l’entreprise. Dans le contexte de la Banque Mutuelle, le modèle
d’engagement correspond au processus global d’évolution TI ayant comme principaux
livrables les documents d’architecture cible, incluant les projets d’affaires et les évolutions TI.
Les auteurs présentent cinq décisions majeures relatives à la gouvernance des TI et toutes
reliées au modèle d’opération. Ces décisions représentent les règles de conduite de
l’organisation et on les présente comme suit : principes TI, architecture d’entreprise,
infrastructure TI, besoins d’affaires et priorités et investissements.Le modèle d’engagement
sert donc à visiter le processus global d’évolution TI de la Banque Mutuelle, à le comparer, à
le commenter et à l’adapter pour les besoins des principes SOA.
Comment tirer profit de l’apport de l’architecture d’entreprise ? Le modèle de Ross et
al. ne se limite pas uniquement à divers éléments technologiques. Le modèle basé sur une

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 21 
fondation pour l’exécution des affaires propose à l’organisation un solide ancrage pour son
évolution et la réalisation de ses stratégies. De plus, le modèle d’opération agit comme une
boussole guidant la prise de décisions relative aux solutions d’affaires et technologiques. En
termes d’évaluation du niveau de maturité architecturale, les points à évaluer sont :

√ les stratégies d’affaires, basées selon une approche orientée services


√ la gouvernance de l’organisation; affaires et TI
√ les méthodes de développement utilisées pour les projets TI
√ le découpage des applications (fonctions, composantes, services)
√ l’architecture applicative et les infrastructures technologiques

D’un point de vue technologique, les observations sur le terrain démontrent que la
Banque Mutuelle situe son niveau de maturité architecturale entre la définition des
technologies standards et l’optimisation des infrastructures. En fait, ceci dépend du domaine
d’applications. Dans le cas du domaine Épargne et placement, il y a lieu d’optimiser
davantage les infrastructures et d’intégrer les processus afin de les rendre plus efficients.
Cependant, le niveau de maturité ne s’évalue pas uniquement sur les acquis et standards
technologiques. Telle que mentionnée précédemment, l’évaluation doit également porter sur
les politiques d’entreprise notamment sur les normes et orientations relatives au
développement et à la maintenance des applications, à la gestion de projets, aux processus de
développement, et aux mesures de performance. Donc, à la lumière des activités réalisées à la
Banque Mutuelle, portant sur le modèle d’engagement ainsi que sur la gouvernance TI, voici
quelques observations :

− Le processus de développement est standardisé et respecté par l’ensemble de


l’organisation
− La gestion de risques en développement de projets est appliquée par les
chargés de projets, en lien avec les indications du bureau de projets
− Les mesures de performance des projets sont en place depuis 2006 et
démontrent par exemple, des indicateurs en termes de respect des délais de
livraison, respect des coûts, qualité, etc.

Bien que les applications soient centralisées, le calcul des ROI, la gestion et
l’établissement des priorités se font par lignes d’affaires. Pour conclure, les résultats
démontrent une certaine maturité du côté des technologies de l’information, mais les résultats
démontrent également un retard du côté des secteurs d’affaires, en termes de stratégies
d’affaires. En fait, on observe une légère distorsion entre les stratégies d’affaires rapportées
les stratégies TI. Finalement, est-ce que la Banque Mutuelle est prête pour l’adoption des
concepts SOA en termes de maturité? Est-il opportun à ce stade-ci de migrer vers la

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 22 
modularité des processus d’affaires?

8 RESULTATS DE LA RECHERCHE
√ D’un point de vue affaires, les applications sont développées en silos. Bien que les
principes de réutilisation soient mis en place et respectés par le secteur des technologies
concernant plusieurs services d’infrastructures technologiques et applicatives, les
architectes et analystes d’affaires n’ont pas les méthodes ni les outils afin de modéliser les
processus d’affaires en services ou en modules partageables et réutilisables. Jusqu’à ce
jour, le découpage est orienté par fonction.
√ Les stratégies TI sont à la remorque des stratégies d’affaires. C'est-à-dire que les stratégies
TI sont fortement influencées par le payeur (demandeur) du projet, autrement dit par le
marché des particuliers, le marché des entreprises, les composantes et filiales. En fait, il y
a peu d’arrimages entre les projets des domaines et sous-domaines d’affaires, incluant les
divers canaux de distribution. De plus, les solutions TI sont soumises à une forte pression,
toujours dictées par de faibles coûts et des délais de livraison, toujours plus restreints.
√ La structure organisationnelle actuelle divise aussi le monde des affaires et celui des TI.
En fait, les TI sont d’un côté avec leurs méthodes, outils, principes, etc. D’un autre côté,
les secteurs d’affaires, subissent les coûts exorbitants que génèrent les TI.
√ L’architecture d’entreprise découle du processus global d’évolution des TI à la Banque
Mutuelle. L’architecture cible, les principes directeurs (normes et orientations TI) et le
plan d’évolution sont les principaux livrables du processus. Ceci dit, tous ces livrables
supportent les stratégies d’affaires, mais les principes d’alignement stratégique entre les
stratégies d’affaires et les stratégies TI semblent ne pas prendre assez d’importance, c'est-
à-dire que les stratégies TI se contente de supporter les stratégies d’affaires sans pour
autant les devancer.
√ L’établissement des priorités se fait selon un modèle d’allocation et de priorisation. Tous
les projets sont classés par catégorie de développement autorisé, selon un budget x.
Cependant, cette forme de catégorisation permettra-elle d’arrimer plusieurs projets dans
un contexte d’architecture orientée services?
√ En fait, il faudrait creuser davantage le modèle d’allocation afin d’identifier les projets
candidats à la mise en pratique des principes SOA, peu importe la répartition du
portefeuille les initiatives d’affaires et les initiatives TI.Les outils de documentation font
défaut. Toute la gestion documentaire est un défi en soi. Trouver la bonne information
demeure fastidieux et finalement, cette information obtenue est-elle à jour? La question
est pertinente. Mais, la Banque Mutuelle s’organise de plus en plus et la mise en place
récente d’un portail améliore grandement la situation. L’accès à l’information dans les
meilleures pratiques SOA est primordial.

9 CONCLUSION
La mise en place des principes et concepts SOA peut sembler complexe. En fait, les

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 23 
concepts SOA ne sont pas uniquement une préoccupation des TI. Ce n’est pas aussi simple
que la mise en place d’une nouvelle technique de développement d’application, d’un nouveau
langage de programmation, de nouvelles normes, etc. L’ensemble de l’organisation est
concerné et doit s’impliquer dans l’atteinte des bénéfices promis par la pratique SOA. Les TI
et les secteurs d’affaires doivent unir leurs efforts dans un seul but, la réutilisation.
La réussite de la mise en pratique des principes et concepts SOA repose sur l’arrimage
des différents projets candidats à la pratique SOA. On parle d’arrimage, mais également
d’alignement entre les stratégies d’affaires entre-elles et les stratégies TI. Il s’agit de changer
les façons de faire. Le processus global d’évolution des TI est très impacté. Pour les TI, il ne
s’agit plus d’être à la remorque des stratégies d’affaires, c'est-à-dire d’analyser et de traduire
les stratégies en enjeux et en orientations technologiques, mais bien d’aller au-delà de ces
stratégies d’affaires afin d’y établir les stratégies TI capables de supporter l’évolution et les
plans d’affaires. Cette recherche a donc permis d’appliquer les fondements et principes
d’architecture d’entreprise et d’architecture organisationnelle afin de mettre en place les
concepts d’architecture orientée services (SOA) à la Banque Mutuelle.
Ainsi, les résultats de la recherche suggèrent une vision élargie et globale de
l’organisation. En fait, les bénéfices tant promis par la pratique SOA proviennent de la
réutilisation des services suite à une modélisation optimale des processus d’affaires. En
conclusion, l’approche conceptuelle SOA repose sur l’art de visualier et de modéliser
l’organisation ainsi que ses processus d’affaires dans l’unique but de rendre l’entreprise plus
agile et évolutive.
Cette recherche a traité deux aspects importants de la science de l’informatique. D’un
côté les technologies et de l’autre, la gestion. L’architecture orientée services réunit ces deux
univers. Dans les meilleures pratiques SOA, l’un ne vit pas sans l’autre.

LISTE DES RÉFÉRENCES


Association des banquiers Canadiens (ABC) (2006). Voyons-y de plus près. Août.
Avison David, Shirley Gregor, David Wilson, (2006), Managerial IT unconsciousness, Communications of the
ACM, v.49 n.7, p.89-93, July 2006
Baskerville, Richard, Michael D Myers, (2004), Special issue on action research in information systems: Making
is research relevant to practice foreword, MIS Quaterly, Vol.28, No.3, pg. 329.
BEA Systems Inc. BEA World (2006), SOA concepts for IT Management and Enterprise Architects. San
Francisco.
Benson, J.Robert, Thomas L. Bugnitz, and William B. Walton, (2004). From business strategy to IT action, John
Wiley & Sons, 328p.
Bieberstein Norbert, Sanjay Bose, L. Walker, A. Lynch, (2005). Impact of Service-Oriented Architecture (SOA)
on enterprise systems, organisational structures, and individuals. IBM Systems Journal, Vol. 44, No 4,
2005. 691-708.
Bieberstein Norbert, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah, (2006). Service-Oriented

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 24 
Architecture (SOA) Compass, IBM Press, 232 p.
Broadbent Marianne, (2002). CIO Futures – Lead with effective governance, ICA 36th conference. Gartner.
Cox, D.E, H. Kreger, (2005). Management of the service-oriented architecture, IBM Systems Journal, 2005.
Vol. 44, No 4, pgs 709-726
Craig, J., (2006). SOA and Web services in enterprise: Benefits and Challenge, EMA (Enterprise Management
Associates).
Fatolahi, A. and Shams, F. (2006). An investigation into applying UML to the Zachman framework. Information
Systems Frontiers 8, 2 (Feb. 2006), 133-143.
Federico, T.R. (2006). SAP AG in 2006: Driving Corporate Transformation. Case SM-153, 08/08/06. Stanford
Graduate School of Business.
Feig, Nancy, (2006). Changing channel – Banks are tapping SOA to achieve multichannel integration, enabling
seamless customer service, increased speed to market and accelerated organic growth, Bank Systems
& Technology. New York: Nov 2006. Vol. 43, Iss. 11; pg 32.
Forrester Research Inc., (2006). The state of SOA in Financial Services. By Jost Hoppermann. Januray 9, 2006.
Forrester Research Inc., (2006). SOA and Web services management. By Randy Heffner. February 10, 2006.
Fox, Pimm. (2004), Reusable Integration With an SOA. Computerworld. Framingham: Mar 8, 2004. Vol. 38, Iss.
10; p. 22 (2 pages)
Gartner, (2005). An SOA approach will boost a bank’s competitiveness. By Don Free, Annemarie Earley, Maria
Luisa Kun. July 2005.
Gibbs, Mark. (2006) SOA or a kit car? Am I nuts? Network World. Framingham: Jul 31, 2006. Vol.23, Iss. 29;
pg. 50, 1 pg
Goethals, F. G., Snoeck, M., Lemahieu, W., and Vandenbulcke, J. (2006). Management and enterprise
architecture click: The FAD(E)E framework. Information Systems Frontiers 8, 2 (Feb. 2006).
Greefhorst, D., Koning, H., and Vliet, H. V. (2006). The many faces of architectural descriptions. Information
Systems Frontiers 8, 2 (Feb. 2006), 103-113.
Hall, Mark (2006). An SOA State Of Mind. Computerworld. Framingham: Apr 3,2006. Vol.40, Iss. 14; pg.A14,1
pg
Havenstein Heather (2006). Measuring SOA Performance Is A Complex Art. Computerworld. Framingham: Aug
7, 2006. Vol. 40, Iss. 32; p. 6,1.
Homan Ulrich, Michael Rill, Andreas Wimmer, (2004). Flexible value structures in Banking, Communcation of
ACM. May 2004. Vol. 47, No 5. 35-37.
Ganci et al. Redbooks. (2006). Patterns: SOA Foundation Service Creation Scenario. IBM. September , 556
pages
Institut Canadien des Comptables Agrées ICCA, (2005). Alignement des investissements dans les technologies
de l’information sur la stratégie d’entreprise - ce que les directeurs financier doivent savoir,
www.icca.ca/ccti, 20p.
Jonkers, H., Lankhorst, M. M., Ter Doest, H. W., Arbab, F., Bosma, H., and Wieringa, R. J. (2006). Enterprise
architecture: Management tool and blueprint for the organisation. Information Systems Frontiers 8, 2
(Feb. 2006), 63-66.
Kaisler Stephen H., Frank Armour, Michael Valivullah, (2005). Enterprise architecture: Critical problems,
Keller, Eric (2006). Get ready to SOA, Manufacturing Business Technology. Hignlands Ranch, Nov 2006. Vol.
24, Iss. 11; pg n/a

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 25 
Kilcourse Brian, Paula Rosenblum. (2006), SOA-The 'Next Big Thing'? Chain Store Age. New York: Aug 2006.
Vol.82, Iss. 8; pg. 84, 2 pgs
Krafzig, Dirk, Karl Banke, Dirk Slama. (2006). PEnterprise SOA : Service-oriented Architecture Best Practices.
April 2006, 382 pages
Labrot, Andy. (2006), Service-Oriented Architecture Can Help Bridge Gap Between It, Business Units National
Underwriter. P & C. Erlanger: Oct 30, 2006. Vol.110, Iss. 41; pg. 19, 2 pgs.
Leist Susanne, Gregor Zellner (2006). Evaluation of current Architecture Frameworks”, SAC’06, April, 23-27.
Lejeune, A. (1994). La technologie de l’information au coeur de l’espace de la stratégie. L’industrie canadienne
des services financiers en mutation. Thèse de doctorat non publiée, HEC Montréal.
Lejeune, A. et Tom Roehl (2003). Hard and soft ways to create value from information flows : Lessons from the
Canadian financial services industry, Canadian Journal of Administrative Sciences, Special Topic Issue
on Electronic Business and Commerce in Canada. March, Vol. 20, N.1.
Lindgren, R., Henfridsson, O., Schultze, U. (2004). Design principles for competence management systems: A
synthesis of an Action Research Study. MIS Quaterly; sept.; 28. 3, ABI/Inform pg. 435.
Lindström, Å., Johnson, P., Johansson, E., Ekstedt, M., and Simonsson, M. (2006). A survey on CIO concerns-
do enterprise architecture frameworks support them?. Information Systems Frontiers 8, 2 (Feb.), 81-90.
Lyer B. R. Gottlieb, (2004). The four domain architecture: an approach to support enterprise architecture. IBM
Systems Journal. 2004, 43, 3; pg. 587.
MacVittie Lori, Don MacVittie. (2006), SOA RISING. Network Computing. Manhasset: Jul 20, 2006. Vol. 17,
Iss. 14; p. 32 (2 pages)
MacVittie, Lori. (2006). Locking Up SOA Governance. Network Computing. Manhasset: Oct 12, 2006. Vol.17,
Iss. 21; pg. 20, 1 pg.
Marabito, J., Sack, I., & Bhate A. (1999). Organization modeling. Innovative architectures fot the 21st century.
Upper Saddle River, NJ: Prentice-Hall.
Marshall, Jeffrey. (2006) Up and Away with SOA. Financial Executive. Morristown: June. Vol. 22, Iss. 5; p. 58
(2 pages)
Bonnet, P. (2005). Cadre de références. Architecture SOA – Meilleures pratiques. Orchestra Networks. Sep
2003-Fév.2005.
Patrick Paul, (2005). Impact of SOA on Enterprise Information Architectures, SIGMOD, ACM: June. 844-848
Renken, Jaco, (2004). Developing an IS/ICT management Capability Maturity Framework, Proceedings of
SAICSIT, page 53-62.
Ricadela, Aaron, (2004). The Dark side of SOA, Bank Systems & Technology. New York: Sept.
Rivard, Suzanne, Benoit A. Aubert, Michel Patry, Guy Paré, Heather A. Smith. (2004). Information Technology
And Organizational Transformation: Solving The Management Puzzle, Elsevier B.-Heinemann, 320 p.
Ross, Jeanne W, Peter Weill, David C. Robertson (2006). Enterprise Architecture as strategy. Creating a
Foundation for Business Execution. Boston (MASS): Harvard Business School Press, 233 pg.
Sauer, Chris, Leslie P. Willcocks. (2002), The evolution of the Organizational Architect, MIT Sloan
Management, Spring 2002.
Ricadela, Aaron, (2004). The Dark side of SOA, Bank Systems & Technology. New York: Sep 2004.
Sherer, Susan A. (2004), IS project Selction : The role of strategic Vision and IT Governance. Proceedings of the
37th Hawaii international conference on System Sciences. IEEE.

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 26 
Susman, G., and Evered, R. (1978), An assessment of the scientific merits of action research, Administrative
Science Quarterly (23), pp.582-603.
Stal, Michael (2006),IEEE Software. Using Architectural Patterns and Blueprints for Service-Oriented
Architecture Los Alamitos:Mar/Apr 2006. Vol.23, Iss. 2; pg. 54
St-Amant, Gilles (1995). Le management est-il la pratique qui précède la théorie? Ou quelle est la place de la
recherche-action au sein de la formation en gestion? Collection Histoire, Gestion, Organisations No 4.
Versteeg, G. and Bouwman, H. (2006). Business architecture: A new paradigm to relate business strategy to
ICT. Information Systems Frontiers 8, 2 (Feb.), 91-102.

i
BEA Systems Inc. (BEAWorld 2006) présente certains coûts initiaux comme les coûts au niveau de l’organisation :
changement organisationnel, révision des processus de gouvernance d’affaires, éviter les coûts d’intégration; et les coûts TI :
coûts d’acquisition des infrastructures, coûts de maintenance des infrastructures, révision des processus de gouvernance ti,
formation des ressources.

ii
Bénéfices TI : réduction des coûts de développement, économies sur les coûts de maintenance, minimissation des
coûts d’intégration, proposition des solutions flexibles, rapides, meilleure justification des investissements TI, vu que,
effectuée plus près des processus d’affaires, elle permet la livraison incrémentale de services.
Bénéfices d’affaires : augmente l’agilité des affaires, réduit le risque, exprime une meilleure compréhension des TI,
procure de meilleurs avantages concurrentiels.

ECIG – Sousse ‐  ©Thiboutot – Lejeune 2007                                                                        Page 27