L’architecture d’entreprise · 28 octobre 2005, Version 1.4 de BABoK (ajout de Draft detailed) 12 juillet 2006, Versiuon 1.6 de BABoK 10 novembre 2006, premier examen de certification

1

© Gilles Gravel 2006

BABoKBusiness Analyst Body of Knowledge

« Référentiel d’architecture d’entreprise »


L’architecture d’entreprise

Introduction à l’architecture d’entrepriseRéférentiel ou méthodologie?HistoriqueLa base de BABoKSommaire du corpus de connaissanceSon état actuel d’avancementConclusionLiens utiles

2


Introduction à l’architecture d’entreprise


Modélisation organisationnelle

Morabito, Sack et Bathe (1999) montrent que ces caractéristiques sont issues d’un patron d’arrangements et d’alignements entre des domaines organisationnels tels que l’information, les processus, la culture, les personnes et l’apprentissage. Pour les dirigeants, une nouvelle compétence est exigée : la pratique de l’architecture qui consiste à démonter une organisation en ses composantes fondamentales afin d’en comprendre les qualités émergentes

3


L’Architecture d’entrepriseL’architecture d’entreprise (AE) fournit une base de planification stratégique qui relie et aligne les TI avec les fonctions d’affaires qu’ils supportent. L’AE ne débute pas avec les technologies, Elle débute avec une planification stratégique basée sur les besoins d’affaires de l’entreprise, sa vision, ses buts et son leadership.L’AE est constitué de composantes d’affaires et techniques et c’est un processus cyclique qui débute avec les composantes à plus haute priorité pour s’assurer qu’elles demeurent à jour alors que les autres composantes sont développées. Due à cet état de fait, l’AE est en évolution continue et n’est à toute fin jamais complétée.


Référentiel ou méthodologie?

BABoK : C’est un référentiel «Framework» utilisé pour définir l’ensemble des processus d’affaires d’une entreprise selon un cadre de bonnes pratiques

4


Rapprochement

BABoK a certains points communs avec le CMMi et le SWEBOK

Il vise à préserver les intérêts du client d’affaires davantage que du processus de développement technique.

Il définit des pratiques d’analyse d’affaires et touche les analystes fonctionnels sans le côté technique


CMMiLe CMMI, pour Capability Maturity Model Integration (Modèle intégré du niveau de maturité), est une extension de la spécification CMM première, créée pour le ministère de la Défense américain en 1989 afin de déterminer si un projet interne ou tiers serait terminé dans les temps, selon le budget et les spécifications. CMMI étend CMM en y intégrant les avancées d'autres spécifications proches, et établies entre-temps pour pallier les manques de CMM.

CMMI est donc avant tout un référentiel d'évaluation de la capacité à gérer et terminer un projet correctement, proposant nombre de bonnes pratiques liées à la gestion, au développement et à la maintenance d'applications et de systèmes. Ces bonnes pratiques sont regroupées en 24 processus, eux-mêmes regroupés en 4 types (ProcessManagement, Project Management, Engineering et Support) et 5 niveaux de maturité

5


SWEBOK

SWEBOK (contraction de Software Engineering Body of Knowledge) est un projet lancé par un comité de IEEE dans le cadre du génie logiciel. Le projet vise à définir et éclaircir le rôle du génie logiciel et de ses composants au sein d'autres disciplines. Il sert d'encyclopédie du génie logiciel de par ses définitions, les standards présentés et les méthodes abordées


SWEBOK

6


Positionnement du cadre de référence

COSO

CMMiPMBOKPrince2

ITIL Processus

Service

ISO

9000

COMMENT

QUOI

Source: ISACA, AFAI & H. Ceuleman 2004

CobiTGouvernance des TI

ISO17799SécuritéGouvernance

D’entreprise

BABoKZachman


Un inventaire des référentiels et méthodologies d’entreprise

RéférentielsZachmanBABoKCMMiSWEBOK

MéthodologiesMacroscopeMerise…

7


Historique

Zachman Framework

IIBABABoK


Historique Zachman Framework

1964 John Zachman joint IBM 1970 Il oriente ses travaux sur l’architecture d’entreprise 1975 Il publie de nombreux articles sur le sujet1987 Il publie pour IBM "A Framework for Information Systems Architecture." 1990 Il quitte IB pour fonder sa propre entreprise de consultation « The Zachman Institute for Framework Advancement (ZIFA) »

8


Le cadre de référence ZachmanConstitué d’une matrice de 5 perspectives vue par des acteurs différents selon des catégories d’information au nombre de 6

Les acteurs dans le fondement d’architecture d’entreprise:

Quelqu’un qui s’est engagé à faire des affaires dans une industrie particulièreHomme d’affaires qui dirige l’entrepriseAnalyste fonctionnelConcepteur, qui applique des technologies spécifiques pour résoudre un problème particulierConstructeur de systèmeSystème lui-même


