Den pålidelige omlægning af eksisterende forretnings- og it-miljøer til moderne, konkurrencedygtige, integrerede arkitekturer er ikke let at gennemføre. Kompleksiteten af forretnings- og it-miljøer er vokset næsten uhæmmet i fyrre år, hvilket har gjort ændringer stadig dyrere. Det skyldes, at:
- Miljøets kompleksitet kommer ofte til udtryk i ældre kode. Manglende kompetencer på området driver vedligeholdelses- og integrationsomkostningerne i vejret.
- Eksisterende komplekse miljøer skal ombygges i faser, der giver operationel mening for de tilknyttede forretningsfunktioner. Disse faser fører ofte til omfattende, risikable udskiftninger af systemer, da uvidenhed om den eksisterende kompleksitet betyder, at potentielle inkrementelle ændringer er for vanskelige at forstå og konstruere.
- Accelererede udviklingsmetoder har efterladt virksomhederne med moderne legacy-systemer. Komplekse Java- og .NET-applikationer har mange af de samme problemer som ældre COBOL-applikationer.
Som følge heraf bruges en stadig større del af indsatsen for at udvikle nye forretningskapaciteter på at forstå og integrere med det eksisterende komplekse system og forretningslandskab i stedet for at levere værdi. Det er blevet observeret, at op til 75 % af den samlede projektindsats nu bruges på softwareintegration og migration snarere end på ny funktionalitet.
IT-industrien som helhed har en dårlig succesrate med hensyn til at levere sådanne omfattende ændringer for sine kunder. CHAOS-undersøgelsen fra Standish Group har vist en generel forbedring af succesen med hensyn til levering af it-projekter i løbet af de sidste 20 år, men selv i 2006 mislykkedes store it-projekter stadig oftere end de lykkedes. Der er mange paralleller mellem tekniske ændringer i sådanne miljøer og byggebranchens bekymringer i forbindelse med sanering af industriområder eller forurenede områder. De er fulde af farer, uventede kompleksiteter og har en tendens til at være risikable og dyre at sanere. Den akkumulerede kompleksitet i IT-miljøer har gjort dem til “Brownfield”-områder.
Det er ikke kompleksiteten af den nye funktion eller nye systemegenskaber, der er roden til store projektfejl – det er vores forståelse og kommunikation af det overordnede krav (som identificeret i “The Mythical Man Month”). For at lykkes skal kravene indeholde en præcis og grundig forståelse af begrænsningerne i den eksisterende forretning og IT. De nuværende “Greenfield”-værktøjer og -metoder anvender tidlige, uformelle og ofte upræcise abstraktioner, som i bund og grund ignorerer denne kompleksitet. Tidlige, dårligt informerede abstraktioner er som regel forkerte og opdages ofte sent i konstruktionsfasen, hvilket resulterer i forsinkelser, dyre omarbejdninger og endog mislykkede udviklinger. En Brownfield-orienteret tilgang omfatter den eksisterende kompleksitet og bruges til pålideligt at fremskynde den samlede løsningskonstruktionsproces, herunder at muliggøre trinvise, inkrementelle ændringer, hvor det er muligt.
Brownfield tager den standard OMG-model/mønsterdrevne tilgang og vender den på hovedet. I stedet for at tage den konventionelle tilgang, hvor man starter med en konceptuel model og kører ned til platformsspecifikke modeller og kodegenerering, starter Brownfield med at høste kode og andre eksisterende artefakter og bruger mønstre til formelt at abstrahere opad mod arkitektur- og forretningsniveauet.
Standard Greenfield-teknikker anvendes derefter i kombination til at definere det foretrukne forretningsmål. Denne “meet in the middle”-teknik er velkendt fra andre udviklingsmetoder, men den omfattende brug af formel abstraktion og brugen af mønstre til både opdagelse og generering er ny.
Den underliggende konceptuelle arkitektur for alle Brownfield-værktøjer er kendt som VITA. VITA står for Views, Inventory, Transformation and Artifacts. I en VITA-arkitektur kan problemdefinitionen af målområdet opretholdes som separate (om end relaterede) native “headfulls” af viden, der er kendt som Views. Den centrale fordel ved et View er, at det kan være baseret på stort set alle formelle værktøjer. Brownfield pålægger ikke et enkelt værktøj eller sprog til et problemområde – en af de centrale principper er, at hovedindholdet fortsat skal vedligeholdes i deres oprindelige former og værktøjer.
Native Views samles og sammenkædes derefter i en enkelt fortegnelse. Inventariet bruges derefter sammen med en række transformationsmuligheder til at producere de artefakter, som løsningen har brug for.
Views kan i øjeblikket importeres fra en lang række forskellige kilder, herunder UML, XML-kilder, DDL, regneark osv. Analysis and Renovation Catalyst-værktøjet fra IBM har taget denne mulighed endnu længere via brugen af formelle grammatikker og Abstract Syntax Trees for at gøre det muligt at analysere og omdanne næsten ethvert program til et View, der kan indgå i Inventory.
Den hurtige cykliske karakter af den opdagelses-, reengineer-, genererings- og testcyklus, der anvendes i denne tilgang, betyder, at løsninger kan forfines iterativt med hensyn til deres logiske og fysiske definitioner, efterhånden som flere af begrænsningerne bliver kendt, og løsningsarkitekturen forfines.
Iterativ Brownfield-udvikling kan muliggøre en gradvis forfinelse af logiske og fysiske arkitekturer og inkrementel testning for hele tilgangen, hvilket resulterer i en acceleration af udviklingen, forbedret løsningskvalitet og billigere fjernelse af fejl. Brownfield kan også bruges til at generere løsningsdokumentation, der sikrer, at den altid er opdateret og konsistent på tværs af forskellige synsvinkler.
Den Inventory, der skabes gennem Brownfield-processing, kan være meget kompleks, idet den er et indbyrdes forbundet multidimensionelt semantisk netværk. Niveauet af viden i fortegnelsen kan være meget finkornet, meget detaljeret og indbyrdes relateret. Sådanne ting er imidlertid svære at forstå og kan skabe hindringer for kommunikationen. Brownfield løser dette problem ved at abstrahere begreber via et håndværksmæssigt bedste gæt ved at bruge kendte mønstre i sine opgørelser til at udtrække og udlede relationer på højere niveau.
Formelle abstraktioner gør det muligt at oversætte opgørelsens kompleksitet til enklere, men i sagens natur nøjagtige, repræsentationer for at gøre det lettere for dem, der skal forstå problemrummet, at bruge dem. Disse abstraherede Inventory-modeller kan bruges til automatisk at gengive arkitekturrepræsentationer i flere lag i værktøjer som Second Life.
Sådanne visualiseringer gør det muligt at dele og opleve komplekse oplysninger af flere personer fra hele verden i realtid. Dette forbedrer både forståelsen og følelsen af et enkelt team.