Det är inte lätt att på ett tillförlitligt sätt omforma befintliga affärs- och IT-miljöer till moderna, konkurrenskraftiga och integrerade arkitekturer. Komplexiteten i affärs- och IT-miljöer har ökat nästan okontrollerat i fyrtio år, vilket har gjort förändringar allt dyrare. Detta beror på följande:
- Miljöns komplexitet uttrycks ofta i äldre kod. Brist på kompetens för äldre kod leder till ökade underhålls- och integrationskostnader.
- Existerande komplexa miljöer måste omarbetas i faser som är operativt meningsfulla för den tillhörande affärsverksamheten. Dessa faser leder ofta till omfattande och riskfyllda byten av system, eftersom okunskap om den befintliga komplexiteten innebär att potentiella stegvisa förändringar är för svåra att förstå och konstruera.
- Accelererade utvecklingsmetoder har lämnat företagen med moderna äldre system. Komplexa Java- och .NET-applikationer har många av samma problem som äldre COBOL-applikationer.
Det resulterar i att en allt större del av arbetet med att utveckla nya affärsmöjligheter går åt till att förstå och integrera med det befintliga komplexa system- och affärslandskapet snarare än att leverera värde. Det har observerats att upp till 75 % av den totala projektinsatsen nu går åt till programvaruintegration och migrering snarare än till ny funktionalitet.
Industrin som helhet har dålig framgång när det gäller att leverera sådana storskaliga förändringar för sina kunder. I CHAOS-undersökningen från Standish Group har man kunnat se en allmän förbättring av IT-projektens framgång under de senaste tjugo åren, men även 2006 misslyckades stora IT-projekt oftare än de lyckades. Att genomföra förändringar i sådana miljöer har många paralleller med byggbranschens problem när det gäller att sanera industriområden eller förorenade områden. De är fulla av faror och oväntade komplexiteter och tenderar att vara riskabla och dyra att sanera. Den ackumulerade komplexiteten i IT-miljöer har gjort dem till ”Brownfield”-områden.
Det är inte komplexiteten i den nya funktionen eller nya systemegenskaper som är orsaken till att stora projekt misslyckas – det är vår förståelse och kommunikation av det övergripande kravet (som identifierats i The Mythical Man Month). För att lyckas måste kraven innehålla en exakt och grundlig förståelse av begränsningarna i den befintliga verksamheten och IT. De nuvarande verktygen och metoderna för ”grönt fält” använder tidiga, informella och ofta oprecisa abstraktioner som i princip ignorerar denna komplexitet. Tidiga, dåligt informerade abstraktioner är vanligtvis felaktiga och upptäcks ofta sent i konstruktionen, vilket leder till förseningar, dyrt omarbete och till och med misslyckad utveckling. Ett Brownfield-orienterat tillvägagångssätt omfattar befintlig komplexitet och används för att på ett tillförlitligt sätt påskynda den övergripande lösningstekniska processen, inklusive att möjliggöra stegvisa, inkrementella förändringar där det är möjligt.
Brownfield tar OMG:s standardmodell/mönsterspecifika tillvägagångssätt och vänder det på huvudet. I stället för att använda det konventionella tillvägagångssättet där man börjar med en konceptuell modell och sedan kör ner till plattformsspecifika modeller och kodgenerering, börjar Brownfield med att samla in kod och andra befintliga artefakter och använder mönster för att formellt abstrahera uppåt mot arkitektur- och affärsnivåerna.
Standard Greenfield-tekniker används sedan i kombination för att definiera det föredragna affärsmålet. Denna ”meet in the middle”-teknik är bekant från andra utvecklingsmetoder, men den omfattande användningen av formell abstraktion och användningen av mönster för både upptäckt och generering är ny.
Den underliggande konceptuella arkitekturen för alla Brownfield-verktyg är känd som VITA. VITA står för Views, Inventory, Transformation and Artifacts. I en VITA-arkitektur kan problemdefinitionen av målområdet upprätthållas som separata (men relaterade) inhemska ”huvuddelar” av kunskap som kallas Views. Den viktigaste fördelen med en View är att den kan baseras på i stort sett vilket formellt verktyg som helst. Brownfield påtvingar inte ett enda verktyg eller språk på ett problemområde – en central princip är att huvuddelarna fortsätter att underhållas i sina ursprungliga former och verktyg.
Inhemska Views förs sedan samman och länkas till en enda inventering. Inventeringen används sedan tillsammans med en rad omvandlingsfunktioner för att producera de artefakter som lösningen behöver.
Vyer kan för närvarande importeras från en mängd olika källor, t.ex. UML, XML-källor, DDL, kalkylblad osv. Verktyget Analysis and Renovation Catalyst från IBM har tagit denna möjlighet ännu längre genom att använda formella grammatiker och abstrakta syntaxträd för att göra det möjligt att analysera nästan vilket program som helst och omvandla det till en vy för att inkludera det i inventariet.
Den snabba cykliska karaktären hos cykeln för upptäckt, omarbetning, generering och testning som används i detta tillvägagångssätt innebär att lösningarna kan förfinas iterativt i termer av deras logiska och fysiska definitioner allteftersom fler av begränsningarna blir kända och lösningsarkitekturen förfinas.
Iterativ Brownfield-utveckling kan möjliggöra en gradvis förfining av logiska och fysiska arkitekturer och inkrementell testning för hela tillvägagångssättet, vilket resulterar i snabbare utveckling, förbättrad lösningskvalitet och billigare borttagning av defekter. Brownfield kan också användas för att generera lösningsdokumentation, vilket säkerställer att den alltid är aktuell och konsekvent mellan olika synvinklar.
Inventariet som skapas genom Brownfield-bearbetning kan vara mycket komplext, eftersom det är ett sammankopplat multidimensionellt semantiskt nätverk. Kunskapsnivån i inventeringen kan vara mycket finkornig, mycket detaljerad och sammanlänkad. Sådana saker är dock svåra att förstå och kan utgöra hinder för kommunikation. Brownfield löser detta problem genom att abstrahera begrepp via en hantverkares bästa gissning, genom att använda kända mönster i sina inventeringar för att extrahera och härleda relationer på högre nivå.
Formella abstraktioner gör det möjligt att översätta inventeringens komplexitet till enklare, men i sig korrekta, representationer för att underlätta för dem som behöver förstå problemområdet. Dessa abstrakta inventeringsmodeller kan användas för att automatiskt återge arkitekturrepresentationer i flera lager i verktyg som Second Life.
Dessa visualiseringar gör det möjligt att dela och uppleva komplex information i realtid för flera personer från hela världen. Detta ökar både förståelsen och känslan av ett gemensamt team.