Le cadre de référence Zachman

9


Le cadre de référence Zachman


Historique BABoKOctobre 2003, première rencontre inaugurale à Toronto des 28 membres fondateurs de 21 organisations différents (Banque de Montréal, de Bell Canada, London Life …) représentant 8 pays.2 Mars 2004, première rencontre générale à Toronto et formation officieuse de l’IIBA3 janvier 2005, première version du »Body of Knowledge»7 avril 2005, seconde rencontre générale à Toronto et un vote est fait sur la constitution est accepté.28 octobre 2005, Version 1.4 de BABoK (ajout de Draft detailed)12 juillet 2006, Versiuon 1.6 de BABoK10 novembre 2006, premier examen de certification CBPA en FlorideMars 2007, prochaine version prévue de BABoK

10


Qu’est que l’IIBAIIBA International Institute of Business

AnalysisC’est une association professionnelle Internationale à but non lucratif des professionnels en analyse d’affaires

Quelques faits:Siège social au Canada à TorontoReprésenté dans 7 pays en plus du Canada et des États-Unis.Chapitres au Canada : 12Chapitres aux États-Unis : 38L’IIBA se conforme aux pratiques ISO / IEC 17024


Les objectifs de l’IIBAÊtre le chef de file en tant qu’association de professionnel au niveau international qui maintient et développe des standards de bonne pratique en analyse d’affaires ainsi que la certification de ses professionnels

Les moyens qu’elle utilise :Créer et développer une conscience et une reconnaissance de la valeur de la contribution des analystes d’affairesDéfinir le corpus de connaissance (Body of Knowledge)Fournir un forum de partage des connaissances et de contributionau corpus de connaissancesIdentifier les compétences et qualités requises pour un analysted’affairesDéfinir les standards de formation et le développement professionnel nécessaire aux analystes d’affairesReconnaître publiquement et certifier les analystes d’affaires qualifiés

11


La base de BABoKB BusinessA Analyst

Qu’est-ce qu’un Analyste d’Affaires ? (Business Analyst) Un BA travaille comme une liaison entre les propriétaires de manière à comprendre, analyser, communiquer et valider les exigences de changement des processus d’affaires des politiques et des systèmes d’information.

Il doit comprendre les problèmes d’affaires et les opportunités dans le contexte des exigences et recommande des solutions qui permettront à l’organisation d’atteindre ses objectifs.


La base de BABoKB Body o of K Knowledge

Le corpus de connaissances est la somme de la connaissance à l’intérieur de la profession d’analyste d’affaires et reflète ce qui est considéré comme une bonne pratique du domaine. Tel que dans la plupart des professions, le BoK est défini et amélioré par les analystes d’affaires professionnels qui ont adhéré à ces pratiques.Le BoK décrit les zones de connaissance d’analyse

d’affaires, les activités associées, les tâches et les qualifications nécessaires à leur exécution.C’est un guide qui évolue continuellement selon les ajouts requis par la profession et selon les changements dans le temps.

12


Concepts centraux de l’analyse d’affaires (chapitre 1.4 BABoK R1.6)

Définition du rôle de l’analyste d’affairesDéfinition des requis (requirements)Définition des types de requis

AffairesUsagersFonctionnellesQualité du serviceSupposition et contraintes des problèmesMise en œuvre

Pratique d’exigences efficacesGlossaire (chapitre 9 BABoK R1.6)


Sommaire du corpus de connaissance (BoK)

Divisé en six domaines de connaissance lorsque combiné, couvre les standards des professionnels de l’IIBA qui auront à réaliser des analyses d’affaires

Les domaines sont: L’analyse d’entreprise (chapitre 2 BABoK R1.6)

Planification et gestion de requis d’affaires (chapitre 3)

Exigences des requis d’affaires (chapitre 4)

Analyse des requis et documentation (chapitre 5)

Exigences de communication (chapitre 6)

Évaluation de solution et validation (chapitre 7)

Il y a également 2 autres sujets :Les fondements du BA (chapitre 8)

Glossaire (chapitre 9)

13


Schéma général


L’analyse d’entreprise (chapitre 2 BABoK R1.6)

Il est important pour les analystes d’affaires de bien comprendre l’environnement organisationnel dans lequel il travaille.Principales activités (non ordonnées ou obligatoires) :

Création et maintien de l’architecture d’affairesÉtude de faisabilité pour déterminer la solution d’affaires optimaleIdentifier les nouvelles opportunités d’affairesDéfinir la portée et l’opportunité d’affairesPréparer un cas d’affaires (business case)Faire une analyse de risque initialePréparer des scénarios décisionnels

14


Planification et gestion de requis d’affaires (chapitre 3)

