Et pourtant elle est vitale. il existe encore d'anciennes applications (mainframe/COBOL) ou la culture de documenter n'existait pas et celui qui avait la connaissance ne voulait pas la diffuser pour ne pas perdre son pouvoir.

Contraint par l'ouverture des marchés, la déréglementation et la concurrence de plus en plus d'organisations fusionnent ou se rapprochent afin de faire des économies d'échelle.

Parmi les applications existantes, on choisit celles qui seront intégrées dans le SI cible et qui contiendront toutes les nouvelles fonctionnalités. Pour faire évoluer, réutiliser et maintenir une application encore faut il savoir ce qu'il y a à l'intérieure. Quels sont les services et le modèle de données métier ? Normalement on doit avoir la documentation avec les exigences, les SFG, SFD (Spécifications Fonctionnelles Générales et Détaillée), STD (Spécifications Techniques Détaillée), dossier d'architecture technique, fonctionnel, les modèles de processus métier (BPMN Business Process Management Notation), les diagrammes UML (Unified Modeling Language), les cartographies d'urbanisation existantes et cibles. La documentation est trop souvent perçue comme une contrainte, peu utile, consommatrice de ressources et quand les échéances arrivent; elle est reléguée en toute dernière priorité.

Et pourtant elle est vitale. il existe encore d'anciennes applications (mainframe/COBOL) ou la culture de documenter n'existait pas et celui qui avait la connaissance ne voulait pas la diffuser pour ne pas perdre son pouvoir.

Ces applications sont figées pour l'éternité. Il est peine perdue de vouloir analyser les milliards de lignes COBOL avec des GOTO partout (quand elles n'ont pas été générées par un quelconque générateur qui nomme les variables incrémentalement !).

Pour pérénniser ses investissements, on doit mettre en oeuvre toutes les techniques facilitant la documentation. En effet il est stratégique pour les organisations de ne pas perdre leurs connaiisances, leurs processus métier, leur savoir faire.

Par exemple le savoir d'un expert métier constitué de règles peut être formalisé dans un moteur de règles.

C'est une étape difficile car les connaisances d'un expert sont exprimées en langage naturel avec toute sa complexité et ses ambiguités. Il faut comme toujours pour gérer la complexité diviser en niveaux de plus en plus fins. On part donc de macros règles composées de macros règles plus fines et ainsi de suite jusqu'à arriver à des règles élémentaires. Un moteur de règles possède des outils permettant aux experts métier de concevoir leurs règles directement et de les stocker dans le référentiel. Ainsi les règles sont identifiées, documentées, versionnées, sauvegardées, compilées, avec une véritable gestion de leur cycle de vie (créée, activée, archivée, compilée; ...), et un contrôle de qui peut y avoir accès et comment).

Le point remarquable c'est que l'ensemble de ces règles sont compilées à partir de leur conception en langage presque naturel (nécessitant bien sûr une préparation de la part des techniciens) et sont directement intégrées dans l'application ce qui a pour énorme avantage de raccourcir considérablement le développement.

On a donc un moyen technique permettant de structurer, de documenter, de pérénniser et d'implémenter directement les connaissances stratégiques d'une organisation.

Il ne faut pas hésiter à fournir cet effort supplémentaire au début pour s'approprier des techniques sophistiquées comme les moteurs de règles mais qui par la suite se révèlent être des atouts différenciants majeures face à la concurrence en permettant de mettre plus rapidement une fonctionnalité sur la marché (time to market) et sauvegardant pour le futur les connaissances dument acquises d'une organisation.

Voir aussi : http://urbanisation-si.blog4ever.net/