Niezawodne przeprojektowanie istniejących środowisk biznesowych i informatycznych w nowoczesne, konkurencyjne, zintegrowane architektury jest nietrywialne. Złożoność środowisk biznesowych i informatycznych narasta niemal bez kontroli od czterdziestu lat, czyniąc zmiany coraz bardziej kosztownymi. Dzieje się tak, ponieważ:
- Złożoność środowiska jest często wyrażona w kodzie dziedzictwa. Niedobór umiejętności w zakresie dziedzictwa powoduje wzrost kosztów utrzymania i integracji.
- Istniejące złożone środowiska muszą być przeprojektowane w fazach, które mają sens operacyjny dla ich powiązanych funkcji biznesowych. Fazy te często prowadzą do hurtowej, ryzykownej wymiany systemów, ponieważ nieznajomość istniejącej złożoności oznacza, że potencjalne zmiany przyrostowe są zbyt trudne do zrozumienia i zaprojektowania.
- Przyspieszone metody rozwoju pozostawiły przedsiębiorstwa z nowoczesnymi systemami dziedzictwa. Złożone aplikacje Java i .NET mają wiele z tych samych problemów, co starsze aplikacje COBOL.
W rezultacie coraz większa część wysiłku związanego z rozwojem nowych możliwości biznesowych jest poświęcana na zrozumienie i integrację z istniejącym złożonym systemem i otoczeniem biznesowym, a nie na dostarczanie wartości. Zaobserwowano, że do 75% całkowitego wysiłku włożonego w projekt jest obecnie poświęcane na integrację i migrację oprogramowania, a nie na nowe funkcje.
Branża IT jako całość ma niski wskaźnik sukcesu w dostarczaniu takich zmian na dużą skalę dla swoich klientów. Badanie CHAOS przeprowadzone przez Standish Group wykazało ogólną poprawę w realizacji projektów informatycznych w ciągu ostatnich dwudziestu lat, ale nawet w 2006 r. duże projekty informatyczne nadal częściej kończyły się niepowodzeniem niż sukcesem. Zmiany inżynieryjne w takich środowiskach mają wiele podobieństw do obaw branży budowlanej związanych z przebudową terenów przemysłowych lub skażonych. Są one pełne niebezpieczeństw, nieoczekiwanych zawiłości, a ich przebudowa jest zazwyczaj ryzykowna i kosztowna. Skumulowana złożoność środowisk informatycznych sprawiła, że stały się one miejscami „Brownfield”.
To nie złożoność nowej funkcji lub jakiejkolwiek nowej charakterystyki systemu jest źródłem niepowodzeń dużych projektów – jest to nasze zrozumienie i komunikacja ogólnego wymagania (jak zidentyfikowano w The Mythical Man Month). Aby odnieść sukces, wymagania muszą zawierać precyzyjne i dokładne zrozumienie ograniczeń istniejącego biznesu i IT. Obecne narzędzia i metody „Greenfield” używają wczesnych, nieformalnych i często nieprecyzyjnych abstrakcji, które zasadniczo ignorują taką złożoność. Wczesne, niedoinformowane abstrakcje są zazwyczaj błędne i często wykrywane są na późnym etapie budowy, co powoduje opóźnienia, kosztowne przeróbki, a nawet nieudane projekty. Podejście zorientowane na Brownfielda obejmuje istniejącą złożoność i jest wykorzystywane do niezawodnego przyspieszenia całego procesu inżynierii rozwiązań, w tym umożliwienia stopniowych, przyrostowych zmian wszędzie tam, gdzie jest to możliwe.
Brownfield przyjmuje standardowe podejście OMG oparte na modelach/wzorcach i wywraca je na nice. Zamiast konwencjonalnego podejścia polegającego na rozpoczęciu od Modelu Koncepcyjnego i przejściu do Modeli Specyficznych dla Platformy oraz generowania kodu, Brownfield rozpoczyna od zbierania kodu i innych istniejących artefaktów oraz wykorzystuje wzorce do formalnego abstrahowania w górę w kierunku warstwy Architektury i Biznesu.
Standardowe techniki Greenfield są następnie używane w połączeniu w celu zdefiniowania preferowanego celu biznesowego. Ta technika „spotkania w środku” jest znana z innych metod rozwoju, ale szerokie zastosowanie abstrakcji formalnej i wykorzystanie wzorców zarówno do odkrywania, jak i generowania jest nowatorskie.
Podstawowa architektura koncepcyjna wszystkich narzędzi Brownfield jest znana jako VITA. VITA to skrót od Views, Inventory, Transformation i Artifacts. W architekturze VITA, definicja problemu przestrzeni docelowej może być utrzymywana jako oddzielne (choć powiązane) natywne „garści” wiedzy znane jako widoki. Podstawową zaletą widoku jest to, że może on być oparty na prawie każdym formalnym narzędziu. Brownfield nie narzuca jednego narzędzia lub języka na przestrzeń problemową – głównym założeniem jest to, że zbiory wiedzy nadal są utrzymywane w ich rodzimych formach i narzędziach.
Natywne widoki są następnie zebrane razem i połączone w jeden spis. Inwentarz jest następnie używany z serią możliwości transformacji w celu wytworzenia artefaktów, których potrzebuje rozwiązanie.
Widoki mogą być obecnie importowane z wielu różnych źródeł, w tym UML, źródeł XML, DDL, arkuszy kalkulacyjnych itp. Narzędzie Analysis and Renovation Catalyst firmy IBM posunęło tę zdolność jeszcze dalej poprzez wykorzystanie gramatyk formalnych i Abstract Syntax Trees, aby umożliwić prawie każdy program do parsowania i tokenizacji do Widoku w celu włączenia do Inwentarza.
Szybka cykliczna natura cyklu odkrywania, przeprojektowywania, generowania i testowania używanego w tym podejściu oznacza, że rozwiązania mogą być udoskonalane iteracyjnie pod względem ich logicznych i fizycznych definicji, ponieważ więcej ograniczeń staje się znanych, a architektura rozwiązania jest dopracowana.
Iteracyjny rozwój Brownfield może pozwolić na stopniowe udoskonalanie logicznych i fizycznych architektur oraz przyrostowe testowanie dla całego podejścia, co skutkuje przyspieszeniem rozwoju, poprawą jakości rozwiązania i tańszym usuwaniem wad. Brownfield może być również używany do generowania dokumentacji rozwiązania, zapewniając, że jest ona zawsze aktualna i spójna w różnych punktach widzenia.
Inwentarz, który jest tworzony poprzez przetwarzanie Brownfield może być bardzo złożony, będąc wzajemnie połączoną wielowymiarową siecią semantyczną. Poziom wiedzy w spisie może być bardzo drobnoziarnisty, bardzo szczegółowy i wzajemnie powiązany. Takie rzeczy są jednak trudne do zrozumienia i mogą stanowić barierę w komunikacji. Brownfield rozwiązuje ten problem poprzez abstrahowanie pojęć za pomocą najlepszego domysłu rzemieślnika, wykorzystując znane wzorce w swoich Wykazach w celu wyodrębnienia i wnioskowania o relacjach wyższego poziomu.
Abstrakcje formalne umożliwiają przetłumaczenie złożoności Wykazu na prostsze, ale z natury dokładne, reprezentacje dla łatwiejszej konsumpcji przez tych, którzy muszą zrozumieć przestrzeń problemową. Te wyabstrahowane modele Inwentarza mogą być używane do automatycznego renderowania wielowarstwowych reprezentacji architektury w narzędziach takich jak Second Life.
Takie wizualizacje umożliwiają dzielenie się złożonymi informacjami i doświadczanie ich przez wiele osób z całego świata w czasie rzeczywistym. Zwiększa to zarówno zrozumienie, jak i poczucie istnienia jednego zespołu.