Die zuverlässige Umgestaltung bestehender Geschäfts- und IT-Umgebungen in moderne wettbewerbsfähige, integrierte Architekturen ist nicht trivial. Die Komplexität von Geschäfts- und IT-Umgebungen nimmt seit vierzig Jahren fast ungebremst zu und macht Veränderungen immer teurer. Dies liegt daran, dass:
- Die Komplexität der Umgebung drückt sich häufig in veraltetem Code aus. Der Mangel an Legacy-Kenntnissen treibt die Wartungs- und Integrationskosten in die Höhe.
- Bestehende komplexe Umgebungen müssen in Phasen umgestaltet werden, die für die jeweilige Geschäftsfunktion sinnvoll sind. In diesen Phasen kommt es häufig zu einem umfassenden und riskanten Austausch von Systemen, da die Unkenntnis der bestehenden Komplexität bedeutet, dass potenzielle inkrementelle Änderungen zu schwer zu verstehen und zu entwickeln sind.
- Beschleunigte Entwicklungsmethoden haben dazu geführt, dass Unternehmen moderne Altsysteme besitzen. Komplexe Java- und .NET-Anwendungen haben viele der gleichen Probleme wie ältere COBOL-Anwendungen.
Infolgedessen wird ein zunehmender Teil des Aufwands für die Entwicklung neuer Geschäftsfunktionen für das Verständnis und die Integration in die bestehende komplexe System- und Geschäftslandschaft aufgewendet, anstatt einen Mehrwert zu schaffen. Es wurde beobachtet, dass bis zu 75 % des gesamten Projektaufwands auf die Softwareintegration und -migration entfallen und nicht auf die Entwicklung neuer Funktionen.
Die IT-Branche als Ganzes hat eine schlechte Erfolgsquote bei der Durchführung solch umfangreicher Veränderungen für ihre Kunden. Die CHAOS-Umfrage der Standish Group hat in den letzten zwanzig Jahren eine allgemeine Verbesserung des Erfolgs bei der Durchführung von IT-Projekten festgestellt, aber selbst im Jahr 2006 scheiterten große IT-Projekte noch häufiger als sie erfolgreich waren. Die technischen Veränderungen in solchen Umgebungen weisen viele Parallelen zu den Bedenken der Bauindustrie bei der Sanierung von Industrie- oder Altlastenstandorten auf. Sie sind voller Gefahren, unerwarteter Komplexität und in der Regel risikoreich und teuer zu sanieren. Die angehäufte Komplexität von IT-Umgebungen hat sie zu „Brownfield“-Standorten gemacht.
Es ist nicht die Komplexität der neuen Funktion oder der neuen Systemeigenschaften, die die Ursache für das Scheitern von Großprojekten sind – es ist unser Verständnis und unsere Kommunikation der Gesamtanforderungen (wie im Monat des Mythos Mensch festgestellt). Um erfolgreich zu sein, müssen die Anforderungen ein genaues und gründliches Verständnis der Beschränkungen des bestehenden Geschäfts und der IT beinhalten. Aktuelle „Greenfield“-Werkzeuge und -Methoden verwenden frühe, informelle und oft ungenaue Abstraktionen, die diese Komplexität im Wesentlichen ignorieren. Frühe, unzureichend informierte Abstraktionen sind in der Regel falsch und werden oft erst spät in der Entwicklung erkannt, was zu Verzögerungen, teuren Nacharbeiten und sogar Fehlentwicklungen führt. Ein Brownfield-orientierter Ansatz umfasst die vorhandene Komplexität und wird verwendet, um den gesamten Lösungsentwicklungsprozess zuverlässig zu beschleunigen, einschließlich der Ermöglichung schrittweiser, inkrementeller Änderungen, wo immer dies möglich ist.
Brownfield nimmt den Standard OMG Modell/Pattern-getriebenen Ansatz und stellt ihn auf den Kopf. Anstatt den konventionellen Ansatz zu verfolgen, bei dem man mit einem konzeptionellen Modell beginnt und dann zu plattformspezifischen Modellen und Codegenerierung übergeht, beginnt Brownfield mit dem Sammeln von Code und anderen vorhandenen Artefakten und verwendet Muster, um formal nach oben zur Architektur- und Geschäftsebene zu abstrahieren.
Standard Greenfield-Techniken werden dann in Kombination verwendet, um das bevorzugte Geschäftsziel zu definieren. Diese „meet in the middle“-Technik ist aus anderen Entwicklungsmethoden bekannt, aber der umfassende Einsatz von formaler Abstraktion und die Verwendung von Mustern sowohl für die Entdeckung als auch für die Generierung ist neu.
Die zugrunde liegende konzeptionelle Architektur aller Brownfield-Tools ist als VITA bekannt. VITA steht für Views, Inventory, Transformation und Artifacts. In einer VITA-Architektur kann die Problemdefinition des Zielraums als separate (wenn auch zusammenhängende) native „Headfulls“ von Wissen, bekannt als Views, gepflegt werden. Der Hauptvorteil einer Sicht ist, dass sie auf so gut wie jedem formalen Werkzeug basieren kann. Brownfield zwingt einem Problemraum nicht ein einziges Werkzeug oder eine einzige Sprache auf – ein zentraler Grundsatz ist, dass die „Headfulls“ weiterhin in ihrer ursprünglichen Form und mit ihren eigenen Werkzeugen gepflegt werden.
Native Views werden dann zusammengeführt und zu einem einzigen Inventar verbunden. Das Inventar wird dann mit einer Reihe von Transformationsfunktionen verwendet, um die Artefakte zu erzeugen, die die Lösung benötigt.
Sichten können derzeit aus einer Vielzahl von Quellen importiert werden, einschließlich UML, XML-Quellen, DDL, Tabellenkalkulationen usw. Das Tool Analysis and Renovation Catalyst von IBM hat diese Fähigkeit durch die Verwendung formaler Grammatiken und abstrakter Syntaxbäume noch weiter ausgebaut, so dass nahezu jedes Programm geparst und in eine View für die Aufnahme in das Inventar umgewandelt werden kann.
Der schnelle zyklische Charakter des bei diesem Ansatz verwendeten Zyklus von Entdeckung, Re-Engineering, Generierung und Test bedeutet, dass Lösungen iterativ in Bezug auf ihre logischen und physischen Definitionen verfeinert werden können, wenn mehr Einschränkungen bekannt werden und die Lösungsarchitektur verfeinert wird.
Die iterative Brownfield-Entwicklung kann die schrittweise Verfeinerung der logischen und physischen Architekturen und inkrementelle Tests für den gesamten Ansatz ermöglichen, was zu einer Beschleunigung der Entwicklung, einer verbesserten Lösungsqualität und einer kostengünstigeren Fehlerbeseitigung führt. Brownfield kann auch zur Erstellung von Lösungsdokumentationen verwendet werden, um sicherzustellen, dass diese immer auf dem neuesten Stand und über verschiedene Gesichtspunkte hinweg konsistent sind.
Das Inventar, das durch die Brownfield-Verarbeitung erstellt wird, kann sehr komplex sein, da es sich um ein miteinander verbundenes mehrdimensionales semantisches Netz handelt. Der Wissensstand im Inventar kann sehr feinkörnig, sehr detailliert und miteinander verbunden sein. Solche Dinge sind jedoch schwer zu verstehen und können Kommunikationsbarrieren darstellen. Brownfield löst dieses Problem durch die Abstrahierung von Konzepten nach bestem Wissen und Gewissen, indem es bekannte Muster in seinen Inventaren verwendet, um Beziehungen auf höherer Ebene zu extrahieren und abzuleiten.
Formale Abstraktionen ermöglichen es, die Komplexität des Inventars in einfachere, aber inhärent genaue Darstellungen zu übersetzen, die von denjenigen, die den Problemraum verstehen müssen, leichter genutzt werden können. Diese abstrahierten Inventarmodelle können verwendet werden, um automatisch mehrschichtige Architekturdarstellungen in Tools wie Second Life zu rendern.
Solche Visualisierungen ermöglichen es, dass komplexe Informationen von mehreren Personen aus der ganzen Welt in Echtzeit geteilt und erlebt werden können. Dies verbessert sowohl das Verständnis als auch das Gefühl für ein einziges Team.