Réorganiser de manière fiable les environnements commerciaux et informatiques existants en architectures intégrées modernes et compétitives n’est pas trivial. La complexité des environnements commerciaux et informatiques s’est accumulée de manière presque incontrôlée depuis quarante ans, rendant les changements toujours plus coûteux. Ceci est dû au fait que :
- La complexité de l’environnement s’exprime souvent dans le code hérité. Les pénuries de compétences patrimoniales font grimper les coûts de maintenance et d’intégration.
- Les environnements complexes existants doivent être réaménagés par phases qui ont un sens opérationnel pour leur fonction commerciale associée. Ces phases aboutissent souvent à des remplacements massifs et risqués des systèmes, car l’ignorance de la complexité existante signifie que les changements incrémentiels potentiels sont trop difficiles à comprendre et à concevoir.
- Les méthodes de développement accéléré ont laissé aux entreprises des systèmes patrimoniaux modernes. Les applications complexes Java et .NET présentent bon nombre des mêmes problèmes que les anciennes applications COBOL.
En conséquence, une proportion croissante de l’effort de développement de nouvelles capacités d’entreprise est consacrée à la compréhension et à l’intégration avec le système complexe existant et le paysage commercial plutôt qu’à la fourniture de valeur. Il a été observé que jusqu’à 75% de l’effort global du projet est maintenant consacré à l’intégration et à la migration des logiciels plutôt qu’à de nouvelles fonctionnalités.
L’industrie informatique dans son ensemble a un faible taux de réussite dans la livraison de tels changements à grande échelle pour ses clients. L’enquête CHAOS du Standish Group a suivi une amélioration globale de la réussite des projets informatiques au cours des vingt dernières années, mais même en 2006, les grands projets informatiques échouaient encore plus souvent qu’ils ne réussissaient. L’ingénierie des changements et dans de tels environnements présente de nombreux parallèles avec les préoccupations du secteur de la construction dans le réaménagement de sites industriels ou contaminés. Ces sites sont pleins de dangers, de complexités inattendues et leur réaménagement est généralement risqué et coûteux. La complexité accumulée des environnements informatiques en a fait des sites « Brownfield ».
Ce n’est pas la complexité de la nouvelle fonction ou de toute nouvelle caractéristique du système qui est à l’origine des échecs des grands projets – c’est notre compréhension et notre communication de l’exigence globale (telle qu’identifiée dans le mois de l’homme mythique). Pour réussir, les exigences doivent inclure une compréhension précise et approfondie des contraintes de l’entreprise et de l’informatique existantes. Les outils et les méthodes « Greenfield » actuels utilisent des abstractions précoces, informelles et souvent imprécises qui ignorent essentiellement cette complexité. Les abstractions précoces et mal informées sont généralement erronées et sont souvent détectées tardivement dans la construction, ce qui entraîne des retards, des remaniements coûteux, voire des échecs de développement. Une approche orientée Brownfield embrasse la complexité existante et est utilisée pour accélérer de manière fiable le processus global d’ingénierie de la solution, y compris en permettant un changement progressif et incrémentiel chaque fois que cela est possible.
Brownfield prend l’approche standard OMG orientée modèle/pattern et la renverse. Plutôt que d’adopter l’approche conventionnelle consistant à commencer par un modèle conceptuel et à descendre jusqu’aux modèles spécifiques à la plate-forme et à la génération de code, Brownfield commence par récolter du code et d’autres artefacts existants et utilise des modèles pour abstraire formellement vers le haut, vers le niveau Architecture et Business.
Les techniques Greenfield standard sont ensuite utilisées en combinaison pour définir la cible métier préférée. Cette technique de « rencontre au milieu » est familière à d’autres méthodes de développement, mais l’utilisation extensive de l’abstraction formelle et l’utilisation de modèles à la fois pour la découverte et la génération est nouvelle.
L’architecture conceptuelle sous-jacente de tous les outils Brownfield est connue sous le nom de VITA. VITA est l’abréviation de Views, Inventory, Transformation and Artifacts. Dans une architecture VITA, la définition du problème de l’espace cible peut être maintenue en tant que « têtes » natives distinctes (bien que liées) de connaissances connues sous le nom de vues. L’avantage principal d’une vue est qu’elle peut être basée sur à peu près n’importe quel outil formel. Brownfield n’impose pas un outil ou un langage unique à un espace problématique – un principe de base est que les headfulls continuent d’être maintenus dans leurs formes et outils natifs.
Les vues natives sont ensuite rassemblées et reliées en un seul Inventaire. L’Inventaire est ensuite utilisé avec une série de capacités de transformation pour produire les artefacts dont la solution a besoin.
Les vues peuvent actuellement être importées à partir d’une grande variété de sources, notamment UML, sources XML, DDL, feuilles de calcul, etc. L’outil Analysis and Renovation Catalyst d’IBM a poussé cette capacité encore plus loin via l’utilisation de grammaires formelles et d’arbres de syntaxe abstraite pour permettre à presque n’importe quel programme d’être analysé et tokenisé en une vue à inclure dans l’inventaire.
La nature cyclique rapide du cycle de découverte, de réingénierie, de génération et de test utilisé dans cette approche signifie que les solutions peuvent être affinées de manière itérative en termes de leurs définitions logiques et physiques à mesure que davantage de contraintes sont connues et que l’architecture de la solution est affinée.
Le développement brownfield itératif peut permettre le raffinement progressif des architectures logiques et physiques et des tests incrémentiels pour l’ensemble de l’approche, ce qui permet d’accélérer le développement, d’améliorer la qualité des solutions et de supprimer les défauts à moindre coût. Brownfield peut également être utilisé pour générer la documentation de la solution, en veillant à ce qu’elle soit toujours à jour et cohérente entre les différents points de vue.
L’Inventaire qui est créé par Brownfield traité peut être très complexe, étant un réseau sémantique multidimensionnel interconnecté. Le niveau de connaissance de l’Inventaire peut être très fin, très détaillé et interrelié. De telles choses sont toutefois difficiles à comprendre et peuvent constituer des obstacles à la communication. Brownfield résout ce problème en abstrayant les concepts via une meilleure estimation de l’artisan, en utilisant des modèles connus dans ses Inventaires pour extraire et déduire des relations de plus haut niveau.
Les abstractions formelles permettent de traduire la complexité de l’Inventaire en représentations plus simples, mais intrinsèquement précises, pour une consommation plus facile par ceux qui doivent comprendre l’espace du problème. Ces modèles abstraits de l’Inventaire peuvent être utilisés pour rendre automatiquement des représentations d’architecture multicouches dans des outils tels que Second Life.
Ces visualisations permettent à des informations complexes d’être partagées et vécues par de multiples individus du monde entier en temps réel. Cela améliore à la fois la compréhension et le sentiment d’une équipe unique.