Présentation faite à l’EPITA le 27 octobre
“Brève introduction à l’Architecture d’entreprise” faite aux étudiants de l’EPITA le 27 octobre 2010. (cliquer sur ce lien pour avoir une vue élargie)
“Brève introduction à l’Architecture d’entreprise” faite aux étudiants de l’EPITA le 27 octobre 2010. (cliquer sur ce lien pour avoir une vue élargie)
Papier publié sur le Hub “Solutions Logicielles” en tant que membre de l’équipe d’experts
Des unités d’affaires compétentes, hautement spécialisées, qui se développent chacune en suivant les orientations stratégiques de l’entreprise : n’est-ce pas une description parfaite des entreprises que nous connaissons ? Précisément. Car chaque unité d’affaire ou métier vérifie soigneusement les documents ou les informations qu’on lui transmet, les corrige, sans se soucier de savoir si une autre unité d’affaire l’a déjà fait. Elle exécute ses opérations, en contrôle la qualité avec des exigences élevées, et transmets le résultat sous une forme qu’elle estime la plus adaptée. Les systèmes d’information automatisent cette logique.
Au sein de ces organisations, dites en silos, la facture ne suit pas automatiquement la fourniture d’un service au client, on continue de vendre des services à des clients qui engloutissent la marge et on a du mal à établir une vision partagée du chiffre d’affaires.
Pourtant, avec le management par les processus et le Web, nous sommes dans l’ère de l’intégration : les opérations se font en temps réel, la production est tirée par la demande client. L’optimum global n’est plus la somme des optimums locaux.

Le mois dernier, j’ai assisté au colloque de la Fondation Cigref sur l’innovation numérique pour la transformation des entreprises. Je ne vais pas vous répéter une histoire que vous pourrez écouter ici : 2e colloque. Je voudrais simplement en souligner quelques moments.
Françoise Mercadal-Delasalles, Directeur des ressources humaines de la Société Générale, décrit comment la stratégie actuelle de la banque, basée sur l’innovation et sur le tissage d’une nouvelle relation avec ses clients, est en ligne avec les objectifs de recherche de la Fondation Cigref qui veulent montrer comment les usages des technologies de l’information soutiennent l’innovation au sein des entreprises . J’ai également noté une autre similitude : la culture internationale forte de la Société Générale et de la Fondation Cigref qui peut prétendre au rang d’organisme international de premier plan sur sur les technologies de l’information.
Taobao.com, leader chinois dans le commerce électronique, vient d’entrer dans le top 100 des entreprises ayant la plus grande valeurdans le monde des sociétés non cotées. Lu Peng, son vice-président, a livré son histoire impressionnante. J’ai eu l’occasion de discuter avec lui sur ses chiffres formidables. Si nous regardons au-delà de l’indicateur de la taille de l’entreprise, nous découvrirons bientôt que la Chine est à la première étape de l’e-commerce : «produire localement vendre localement”. Tout reste à construire pour les prochaines étapes qui sont «produire à distance vendre localement», en particulier une activité logistique capable d’acheminer les marchandises et les services jusqu’au consommateur.
[…]
Last month, I attended to the Foundation Cigref symposium on Digital Innovation for Business Transformation. I won’t tell you a whole story that you are able to listen there : 2nd symposium. I would just outline some special moments.
Françoise Mercadal-Delasalles, Head of Human Resources at Socgen, outline how the bank current strategy based on innovation and on weaving new ways of customer relationship, is in line with Cigref Foundation researches objectives which are to show how usages of Information Technology sustain business innovation. I am noting too another similarity on strong international culture of Socgen and Cigref Foundation which may claim to be a first class international think tank on Information Technology.
Taobao.com, leading Chinese company in e-commerce, has just entered the top 100 companies with the highest numerical value in the unlisted world. Lu Peng his vice-president told its impressive story. I had the opportunity to discuss a little bit about its terrific numbers. If we have a look beyond the business size indicator we would discover soon that China is at the first stage of e-Commerce which is “produced locally-sold locally”. All remain to be build for next stages which are “produced remotely-sold locally”, especially a strong logistic business to bring goods and services to the costumer premises.

