Olemassa olevien liiketoiminta- ja IT-ympäristöjen luotettava uudistaminen nykyaikaisiksi kilpailukykyisiksi, integroiduiksi arkkitehtuureiksi ei ole triviaalia. Liiketoiminta- ja IT-ympäristöjen monimutkaisuus on kasvanut lähes hallitsemattomasti neljänkymmenen vuoden ajan, mikä tekee muutoksista yhä kalliimpia. Tämä johtuu seuraavista syistä:
- Ympäristön monimutkaisuus ilmenee usein vanhassa koodissa. Legacy-osaamisen puute nostaa ylläpito- ja integrointikustannuksia.
- Olemassa olevat monimutkaiset ympäristöt on suunniteltava uudelleen vaiheissa, jotka ovat toiminnallisesti järkeviä niihin liittyvien liiketoimintatoimintojen kannalta. Nämä vaiheet johtavat usein järjestelmien suuriin, riskialttiisiin korvauksiin, koska tietämättömyys olemassa olevasta monimutkaisuudesta tarkoittaa, että mahdollisia asteittaisia muutoksia on liian vaikea ymmärtää ja suunnitella.
- Nopeutetut kehitysmenetelmät ovat jättäneet yrityksille nykyaikaisia perintöjärjestelmiä. Monimutkaisissa Java- ja .NET-sovelluksissa on monia samoja ongelmia kuin vanhoissa COBOL-sovelluksissa.
Tämän seurauksena yhä suurempi osa uusien liiketoimintaominaisuuksien kehittämisen ponnisteluista käytetään nykyisten monimutkaisten järjestelmien ja liiketoimintaympäristön ymmärtämiseen ja integrointiin sen sijaan, että tuotettaisiin arvoa. On havaittu, että jopa 75 prosenttia projektin kokonaispanostuksesta käytetään nykyään ohjelmistojen integrointiin ja siirtymiseen uusien toimintojen sijaan.
Tietotekniikka-alalla kokonaisuudessaan on huono onnistumisprosentti tällaisten laajamittaisten muutosten toteuttamisessa asiakkailleen. Standish Groupin CHAOS-tutkimuksessa on seurattu IT-projektien onnistumisen yleistä paranemista viimeisten kahdenkymmenen vuoden aikana, mutta vielä vuonna 2006 suuret IT-projektit epäonnistuivat useammin kuin onnistuivat. Muutosten suunnittelussa ja tällaisissa ympäristöissä on monia yhtäläisyyksiä rakennusteollisuuden huolenaiheisiin teollisuus- tai saastuneiden alueiden kunnostamisessa. Ne ovat täynnä vaaroja ja odottamattomia monimutkaisuuksia, ja niiden kunnostaminen on yleensä riskialtista ja kallista. Tietotekniikkaympäristöjen kertynyt monimutkaisuus on tehnyt niistä ”Brownfield”-kohteita.
Suurten projektien epäonnistumisten syynä ei ole uuden toiminnon monimutkaisuus tai uudet järjestelmäominaisuudet, vaan kokonaisvaatimusten ymmärtäminen ja niistä tiedottaminen (kuten The Mythical Man Month -teoksessa todettiin). Onnistuakseen vaatimusten on sisällettävä tarkka ja perusteellinen ymmärrys nykyisen liiketoiminnan ja tietotekniikan rajoituksista. Nykyiset Greenfield-työkalut ja -menetelmät käyttävät varhaisia, epävirallisia ja usein epätarkkoja abstraktioita, joissa tällainen monimutkaisuus jätetään pääosin huomiotta. Varhaiset, huonosti informoidut abstraktiot ovat yleensä vääriä, ja ne havaitaan usein myöhään rakennusvaiheessa, mikä johtaa viivästyksiin, kalliisiin uusintatöihin ja jopa epäonnistuneeseen kehitystyöhön. Brownfield-suuntautunut lähestymistapa hyväksyy olemassa olevan monimutkaisuuden, ja sitä käytetään nopeuttamaan luotettavasti koko ratkaisujen suunnitteluprosessia, mukaan lukien vaiheittaisten, inkrementaalisten muutosten mahdollistaminen aina kun se on mahdollista.
Brownfield ottaa OMG:n tavanomaisen malli-/kaavio-ohjatun lähestymistavan ja kääntää sen päälaelleen. Perinteisen lähestymistavan sijaan, jossa aloitetaan käsitteellisestä mallista ja edetään alustakohtaisiin malleihin ja koodin tuottamiseen, Brownfield aloittaa keräämällä koodia ja muita olemassa olevia artefakteja ja käyttää malleja abstrahoidakseen muodollisesti ylöspäin kohti arkkitehtuuri- ja liiketoimintatasoa.
Tämän jälkeen käytetään tavanomaisia Greenfield-tekniikoita yhdistelmänä ensisijaisen liiketoimintakohteen määrittämiseksi. Tämä ”meet in the middle” -tekniikka on tuttu muista kehitysmenetelmistä, mutta muodollisen abstraktion laajamittainen käyttö ja mallien käyttö sekä löytämiseen että tuottamiseen on uutta.
Kaikkien Brownfield-työkalujen taustalla oleva käsitearkkitehtuuri tunnetaan nimellä VITA. VITA on lyhenne sanoista Views, Inventory, Transformation ja Artifacts. VITA-arkkitehtuurissa kohdeavaruuden ongelmamäärittelyä voidaan ylläpitää erillisinä (vaikkakin toisiinsa liittyvinä) natiiveina tietämyksen ”pääkokonaisuuksina”, jotka tunnetaan nimellä Views. Näkymien keskeinen etu on, että ne voivat perustua lähes mihin tahansa muodolliseen työkaluun. Brownfield ei pakota ongelma-alueelle yhtä ainoaa työkalua tai kieltä – keskeisenä periaatteena on, että pääkappaleita ylläpidetään edelleen niiden omissa muodoissa ja työkaluissa.
Natiivit Näkymät kootaan yhteen ja linkitetään yhdeksi Inventoryksi. Inventaariota käytetään sitten useiden muunnosominaisuuksien avulla ratkaisun tarvitsemien artefaktien tuottamiseen.
Näkymiä voidaan tällä hetkellä tuoda monista eri lähteistä, kuten UML:stä, XML-lähteistä, DDL:stä, laskentataulukoista jne. IBM:n Analysis and Renovation Catalyst -työkalu on vienyt tämän kyvyn vielä pidemmälle käyttämällä muodollisia kielioppia ja abstrakteja syntaksipuita, joiden avulla lähes mikä tahansa ohjelma voidaan jäsentää ja muuttaa näkymäksi, joka voidaan sisällyttää inventaarioon.
Tässä lähestymistavassa käytetyn nopean löytämis-, uudelleensuunnittelu-, luomis- ja testaussyklin nopean syklisen luonteen ansiosta ratkaisujen loogisia ja fyysisiä määrittelyjä voidaan parantaa iteratiivisesti sitä mukaa, kun rajoitteet tulevat yhä tarkemmin tunnetuiksi, ja ratkaisun arkkitehtuuria hiotaan.
Iteratiivinen Brownfield-kehitys voi mahdollistaa loogisten ja fyysisten arkkitehtuurien asteittaisen tarkentamisen ja inkrementaalisen testauksen koko lähestymistavan osalta, mikä johtaa kehityksen nopeutumiseen, ratkaisun laadun paranemiseen ja halvempaan virheiden poistamiseen. Brownfield-kehitystä voidaan käyttää myös ratkaisun dokumentaation tuottamiseen, jolloin varmistetaan, että se on aina ajan tasalla ja johdonmukainen eri näkökulmista.
Brownfield-käsittelyn avulla luotu inventaario voi olla erittäin monimutkainen, sillä se on toisiinsa kytketty moniulotteinen semanttinen verkko. Inventaariossa olevan tiedon taso voi olla hyvin hienojakoista, erittäin yksityiskohtaista ja toisiinsa liittyvää. Tällaisia asioita on kuitenkin vaikea ymmärtää, ja ne voivat muodostaa esteitä viestinnälle. Brownfield ratkaisee tämän ongelman abstrahoimalla käsitteitä käsityöläisen parhaan arvauksen kautta, käyttämällä Inventaariossaan tunnettuja malleja korkeamman tason suhteiden poimimiseen ja päättelemiseen.
Formaalisten abstraktioiden avulla Inventaarion monimutkaisuus voidaan kääntää yksinkertaisemmiksi, mutta luonnostaan tarkoiksi esityksiksi, jotta ongelma-avaruuden ymmärtämisen tarpeessa olevat tahot voivat helpommin käyttää niitä. Näitä abstrahoituja Inventory-malleja voidaan käyttää monikerroksisten arkkitehtuurikuvausten automaattiseen esittämiseen Second Lifen kaltaisissa työkaluissa.
Tällaiset visualisoinnit mahdollistavat sen, että monimutkaista tietoa voivat jakaa ja kokea useat henkilöt eri puolilta maailmaa reaaliajassa. Tämä parantaa sekä ymmärrystä että tunnetta yhdestä tiimistä.