L’analyste d’affaires doit définir les activités d’évaluation des requis d’affaires et comment ces activités seront exécutées lors du projet en accord avec les standards existants de l’organisation

Ces activités incluent l’identification des rôles clés, gérer les activités d’identification des besoins, gérer la portée des requis d’affaires et assurer les communications sur l’évolution des activités


Exigences des requis d’affaires (chapitre 4)

Cette section des connaissances inclut la définition d’outils et de techniques pour la collecte des requis des projets des propriétaires de processus d’affaires. Il inclut la description de l’applicabilité des techniques, leur force et faiblesse.

Les principales techniques sont:Séance de «Brainstorming»Groupe focusRévision de la documentationAnalyse d’interfaceEntrevueObservationPrototypageAteliers d’analyse de besoinsSondage / Questionnaire

15


Analyse des requis et documentation (chapitre 5)

Cette région de connaissances décrit comment les besoins de propriétaires sont analysés, structurés et spécifiés pour leur utilisation dans le design et la mise en œuvre d’une solution. L’objectif est de décrire les caractéristiques d’une solution acceptable à un problème d’affaires qui est repris et compris par l’équipe projet pour le réaliser.L’analyse des requis définit les méthodes, outils et techniques utilisées pour structurer les données brutes recueillies durant la phase d’analyse des requis, identifier les différences dans l’information et définir les capacités de la solution documentée.Le premier focus de l’activité de documentation est de raffiner le modèle basé sur la rétroaction interactive avec les propriétaires de processus et s’assurer de la faisabilité de requis proposé pour supporter les besoins des usagers, leurs buts et objectifs.


Exigences de communication (chapitre 6)

C’est une collection d’activités et de considérations pour exprimer le résultat de l’analyse des requis d’affaires et sa documentation destinée à une audience large et variée.

Cela inclut la présentation, la communication, la vérification et doit obtenir l’approbation des propriétaires de processus et des promoteurs des projets.

Les analyses d’affaires doivent considérer où et quand les communications doivent prendre place, quelle approche est appropriée pour chaque situation et comment chaque communication doit être présente.

16


Évaluation de solution et validation (chapitre 7)

Cette section couvre les tâches de l’analyste d’affaires pour s’assurer que la solution doit rencontrer les objectifs des propriétaires de processus par des tests complets et que la mise en œuvre est sans problème.Suivant l’accord sur le design d’une solution, l’analyste d’affaires assiste l’équipe technologique dans le détail du travail de design incluant la séparation du projet en phases, révision du design détaillé, définition des livrables et autres travaux de la même nature.L’analyste d’affaires est imputable pour s’assurer que la solution développée rencontre les besoins définis et doit évaluer le succès du projet après sa mise en œuvre.


Les fondements du BA (chapitre 8)

Ce chapitre définit les compétences générales et particulières, des qualités, techniques et compétences nécessaires pour effectuer des analyses d’affaires.

17


Glossaire (chapitre 9)

Ce glossaire décrit tous les termes utilisés par les analystes d’affaires pour uniformiser les pratiques et démarchesCe glossaire évolue avec l’ajout de détails et de connaissances acquises dans chaque domaine du BoK.


Son état actuel d’avancementLa release 1.6 date du 12 juillet 2006

Elle contient tout ce qui était inclus dans la release 1.4 ( 28 octobre 2005) plus:

Un chapitre d’introductionUne révision du rôle de l’analyste d’affairesUne définition des types de requisDu contenu raffiné et valoriséUne mise à jour de la structure des fondements du BALa révision est réalisée par des groupes de BA bénévolesProchaine release prévu pour mars 2007

18


ConclusionL’analyste d’affaires BA est relativement un nouvel emploi professionnel. Sa certification est aussi jeune et est déjà une reconnaissance du marché qui recherche des individus compétents. La définition des tâches n’est toutefois pas encore définie précisément par l’industrie et la profession devra évoluer à ce niveau.Par contre, c’est dans le chaos que surgissent les opportunités. Le besoin d’un emploi avec un titre spécifique pour remplir le défi associé avec la compréhension des besoins d’affaires, et une approche pour résoudre ces défis est des plus clair.


Liens utilesZachman www.zifa.org

www.12manage.comwww.perso.orange.fr/svc/pr02.htm

IIBA www.theiiba.org

CMMi www.developpeur.journaldunet.comSWEBOK www.irgl.uqam.caWikipedia www.wikipedia.orgMacroscope www.dmr-metalink.com/fr

www.fujitsu.com/ca

Documents

L’architecture d’entreprise · 28 octobre 2005, Version 1.4 de BABoK (ajout de Draft detailed) 12 juillet 2006, Versiuon 1.6 de BABoK 10 novembre 2006, premier examen de certification