Spolehlivě přetvořit stávající obchodní a IT prostředí na moderní konkurenceschopné integrované architektury není triviální. Složitost podnikových a IT prostředí se téměř nekontrolovaně hromadí již čtyřicet let a činí změny stále nákladnějšími. Je to proto, že:
- Složitost prostředí je často vyjádřena ve starším kódu. Nedostatek dovedností v oblasti starších kódů zvyšuje náklady na údržbu a integraci.
- Stávající složitá prostředí musí být přepracována ve fázích, které mají provozní smysl pro jejich související obchodní funkce. Tyto fáze často standardně vedou k plošným a riskantním výměnám systémů, protože neznalost stávající složitosti znamená, že potenciální postupné změny je příliš obtížné pochopit a navrhnout.
- Zrychlené metody vývoje zanechaly v podnicích moderní starší systémy. Komplexní aplikace Java a .NET mají mnoho stejných problémů jako starší aplikace COBOL.
V důsledku toho se stále větší část úsilí při vývoji nových podnikových schopností vynakládá na pochopení a integraci se stávajícím komplexním systémem a podnikovým prostředím spíše než na poskytování hodnoty. Bylo zjištěno, že až 75 % celkového úsilí projektu je nyní vynaloženo na integraci a migraci softwaru spíše než na nové funkce.
Odvětví IT jako celek má špatnou úspěšnost při realizaci takových rozsáhlých změn pro své klienty. Průzkum CHAOS od společnosti Standish Group sledoval za posledních dvacet let celkové zlepšení úspěšnosti realizace IT projektů, ale i v roce 2006 velké IT projekty stále častěji selhávaly než uspěly. Inženýrské změny a v takovém prostředí mají mnoho paralel se starostmi stavebního průmyslu při sanaci průmyslových nebo kontaminovaných areálů. Ty jsou plné nebezpečí, neočekávaných složitostí a jejich sanace bývá riskantní a nákladná. Nahromaděná složitost IT prostředí z nich udělala „Brownfield“ místa.
Není to složitost nové funkce nebo nějaké nové vlastnosti systému, co je příčinou selhání velkých projektů – je to naše pochopení a komunikace celkového požadavku (jak bylo identifikováno v Měsíci mýtického člověka). Aby byly požadavky úspěšné, musí obsahovat přesné a důkladné pochopení omezení stávajícího podniku a IT. Současné nástroje a metody „Greenfield“ používají časné, neformální a často nepřesné abstrakce, které takovou složitost v podstatě ignorují. Včasné, nedostatečně informované abstrakce jsou obvykle chybné a často jsou odhaleny až v průběhu výstavby, což má za následek zpoždění, nákladné přepracování a dokonce neúspěšný vývoj. Přístup orientovaný na Brownfield zahrnuje existující složitost a používá se ke spolehlivému urychlení celkového procesu inženýrství řešení, včetně umožnění postupných, inkrementálních změn, kdekoli je to možné.
Brownfield přebírá standardní přístup OMG založený na modelu/vzoru a staví jej na hlavu. Namísto konvenčního přístupu, kdy se začíná koncepčním modelem a pokračuje se k modelům specifickým pro platformu a generování kódu, začíná Brownfield sběrem kódu a dalších existujících artefaktů a používá vzory k formální abstrakci směrem nahoru k úrovni architektury a podnikání.
Standardní techniky Greenfield se pak používají v kombinaci k definování preferovaného obchodního cíle. Tato technika „setkání uprostřed“ je známá z jiných metod vývoje, ale rozsáhlé využití formální abstrakce a použití vzorů pro zjišťování i generování je nové.
Základní konceptuální architektura všech nástrojů Brownfield je známá jako VITA. VITA je zkratka pro Views (pohledy), Inventory (soupis), Transformation (transformace) a Artifacts (artefakty). V architektuře VITA lze definici problému cílového prostoru udržovat jako samostatné (i když související) nativní „hlavy“ znalostí známé jako Pohledy. Základní výhodou Pohledů je, že mohou být založeny v podstatě na jakémkoli formálním nástroji. Brownfield nevnucuje problémovému prostoru jediný nástroj nebo jazyk – základním principem je, že hlavičkové soubory jsou nadále udržovány ve svých nativních formách a nástrojích.
Nativní Pohledy jsou pak sdruženy a propojeny do jediného Soupisu. Inventář se pak používá s řadou transformačních možností k vytvoření artefaktů, které řešení potřebuje.
Vhledy lze v současnosti importovat z nejrůznějších zdrojů včetně UML, zdrojů XML, DDL, tabulek atd. Nástroj Analysis and Renovation Catalyst od IBM posunul tuto schopnost ještě dále prostřednictvím použití formálních gramatik a abstraktních syntaktických stromů, které umožňují analyzovat a tokenizovat téměř jakýkoli program do podoby View pro zařazení do soupisu.
Rychlá cyklická povaha cyklu zjišťování, reinženýringu, generování a testování používaného v tomto přístupu znamená, že řešení lze iterativně zdokonalovat z hlediska jejich logických a fyzických definic, jakmile je známo více omezení a architektura řešení se zpřesňuje.
Iterativní vývoj Brownfield může umožnit postupné zpřesňování logické a fyzické architektury a inkrementální testování celého přístupu, což vede ke zrychlení vývoje, zlepšení kvality řešení a levnějšímu odstraňování vad. Brownfield lze také použít k vytváření dokumentace řešení, čímž se zajistí, že bude vždy aktuální a konzistentní napříč různými úhly pohledu.
Inventář, který vzniká zpracováním Brownfieldu, může být velmi složitý, neboť představuje vzájemně propojenou vícerozměrnou sémantickou síť. Úroveň znalostí v Inventáři může být velmi jemná, vysoce podrobná a vzájemně provázaná. Takové věci jsou však těžko pochopitelné a mohou představovat překážku v komunikaci. Brownfield tento problém řeší abstrakcí pojmů prostřednictvím řemeslně nejlepšího odhadu, přičemž využívá známé vzory ve svých Inventářích k extrakci a odvození vztahů vyšší úrovně.
Formální abstrakce umožňují převést složitost Inventáře do jednodušších, ale ve své podstatě přesných reprezentací pro snadnější konzumaci těmi, kteří potřebují porozumět problémovému prostoru. Tyto abstrahované modely Inventáře lze použít k automatickému vykreslování vícevrstvých reprezentací architektury v nástrojích, jako je Second Life.
Takové vizualizace umožňují sdílení složitých informací a jejich prožívání více osobami z celého světa v reálném čase. To zlepšuje porozumění i pocit jednotného týmu.