La plupart des DSI, comme les managers en général, tiennent comme fondamental d’avoir accru les compétences de leur organisation. Ils ont davantage de chances d’atteindre, voire de dépasser, leurs objectifs et sont plus forts pour résister aux périodes difficiles. De plus, les collaborateurs qui ont progressé, font preuve d’une plus grande loyauté à leur égard et à celui de l’entreprise. Ces managers voient leur taux d’attrition baisser.
Pourtant, l’architecture et l’architecture d’entreprise pourraient vous surprendre. Bien que vous ayez formé tous vos architectes, vous ne parvenez pas à accélérer le rythme des changements de l’architecture de votre système d’information. Cela parce que les architectes ne réalisent qu’une partie de l’architecture, les choix de conception et les décisions sont faits par les chefs de projet. Certaines entreprises ont même inventé le nom “Les chefs de projet technique” afin de promouvoir leurs architectes à la position de manager. Cela signifie que si vous avez investi pour le déploiement d’un framework comme TOGAF parmi vos architectes, vous pouvez sans doute, manquez votre retour sur investissement.
Most of CIOs and managers see as an achievement to increase the competences of their organisation. They have better chance to outperform their goals and are stronger to withstanding the setbacks. Moreover, the collaborators who crossed a gap, improve their loyalty to them and to the company. They lower they attrition rate.
Yet, with architecture and enterprise architecture, you may be surprised. Although you have trained all your architects, you may not quicken the pace of changes in your information system architecture. This is because architects are doing only a small part of the architecture, main design and decisions are done by Project managers. Some companies have even coined the name “Technical Project managers” to promote architects to management position. This means that if you have invested to roll-out a framework like TOGAF among your architects, you may likely miss your ROI.
Ne voulons-nous tous pas mettre en œuvre des réponses simples et rapides à nos questions stratégiques ? Pas seulement à cause de la contrainte de délai de commercialisation des produits, mais aussi, parce que cela accroît la visibilité sur la valeur que nous apportons à nos entreprises. Nous avons passé beaucoup de temps à lire, à parcourir les tweets, à observer les médias sociaux, à discuter avec les fournisseurs, à assister à des conférences pour trouver les bonnes idées adaptées à notre cas. Lorsque nous en avons identifiée une, nous essayons de la mettre à côté d’une ancienne idée pour voir comment elles s’intègrent, à la manière d’un jeu de lego. Souvent, elle ne convient pas. Alors, nous stockons l’idée pour un usage ultérieur, lorsque nous trouverons une nouvelle qui va permettre de réaliser l’ensemble du montage.
Si elle convient, nous faisons une analyse de rentabilisation et nous nous mettons en quête d’un sponsor pour ce qu’il promet d’être un projet révolutionnaire pour notre entreprise. A partir de maintenant, il ne fait aucun doute que notre expérience est adaptée pour mener le projet à une réalisation réussie, sinon ce serait une autre histoire.
Le stade où un ensemble d’idées constitue une solution d’entreprise innovante, est très difficile à atteindre pour de nombreuses raisons étudiées et connues par les chercheurs en gestion. Selon les promesse du projet, certains utilisateurs peuvent accepter des inconvénients en regards des avantages, ce qui les obligent à changer leur mode de travail.
[…]
Don’t we all want to implement straight and rapid solutions to Business problems ? Not only because of the products time to market, but also, because it improves our own visibility on value we bring internally to our companies. We spent a lot reading, taping tweets, looking social medias, talking with suppliers, attending conferences as we expect to find good ideas for us. If we feel to have caught one, we try to set it next to an old one to see how they fit just like a lego game. Often it does not fit. Then we store the idea for a later stage when we will find a new one which will realise the fitting.
As soon as it fits, we make a business case and start to enlist a sponsor to what it promise to be a breakthrough project for our company. Starting from now, no doubt that we are enough experienced to lead the project to a successful achievement, otherwise it would be another story.
Reaching the point where a set of ideas makes up a breakthrough business solution, is indeed very hard for plenty of reasons studied by management researchers. According to the project promise, some may accept an imperfect fit in comparison with benefits, all things which will require people to make the bridge.
[…]
Lorsque l’IEEE s’est intéressée à l’ingénierie des exigences, elle a publié la définition suivante dans son standard IEEE Std 610.12.-1990: «Une exigence est : (1) Une condition ou une aptitude nécessaire à un utilisateur pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées.(3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).
RUP et les autres approches de développement de logiciels utilisent cette définition.
l’IIBA dans le BABOK 2,0 prend un court-circuit et élargit le périmètre de la définition de l’IEEE grâce au mot partie-prenante : “une exigence est (1) Une condition ou une aptitude nécessaire à une partie prenante pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées. (3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).
(1) concerne les exigences organisationnelles et métier tandis que (2) concerne les exigences de solution.
Pour le BABOK 2.0 (1) est découpé entre exigences d’entreprises classifient les objectifs globaux d’une organisation et les exigences des parties prenantes qui classifient les besoins des intervenants en particulier. (2) concerne les exigences fonctionnelles et non fonctionnelles.
Il est étonnant de voir comment l’IIBA a ignoré les initiatives d’Architecture d’Entreprise qui visent à renouveler la gestion des exigences au sein du cycle de vie de la transformation de l’entreprise.
Malgré tout, les exigences continuent à être collectées au travers des modèles que nous connaissons depuis les temps immémoriaux: IDEF0 , SADT , UML , BPMN , … avec quelques améliorations sur les exigences non fonctionnelles.
Alors qu’il y -t-il à la table de jeu?
[…]
Since IEEE was interested by requirements engineering and publish the following definition in its IEEE Std 610.12.-1990 : “A requirement is: (1) A condition or capability needed by a user to solve a problem or achieve an objective (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).
RUP and other software development approach use this definition.
IIBA in its BABOK 2.0 take a short circuit and make the following definition : a requirement (1) A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).
(1) is Business and organisational requirements while (2) is solution requirement.
For BABOK 2.0 (1) is splitted in Business requirements which categorize project goals within an organisation and stakeholder requirements which categorize particular stakeholder needs. (2) are splitted in functional and non functional requirements.
It is astonishing how IIBA has ignored Enterprise Architecture initiative which aims at renewing how to manage requirements lifecycle in an enterprise transformation.
But, otherwise, requirements remains collected by all models we know since time immemorial : IDEF0, SADT, UML, BPMN,… with some refinements on non functional requirements.
Then what have we got on the play mat ?
[…]