Urbanisation SI
"Mais qui joue en première base ?"
Mais qui crée la bande de règlement destinée à la banque pour qu'elle prélève les cotisations des clients qui on demandé le prélèvement automatique à échéance ?
C'est la question que se pose un analyste fonctionnel pour un projet stratégique d'une grande organisation. "J'ai consulté les métiers, la compta, les informaticiens qui ont connaissent l'ancienne application et personne ne sait ! On a examiné l'ancienne application, on ne trouve rien !"
"Mais qui crée la bande de règlement ?" Cet analyste aurait du posé la question au département "urbanisme", qui est censé avoir la cartographie applicative existante ou est répertoriée tous les blocs applicatifs. Normalement, le processus de cotisation, récupère ou crée toutes les entités métiers, les formate dans le langage pivot commun à toute l'entreprise puis les met à disposition d'un processus transverse qui les traduit techniquement au format de la banque pour que celle-ci débite les comptes des clients à la date fournie.
"Mais qui crée la bande de règlement ?" Encore faut-il, que le département "urbanisme" dispose d'un tel référentiel et qui plus est, à jour ! Le concept d'urbanisation des SI est relativement récent. La cartographie applicative de l'existant est un travail itératif de longue haleine en supposant que les bons interlocuteurs soient toujours présents et que les documentations existent et soient à jour !
Et la on touche au talon d'Achille que représente la documentation trop souvent inutilisable ou inexistante. Faire de la rétro-documentation sur du code qui a été généré est comparable à Dustin Hoffman jouant le rôle d'un autiste surdoué dans le film Rain Man et qui répète inlassablement "Qui joue en première base ?" faisant référence à un sketch humoristique de Abbott-Costello (1938) et dans lequel "Qui" désigne le nom d'un joueur provoquant un quiproquo infini.
Les cartographies produites par la cellule urbanisation du SI, sont indispensables à l'ensemble des projets de l'entreprise. Elles leurs procurent le contexte ce qui leurs évitent de faire les études amont pour connaître ce contexte. En retour, les projets doivent les mettre à jour pour les futurs projets, sans quoi on continuera à se poser la question "Mais qui joue en première base ?" :-)
"Une seule parole qui fait du bien est meilleure que cent mille discours qui ne servent à rien."
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
Donnez moi des bonnes raisons d'urbaniser mon SI ?
Un des fondamentaux de l'urbanisation du SI c'est d'avoir des référentiels constitués de cartographies de processus métiers, de modèles et d'outils pour les entités métiers et les règles d'urbanisme. Ceci permet d'avoir une vue transverse du système d'information et non plus en silo comme il y une dizaine d'années. Ce cadre d'urbanisme est primordial si l'organisation est dans une démarche d'audit et d'amélioration en se basant sur des référentiels du marché comme CobiT (Control Objective for Information and related Technology), ITIL (Information Technology Infrastructure Library), CMMi (Capability Maturity Model integrated), eSCM (eSourcing Capability Model), ...
Les informaticiens avaient une fâcheuse manie de se faire plaisir en utilisant les dernières technologies créant le "buzz" plutôt que de se cantonner à celles en adéquation avec les besoins des métiers. Les extrêmes ne sont jamais bonnes et souvent un compromis est la meilleure solution. Les nouvelles technologies que ce soit dans : les méthodes (agiles comme Scrum, Kanban, ...), dans la modélisation (BPMN Business Process Management Notation, UML Unified Modeling Language), moteur de processus exécutables (BPM Business Process Management), les moteurs de règles métiers (BRMS Business Rules Management System), les AGL (Atelier de Génie Logiciel), la génération d'applications (MDA Model Driven Architecture, MDD Model Driven Development , ...), les IHM (RIA Rich Internet Apllication), l'usine logicielle, ..., offrent des avantages concurrenciels pour qui veut bien investir dans leurs compréhensions et dans leurs biens fondés.
Le fait qu'une organisation est définie par ses processus socles, est un changement important pour toutes les parties prenantes y compris la DSI. Oubliée l'époque ou la DSI était réduite à la production, aujourd'hui ce n'est plus un centre de coûts, mais plutôt un axe stratégique qui doit s'aligner sur les buts de la direction générale et doit être tournée vers les services transverses à offrir aux métiers.
Autrefois, les DSI étaient "peinardes", elles pouvaient compter sur un état stable du système d'information. Aujourd'hui, c'est une lutte à mort entre les concurrents, c'est à qui tirera le premier pour tuer l'autre. Il faut être le premier à prendre de l'avance sur les services aux clients, sur la qualité, sur la baisse des prix. Et quand un concurrent se différencie, il faut réagir vite en s'adaptant comme les lois de Darwin concernant l'évolution des espèces sous peine de disparaître. La prévisibilité diminue, il faut répondre de plus en plus rapidement aux nouvelles lois, aux nouvelles exigences des clients, aux modes, aux évolutions technologiques, à la mondialisation.
Le système d’information est devenu lui-même un élément concurrentiel dans la stratégie de la plupart des entreprises. C’est maintenant un instrument important dans la conquête de nouveaux marchés. Pour gagner, il faut une bête de course, bien entraînée, et l'urbanisation du SI est la pour y remédier.
"La perfection est un chemin, non une fin."
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
"CobiT or not CobiT ? Telle n'est pas la question !"
CobiT (Control Objectives for Information and related Technology) est un référentiel c'est à dire une boite à outils contenant les meilleures pratiques, orienté dans le domaine de la gouvernance.
Comme toujours on peut appliquer une approche top-down traduisant avec efficience les objectifs stratégiques d'entreprise en un ensemble d'objectifs informatiques cohérents, eux même alimentés par un ensemble de processus CobiT.
Le pragmatisme de CobiT vient de la fourniture de tableaux de correspondance permettant d'identifier l'ensemble des objectifs informatiques dérivant de chaque objectif métier, puis les processus CobiT liés aux objectifs informatiques. CobiT fournit la démarche concernant les technologies, les applications, les compétences, l'architecture technique, l'efficience et la conformité des exigences métiers, la gouvernance et enfin l'analyse de la maturité des processus.
L'approche bottom-up quand à elle, permet un audit d'objectifs CobiT, d'identifier les forces et les faiblesses informatiques et les impacts éventuels sur les métiers. La DSI a donc à sa disposition, un excellent outil d'analyse de risques.
Lors d'une mission pour un service public, la DSI avait demandé une étude sur l'efficience de la gouvernance de son SI suite à une fusion. Les processus CobiT furent passés en revue pour déterminer ceux qui étaient prioritaires. Dans le domaine "Planifier et Organiser (PO)", les processus "Définir un plan stratégique informatique (PO1)", "Définir l'architecture de l'information (PO2)", "Gestion des risques (PO9)", et dans le domaine "Distribuer et soutenir (DS)", le processus "Gérer les services de Tiers (DS2)" fut identifié. L'étape suivante a consisté à analyser leur degré de maturité grâce à la vérification de leur mise place, leur formalisation, leur diffusion, l'outillage, les métriques et s'il existait une démarche d'amélioration continue. Une notation (0 à 5) est attribuée en fonction du modèle CobiT. Pour chaque processus, la maturité mesurée du client est mise en perspective par rapport à l’état de l’art d’une part (la moyenne constatée dans un échantillon représentatif d’entreprises) et par rapport aux entreprises les plus en avance dans le domaine (best of breed) d’autre part.
Concernant le processus "Définir un plan stratégique informatique (PO1)", les points positifs étaient qu'un schéma directeur était réalisé selon une méthode formelle avec une organisation dédiée et que le processus était formalisé, planifié, partagé par les parties prenantes et notamment les métiers qui avaient validé le fait que leurs exigences étaient bien prises en compte. Le point négatif fut que le schéma directeur devait être révisé un an après sa réalisation, ce qui ne fut pas le cas.
Pour le processus "Gérer les services de Tiers (DS2)", aucun processus formalisé fut identifié, ce qui expliqua en partie les surcoûts exorbitants de certains développements qui dépassaient de plus de 3 fois les pratiques usuelles du marché !
A chaque phase, une remise en question des objectifs définis et du niveau de maturité de chacun des processus est donc effectuée afin que le SI soit le mieux aligné avec la stratégie de l'organisation. Attention, ce n'est pas magique, vous ne trouverez pas de remèdes miracles, c'est à dire que CobiT ne précise pas le "comment" (comme le font du reste les normes !), et il faudra alors se tourner vers d'autres référentiels comme CMMi, ITIL ou eSCM et c'est du reste une tendance des plus en vogue qui est d'utiliser le meilleur de chaque référentiel, nous y reviendrons dans un prochains épisode.
"Je ne connais pas d'autres marques de supériorité que la bonté."
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
Mais où va ITIL ?
Un rérentiel genre ITIL (Information Technology Infrastructure Library) ou CMMi (Capability Maturity Model integration) est une boite à outil dans laquelle chaque entreprise peut puiser des bonnes pratiques pour améliorer ses processus. Lorsqu'il est reconnu sur le marché et utilisé par bon nombre d'organisations, on parle alors de standard. A ne pas confondre avec une norme, édictée par une instance de normalisation comme l'ISO (International Standart Organization), correspondant à des concepts à caractères universelles et permettant d'avoir un langage commun. Une nomenclature permet de décomposer une problématique en éléments plus fins à des fins par exemple de benchmarking (comparer ses coûts avec d'autres départements en interne ou d'autres sociétés en externe). La méthodologie est une démarche structurante pour réaliser une tâche comme le UP (Unified Process) basée sur les itérations et les use case.
ITIL a comme périmètre la mise sous contrôle de la production grâce à l'application des meilleures pratiques décrites dans 8 documents. Le 1er traite des centres de services, de la gestion des incidents, des problèmes, des mises en production et des configurations. Les autres traitent des sujets suivants :
- le point de vue de l'entreprise
- la gestion des applications
- la gestion du parc logiciel
- la gestion de l'infrastructure
- la gestion de la sécurité
- la planification pour la mise en oeuvre des services
ITIL V3, qui complète la V2, met l'accent sur le catalogue et le cycle de vie du service : Service Strategy, Sevice Design, Service Transition, Service Operation, Amélioration continue des services.
Le service strategy atténue le gouffre entre les experts métiers et les informaticiens, en remplaçant les termes techniques par le langage des affaires. ITIL accroît donc son territoire jusqu'ici cantonné à l'exploitation et la production informatique (ITIL V2) à la gouvernance des SI jusqu'ici chasse gardée de CobiT (Control objectives for information and related Technology). ITIL V3 ambitionne de développer l'aspect stratégique des services, ceci de leur conception jusqu'à leur fonctionnement en passant par leur mise place et leur amélioration continue.
Le ROI (Return On Investment) et la création de valeur sont maintenant présents dans ITIL V3. Le ROI client permet de s'assurer que le SI n'est pas un centre de coûts mais un actif stratégique pour l'entreprise. Ceci implique la mise en place d'indicateurs pour mesurer la performance et piloter les services. L'amélioration constante des services pousse à la pro activité évitant de mettre en place des améliorations uniquement lors de crises correspondant à des incidents graves.
L'évolution et la complexité des métiers s'accroîssent de manière exponentielle et conduisent souvent à des structures en silos non interopérable. Les exigences non fonctionnelles comme la performance, la disponibilité, la réactivité, la maîtrise des risques de la part des métiers contribuent aussi à ce système technologique vertical très coûteux.
Les métiers ont toujours suspecté les informaticiens de se faire plaisir en adoptant les toutes dernières technologies à la mode au détriment de celles moins sexy mais correspondant mieux à leurs besoins et à la valeur ajoutée !
Comme un funambule sur la corde raide qui sans arrêt rétablit l'équilibre, il faut en permanence concilier les approches techniques et métiers pour éviter la dictature d'un domaine préjudiciable à l'entreprise.
"Aimez qui vous résiste et croyez qui vous blâme."
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
CMMi, un projet comme un autre ?
La Direction générale demande de plus en plus des comptes à la DSI considérée presque comme un "vulgaire presta" ! Qu'en est il de son alignement sur les objectifs stratégiques métiers, de la maîtrise des coûts, des risques et de la gouvernance SI ? Plutôt que de réinventer la roue et de se lancer dans sa propre méthode, mieux vaut se référer aux retours d'expérience d'un ensemble d'entreprises, compilés sous forme de standard comme CMMi (Capability Maturity Model integrated) spécialisé dans l'ingénierie logicielle et visant la direction des études. CMMi est un guide pratique, un mode d'emploi et il appartient à l'entreprise de décider quels processus sont prioritaires et quels sont ceux qu'elle va mettre en oeuvre. Elle doit adapter les processus suggérés et implémenter sa propre solution en fonction de son contexte car chaque organisation est unique au monde. La DSI ne doit plus se concentrer sur la technique mais doit penser processus et services. Comme on l'a vu dans un précédent blog, la conduite du changement est la clé de la réussite aussi bien de la démarche d'urbanisation que de la mise en place d'un tel référentiel. Elle doit être mise en oeuvre très tôt et nécessite le soutien de tous les acteurs, de la direction générale, directions métiers, DSI et les diverses directions projets. Il est indispensable que la DG se donne tous les moyens de pilotage sans cela c'est l'avortement de la mise en oeuvre de CMMi.
Les signes d'un manque de méthode et de gouvernance sont les insatisfactions des clients, le dépassement de coût et des délais des projets voire leur échec, le manque de visibilité et de réactivité face à l'ouverture des marchés et au manque de maîtrise des risques. Par opposition à la certification ISO ou l'entreprise est certifiée ou non, CMMi permet une amélioration progressive de ses processus. Cinq niveaux sont définis (initial, processus géré, défini, maîtrisé, optimisation) regroupant un ensemble de processus auxquels correspondent des meilleures pratiques que l'entreprise est censée mettre en oeuvre avec succès pour passer au niveau de maturité suivant. Les pratiques sont composées d'activités liées à des produits de sortie (livrables) servant de critères pour la certification. L'organisation doit décrire dans ses modes opératoires et ses guides méthodologiques quelles sont les démarches et les outils qu'il faut utiliser pour réaliser le produit de sortie. Parmi ces meilleures pratiques on peut citer la gestion des exigences, la traçabilité, planification, pilotage, gestion des fournisseurs, vérification et validation des produits, assurance qualité, gestion de configuration, gestion et analyse des métriques, ...
La mise en oeuvre de CMMi est un projet comme n'importe quel autre projet et doit passer par les étapes classiques de l'appropriation par les équipes projet, du modèle d'architecture et des meilleures pratiques ; l'adaptation et la construction du référentiel spécifique de l'entreprise, la communication ; le plan de formation adapté à chaque population de profil d'acteur (MOA, expert métier, MOE, chef de projet, développeur, recetteur, ...) et enfin le déploiement du référentiel CMMi dans l'entreprise sans oublier de mettre en place les critères pour apprécier l'amélioration des processus et le retour sur investissement.
"La sagesse est de voir le nouveau dans l'ordinaire, en s'accomodant du monde tel qu'il est. Il y a des trésors cachés dans l'instant présent."
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
Vos fournisseurs, font-ils du bon boulot ?
Lorsqu'un projet fait intervenir des fournisseurs dans le cadre de fourniture de services utilisant les technologies de l'information (IT), les résultats sont décevants dans 50% des cas. Pour la fourniture de services applicatifs, on se retrouve dans une relation MOA (client) - MOE (fournisseur) avec toutes les difficultés de communication que l'on connaît.
Le référentiel e-SCM (eSourcing Capability Model) permet d'améliorer la relation client/fournisseur. Il est tout naturellement décomposé en 2 parties : e-SCM-CL (pour CLient) et e-SCM-SP (Service Provider = fournisseur de services).
Le référentiel comprend 17 domaines d'aptitude pour la partie cliente et 10 pour la partie fournisseur. Le cycle de vie se compose de 5 étapes : analyse (CL seulement), démarrage, fourniture, réversibilité, permanent et des niveaux d'aptitudes de 1 à 5.
L'externalisation est un risque pour la DSI (perte de connaissances, de la maîtrise de certains processus, ...), sa réussite passe par un ensemble de règles et d'engagements qui doivent être établies des 2 côtés. Une compréhension mutuelle doit passer par des personnes ayant le même niveau de compétences de part et d'autre, ainsi on s'évitera de nombreux pièges risquant de mener à l'échec.
Preuve par 9 d'un programme
Les méthodes formelles peuvent être utilisées pour donner une spécification du système que l'on souhaite développer, au niveau de détails désiré. Une spécification formelle du système est basée sur un langage formel dont la sémantique est bien définie (contrairement à une spécification en langage naturel qui peut donner lieu à différentes interprétations). Cette description formelle du système peut être utilisée comme référence pendant le développement. De plus, elle peut être utilisée pour vérifier (formellement) que la réalisation finale du système (décrite dans un langage informatique dédié) respecte les attentes initiales (notamment en termes de fonctionnalité).
Une fois qu'une spécification a été développée, elle peut être utilisée comme référence pendant le développement du système concret (mise au point des algorithmes, réalisation en logiciel et/ou circuit électronique). Par exemple:
- Si la spécification formelle est dotée d'une sémantique opérationnelle, le comportement observé du système concret peut être comparé avec le comportement de la spécification (qui elle-même doit être exécutable ou simulable). De plus, une telle spécification peut faire l'objet d'une traduction automatique vers le langage cible.
- Si la spécification formelle est dotée d'une sémantique axiomatique, les préconditions et postconditions de la spécification peuvent devenir des assertions dans le code exécutable. Ces assertions peuvent être utilisées pour vérifier le fonctionnement correct du système pendant son exécution (ou simulation), ou mieux encore des méthodes statiques (preuve de théorème, model-checking) peuvent être utilisées pour vérifier que ces assertions seront satisfaites pour toute exécution du système.
Une spécification peut être utilisée comme base pour prouver des propriétés sur le système. La spécification est le plus souvent une représentation abstraite (avec moins de détails) du système en développement: débarrassé de détails encombrants, il est en général plus simple de prouver des propriétés sur la spécification que directement sur la description complète et concrète du système.
Certaines méthodes, comme la Méthode B s'appuient sur ce principe: le système est modélisé à plusieurs niveaux d'abstraction, en partant du plus abstrait et en allant au plus concret (ce processus est appelé « raffinement » puisqu'il ajoute des détails au fur et à mesure); la méthodologie assure que toutes les propriétés prouvées sur les modèles abstraits sont conservées sur les modèles concrets. Cette garantie est apportée par un ensemble de preuves dites «de raffinement».
"C'est en essayant encore et encore que le singe apprend à bondir"
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
La vérité (si je mens) sur l'urbanisation
L'entreprise repose sur ses processus métiers. Un SI construit autour des processus révolutionne l'exploitation. La mise en œuvre d'un ESB (Enterprise Service Bus), d'un BPM (Business Process Management), d'un moteur de règles (BRMS Business Rules Management System)alors , ... , implique de repenser l'exploitation qui se rapprochera plus du métier.
La vérité sur la réussite d'une démarche d'urbanisation est la conduite du changement qui doit s'appliquer à tous les secteurs MOA, MOE, gouvernance, développement, intégration, architecture, tests, exploitation.
Les fondations d'une urbanisation de SI repose sur le modèle métier. Les cartographies et les processus sont basées dessus.
Par essence même, un SI urbanisé utilise des entités distribuées et se pose alors les classiques problèmes de synchronisation, mais heureusement toutes les solutions existent aujourd'hui.
Refondre des nouvelles applications nécessite une migration des données. Ce sujet doit être étudié dés le début et doit attirer toutes les attentions des différentes directions. Comme pour une ville avec les permis de construire et de démolir, on doit dés la conception d'une application prévoir une destruction aisée. Je me souviens d'avoir travaillé pour une organisation et j'entendais souvent parler d'une application antédiluvienne qui continuait de tourner, que plus personne n'utilisait, qui produisait quelques logs mais que personne n'osait arrêter par méconnaissance des impacts que cela pouvaient entraîner.
Comme dans le cycle de développement en cascade, analyse, conception, spécifications, réalisation, dans le processus urbanisme > architecture > construction > déploiement, la difficulté va en augmentant. Rien ne sert d'avoir de bonnes idées si on ne parvient pas à les mettre en pratiques.
L'urbanisation des SI est l'affaire de l'interopérabilité des blocs applicatifs qui passe nécessairement par la galaxie XML (XML, XSD, XSLT, WSDL, XMI, …). Ces domaines doivent maîtrisés par l'ensemble des parties prenantes.
L'urbanisation implique souvent la refonte du SI, mais attention ce ne doit pas être l'inverse !
L'urbanisation est aussi et surtout une affaire de conception. Une conception mal pensée et c'est toute l'agilité du SI qui s'écroule.
Comme dans tout projet, la réussite est avant tout une affaire d'équipe compétente et motivée, à charge à la direction d'entretenir ces critères de manière continue.
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
Quels sont les axes de recherche et développement de l'urbanisation ?
Un premier axe de recherche et développement contribuant à l'urbanisation des SI est la norme MDA (Model Driven Architecture), l'architecture pilotée par les modèles, a pour objectif de produire des applications moins chères et plus fiables. Le concept de base est de partir de modèles métier indépendants d'une implémentation technique et de transformer ces modèles suivant des règles afin d'obtenir des modèles en fonction d'une architecture technique cible. La transformation d'un modèle de classe UML en tables SQL (MPD Modèle Physique de données) est à MDA ce que le fameux "Hello world" est aux langages de programmation. Mes retours d'expérience ont montré que générer les DDL (Data Definition Language) c'est-à-dire les scripts SQL pour créer les tables d'une base de données à partir des diagrammes de classe métier UML, permet de réduire les coûts et fiabilise le code qui n'est plus manuelle mais généré automatiquement. De même les outils MDA ou de génération de code permettent à partir d'un modèle métier de générer du WSDL (Web Service Definition Language) pour définir les contrats des web services, du XSD (eXtensible Schema Definition) pour les modèles de documents XML, ou encore pour générer du code Java. Malheureusement ce n'est pas la solution miracle car le code produit comme tout ce qui est généré est très lourd et verbeux. Pour pouvoir manipuler un modèle, il faut un méta modèle décrivant le modèle. On peut accéder aux attributs et méthodes d'un objet parce qu'ils sont décrit dans le modèle (la classe). De même, au niveau supérieur, une classe est une instance de la classe "Classe", un attribut est une instance de la classe "Attribut", … Ce méta-modèle est normalisé par l'OMG (MOF Meta Object Facility). Il y a même un méta-méta- modèle et heureusement ça s'arrête la ! Le point d'attention est la conduite du changement du fait du niveau d'abstraction plus élevé, de l'utilisation de méta-modèles et des nouveaux outils utilisés.
Un autre axe, est l'informatique autonome (autonomic computing) consistant à détecter les pannes et à les réparer automatiquement fait partie d'âpres recherches et contribuerait grandement à réduire les coûts d'exploitation.
Dans l'avenir, la complexité grandissante des SI a conduira de plus en plus (c'est déjà le cas aujourd'hui) à l'utilisation du "grid computing". La technique est de mettre à disposition une infrastructure virtuelle de ressources informatiques partagées, distribuées, hétérogènes, délocalisées et autonomes.
Un des autres aspects de l'urbanisation qui va se développer est le BAM (Business Activity Monitoring) permettant aux responsables métier de mesurer les performances des processus métier et définir des alertes sur les KPI (Key Performance Indicators). Des fonctions de correction et de remise en marche telles que des reprises automatiques, réparation manuelles, compensation, store & forward sont déjà proposées par certains outils de BPM (Business Process Management) comme IBM BPM.
On peut se prêter à rêver à des systèmes s'inspirant des mécanisme du vivant, apprenant tout seul et s'auto réparant d'ailleurs d'ailleurs l'intelligence artificielle est à nouveau sur le devant de la scène.
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
L'agilité ou l'art du paramétrage
Bien avant les moteurs de processus métiers exécutables (BPM Business Process Management) et moteurs de règles métiers (BRMS Business Rules Management system), la flexibilité passait par de simples écrans de paramétrage de l'application. Les évolutions se font alors très rapidement puisque le paramétrage agit sur les attributs des objets métiers. Coté organisationnel, il y a des profils "paramétreur", avec même des niveaux "expert", responsables du "réglage" des applications, mettant à jour les référentiels et créant les nouvelles règles métiers pour les traitements, l'utilisateur est complètement autonome. Normalement, la DSI devrait en principe s'effacer petit à petit concernant l'agilité. Le nombre de tests est aussi réduit.
L'agilité est d'autant plus importante que le spectre du paramétrage est étendu sur le plan métier. Plus le degré d'exposition c'est-à-dire les possibilités offertes au paramétreur seront importantes ainsi que la déclarativité du paramétrage et plus on ira dans le sens de l'agilité. Le paramétrage doit être déclaratif c'est-à-dire qu'on spécifie le "quoi" et pas le "comment". Pour se faire il faut par exemple utiliser au maximum les concepts de l'orienté objet (encapsulation, généralisation, spécialisation, généricité) pour élevé le niveau d'abstraction du modèle de données métier. L'architecture doit être suivie à la lettre pour découpler par exemple au maximum l'IHM des services métiers. Le modèle métier doit être le plus évolutif possible grâce à une bonne couche d'abstraction. Qu'une évolution métier nécessite des changements dans un modèle de données simple est normale et classique, mais que le coût soit exorbitant parce que le modèle n'est pas évolutif et qu'il faille tout casser et tout refaire, est inacceptable aujourd'hui avec toutes les bonnes pratiques de conception objet (voir design pattern du GoF Gang of Four). L'agilité se travaille aussi au niveau de l'appropriation client/utilisateur. Une communication efficace doit être pratiquée entre les 2.
Pensez évolutivité et réutilisabilité doit être un mode de pensée systématique.
Pour pratiquer l'agilité il faut comme tous les sports une hygiène de vie qui se traduit par l'application au quotidien d'une méthode, de règles, de bonne pratiques d'urbanisation, d'architecture et de conception sans oublier la technique pour évoluer sans quoi on risque de s'enliser dans une mauvaise spirale conduisant à ne plus progresser !
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/