, Sundblad & Sundblad ADB-Arkitektur, Uppsala Vi skriver nu januari 2005 och det är dags för ett nytt tema för Microsofts arkitektwebb. Under kvartalet januari mars 2005 är det arkitektur och arkitektens roll som gäller, och det här är den första av tre artiklar under detta tema. Avsikten med den här artikeln är att ge en översikt över ämnet mjukvaruarkitektur; februariartikeln kommer att handla om olika arkitektroller och arkitektens ansvar, medan marsartikeln kommer att diskutera mjukvaruarkitektens verktyg och arbetssätt. En jämförelse med traditionell arkitektur Som vi framhåller i kursen Arkitektur och arkitektens roll, som ingår i vårt utbildnings- och certifieringsprogram för lösningsarkitekter som arbetar i.net-miljö, har vi mycket att vinna på att se hur arkitektur och arkitektyrket definieras i mera traditionella sammanhang. Idén om mjukvaruarkitektur har ju inte särskilt många år på nacken, särskilt om man jämför med traditionell arkitektur som var ett viktigt ämnesområde långt före Kristi födelse, och det är först på senare år som begreppen arkitektur och arkitekt verkligen har blommat ut i IT-sammanhang. Brooks och arkitektur 1975 skrev Frederick P. Brooks, Jr. The Mythical Man-Month I. Brooks är känd som the father of the IBM System/360. Han var projektledare vid utvecklingen av detta välkända stordatorsystem. Han var också under designfasen ansvarig för utvecklingen av operativsystemet till IBM System/360. Bokens titel kommer sig av Brooks syn på begrepp som manår och manmånad. Brooks menar att det finns en vanföreställning omkring dessa begrepp, nämligen att ett projekts framåtskridande kan samvariera med antalet personer och antalet tidsenheter som sätts in i projektet. Kostnaden för projektet samvarierar tämligen väl med antalet manmånader eller manår menar Brooks; projektets framåtskridande gör det inte. Utifrån Brooks erfarenheter från 360-projektet och andra projekt stiftade han det han kallar för Brooks s Law. Han medger att han förenklar problemställningen på ett närmast skamligt sätt men att lagen icke dess mindre har giltighet. Så här ser Brooks s Law ut: Adding manpower to a late software project makes it later. Brooks s Law är emellertid inte skälet till att jag tar upp Brooks här. Det är i stället att han så tidigt som 1975 talar om arkitektur av mjukvarusystem. Han gör det i ett avsnitt om konceptuell integritet, där han jämför arkitektur i de flesta europeiska katedraler med arkitektur i katedralen i Reims. I de flesta fall, menar Brooks, finns det skillnader i arkitekturell stil mellan delar som har byggts av olika generationer av byggare. Senare byggherrar frestats att förbättra stilen från tidigare, dels för att återspegla skillnader i mode och dels för att sätta sin egen prägel på de tillkommande delarna. Katedralen i Reims, menar Brooks, är det lysande undantaget. Åtta generationer av byggherrar har nekat sig tillfredsställelsen av att sätta sin egen prägel på sin del av verket och i stället böjt sig för de ursprungliga arkitektoniska idéerna. Den glädje som vederfars åskådaren kommer i lika hög grad från utformningens integritet som från några enskilda förträffligheter, menar Brooks. I en kommentar om mjukvarusystem säger Brooks att konceptuell integritet enligt hans uppgift är den allra viktigaste faktorn i systemdesign. Det är bättre, säger han, att ett system återspeglar en enda uppsättning designidéer och saknar vissa funktioner och förbättringar än att det innehåller ett antal goda men oberoende och ej samordnade idéer. Brooks menar att det är svårt att åstadkomma konceptuell integritet i större system som kräver att många är inblandade i dess utformning och utveckling, men att han har identifierat två sätt att ändå göra det: Det första sättet är att noggrant fördela utvecklingsarbetet med en del för arkitektur och en annan separat del för implementering. Systemet skall ha en enda arkitekt, eller högst ett fåtal arkitekter som utformar systemet i nära samverkan med varandra.
Det andra sättet är att strukturera de lag eller grupper som skall implementera systemet på ett särskilt sätt som ligger utanför den här artikelns intresseområde. Brooks s definition av arkitektur Brooks s definition av arkitektur är intressant eftersom den ligger nära den traditionella synen på arkitektur. Så här säger han ordagrant: By the architecture of a system, I mean the complete and detailed specification of the user interface. For a computer this is the programming manual. For a compiler it is the language manual. For a control program it is the manuals for the language or languages used to invoke its functions. For the entire system it is the union of the manuals the user must consult to do his entire job. Det är intressant att ta del av Brooks s definition av arkitektur, eftersom den så helt fokuserar på systemets exteriör. Han påpekar också att en mjukvaruarkitekt, precis som en byggnadsarkitekt, är användarens representant. Han är inte säljare och inte heller tillverkare. Han har i stället ett odelat ansvar för att applicera sitt professionella kunnande och tillämplig teknologi i användarens intresse. Arkitekten är helt enkelt användarens och kundens agent. Med referens till sin samarbetspartner i 360-projektet, G.A. Blaauw, exemplifierar Brooks med arkitekturen för en klocka. Klockans arkitektur består av (eller bestod åtminstone då av) beståndsdelar som urtavlan, två eller flera visare och en uppdragningsmekanism. När ett barn har lärt sig förstå denna arkitektur kan det läsa av tiden oavsett om det sker från ett armbandsur eller en kyrkklocka trots att de båda implementerar denna arkitektur på helt olika sätt. Poängen är, menar Brooks, att ett systems arkitektur beskriver systemets utsida; implementationen beskriver dess insida. Vitruvius: Ten Books on Architecture Om Brooks var en pionjär inom mjukvaruarkitektur borde Marcus Vitruvius Pollio kunna betraktas som en pionjär inom traditionell arkitektur. Han levde i Rom under tiden strax före Kristi födelse och skrev under perioden omkring 30 20 år för Kristus tio böcker om arkitektur (De Architectura). Dessa böcker finns översatta till engelska att köpa hos till exempel Amazon. De är samlade i en volym och har titeln Ten Books on Architecture II. Var och en av de tio böckerna är också försedd med nutida kommentarer. Det är visserligen sant att vi haft betydande arkitekter långt före Vitruvius, men det lär vara så att ingen före honom har skrivit om arkitektur och fått sina alster bevarade ända in i våra dagar. Det är inte minst därför det är relevant att tala om Vitruvius som pionjär. Han lär ha inlett sin arkitektbana omkring 50 före Kristus, det vill säga ungefär vid den tid då inbördeskriget mellan Ceasar och Pompejus bröt ut. I inledningen var hans karriär därför militärt inriktad, och han talar i sina böcker om sitt ansvar för utformningen av de katapulter som användes vid belägring av städer för att bryta ner försvaret. Han anses emellertid också vara arkitekt för basilikan i Fano som byggdes under Ceasar och Augustus. Det sägs att Vitruvius idéer om arkitektur påverkar arkitektyrket ända in i vår tid, direkt eller indirekt, så det kan vara intressant att ta del av hans budskap. Vitruvius hävdade att arkitektur utgår från tre principer: Principen om utilitas handlar om att den struktur vi tänker bygga skall vara användbar för sitt syfte. För att arkitekten skall kunna åstadkomma det måste han skaffa sig ingående kunskap om den tänkta strukturens syfte. Det är användarens/beställarens ansvar att syftet blir ordentligt beskrivet, men i de flesta fall krävs att arkitekten ställer sin yrkeskunskap till användarens/beställarens förfogande för att syftet skall bli så väl beskrivet som krävs. Användaren/beställaren är sällan professionella kravanalytiker eller kravställare; arkitekten måste vara det. Arkitekten måste alltså först skaffa sig ingående kunskap om det eller de problem som skall lösas för att sedan åstadkomma en arkitektur med god potential att lösa dem. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 2
Utilitas handlar också om den tänkta strukturens eller produktens flexibilitet. För att den skall bli användbar över tiden måste den kunna anpassas till nya användares behov och nya användningssituationer. Även detta är naturligtvis arkitektens ansvar. Principen om venustas säger att den struktur vi tänker bygga skall vara behaglig att använda eller vistas i. Venustas är helt och hållet arkitektens ansvar. I traditionell arkitektur är det här arkitektens huvudansvar ligger; i mjukvaruarkitektur får man nog säga att venustas hittills spelat en undanskymd roll. Ofta är det problematiskt att det är så användaren som borde sitta i högsätet gör det inte alltid. Alan Cooper har skrivit en del om det här i About Face 2.0 The Essentials of Interaction Design III och The Inmates Are Running the Asylum IV. Cooper är känd som mannen bakom Microsoft Visual Basic. Han hade en formulärhanterare för Windows kallad Ruby. Han sålde Ruby till Microsoft och hjälpte Microsoft att sammanföra Ruby och Windows. Resultatet var Visual Basic 1.0, och Ruby har fortsatt varit Visual Basic s formulärhanterare ända fram till och med Visual Basic 6.0. Det är först nu med.net som Microsoft lämnat Alan Cooper s Ruby bakom sig. Coopers hela professionella verksamhet kretsar sedan tiden med Visual Basic 1.0 kring det han kallar Interaction Design. Hans grundinställning är att all mjukvara i princip är användarfientlig ( user hostile ), och han har många recept för att förbättra situationen. Den som i likhet med Vitruvius och Brooks menar att arkitekten har ett stort ansvar för användbarhet och användarens välbefinnande i relation till den tänkta produkten har mycket att hämta hos Cooper. About Face vänder sig främst till dig i din roll som utvecklare medan The Inmates Are Running the Asylum främst vänder sig till beslutsfattare. Den schweiziske arkitekten Le Corbusier levde mellan 1887 och 1965. Enligt Marvin Trachtenberg, författare till Architecture: From Pre-History to Postmodernism V, uttryckte sig Le Corbusier så här om arkitektur (min översättning från författarens engelska översättning av Le Corbusiers uttalande): Du använder sten, trä och betong, och med dessa material bygger du hus och palats. Detta är konstruktion. Skarpsinne och genialitet sätts i arbete. Men plötsligt rör du vid mitt hjärta, du får mig att må bra, jag är lycklig och jag säger Detta är vackert. Då är det arkitektur. Principen om firmitas innebär att den struktur som byggs skall vara stark, att den skall vara uthållig och varaktig nog att stå emot tidens tand och flitig användning över år och årtionden. Det här är traditionellt byggarens ansvar, och så är det också i samband med mjukvaruutveckling, men jämfört med traditionell arkitektur ligger nog mjukvaruarkitektens intressen mer på firmitas än det gör i traditionell arkitektur. Förmodligen beror detta på att vi mjukvaruarkitekter så gott som uteslutande kommer från och har vår huvudsakliga erfarenhet från byggsidan. Om arkitektur, arkitekter och design Det är uppenbart att arkitektur handlar om design, och främst då om övergripande design. Grady Booch har i något sammanhang sagt att all arkitektur är design men all design är inte arkitektur. Det här uttalandet är emellertid förledande enkelt, och det vet Grady Booch. Arkitektur är mer än design, eftersom arkitekten måste åstadkomma en arkitektur eller utformning som löser väl kända problem. Utan problem finns det inget behov av arkitektur, och arkitekten måste ha ingående kännedom om dessa problem om han skall kunna lösa dem på ett för användaren och beställaren tillfredsställande sätt. Arkitektur måste alltså föregås av ett gediget analysarbete, och arkitekten måste vara beredd att ta på sig ett stort ansvar för detta analysarbete. Vad ingår i ett systems arkitektur? I boken Evaluating Software Architectures VI räknar Paul Clements m.fl. upp tre skäl till att mjukvaruarkitektur har blivit så betydelsefull för stora, komplexa mjukvaruintensiva system: 1. Författarna positionerar arkitektur som ett kommunikationsmedel bland ett tänkt systems intressenter. (Det begrepp författarna använder är naturligtvis stakeholders, men jag har valt att använda det svenska intressenter som en motsvarighet. Jag tycker egentligen att ordet intressenter är litet svagare än stakeholders eftersom det svenska ordet kan innefatta någon som bara har ett svalt intresse av området. Den Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 3
här aktuella betydelsen är emellertid att intressenten har en insats ( stake ) i det tänkta systemet och att man är aktivt intresserad av att skydda denna insats. 2. De menar också att ett systems arkitektur är en yttring av de tidigaste designbeslut som rör systemet. När ett arkitekturförslag presenteras är det första chansen att analysera de prioriteringar som har gjorts mellan konkurrerande krav och önskemål, och ett systems arkitektur är enligt författarna den artefakt som har den största inverkan av alla på systemets kvalitet. De säger att kompromisser mellan prestanda och säkerhet, mellan underhållsvänlighet och pålitlighet, och mellan tidiga och framtida utvecklingskostnader tydliggörs i en arkitekturbeskrivning. 3. De säger också att ett systems arkitektur är en återanvändbar och överföringsbar abstraktion av systemet. Jämfört med ett systems kodmassa är dess arkitektur en tämligen liten och överblickbar modell av systemet som visar hur dess viktigaste komponenter samverkar med varandra. En sådan modell kan överföras till andra system som skall tillfredsställa liknande krav och kan på sikt stimulera till storskalig återanvändning och till produktlinjer. Vår kommentar är att detta skäl förmodligen har extra stor giltighet i en serviceorienterad arkitektur där speciellt entitetstjänster, men även aktivitetstjänster, helt enkelt är till för storskalig återanvändning. Samma bok försöker att besvara frågan om vad arkitektur egentligen är, eller kanske snarare vilka delar av en design som är arkitektur och vilka som inte är det. I våra kurser för blivande certifierade.net-arkitekter kommer relativt ofta frågan upp om var gränsen går mellan arkitektur och övergripande design. Med andra ord: hur långt skall arkitekten gå innan han eller hon överlämnar sitt verk till en designer som inte är arkitekt? Vi brukar alltid besvara den frågan med referens till den här boken som räknar upp några användbara principer för avgränsning och arkitektur och annan design. Jag tänker inte räkna upp alla dessa principer, och jag tänker inte gå in lika djupt på dem som boken gör. Vill du ha mera bredd och djup på den här frågan rekommenderar jag att du köper boken den ger dig bra värde i utbyte för de pengar och den tid du lägger ner på den. Här kommer emellertid vårt urval (för den här artikeln) av dessa principer: Extern synlighet. För att något skall räknas som arkitekturellt måste det vara en komponent, en relation mellan komponenter eller en egenskap i en sådan komponent eller relation som behöver synas externt. Extern synlighet skall möjliggöra resonemang om systemets potential att tillgodose krav som ställts på det, eller om nedbrytning av systemet i mindre oberoende delar som kan implementeras var för sig. Hög abstraktionsnivå. Den information som framgår av en arkitekturbeskrivning är den mest abstrakta men ändå meningsfulla beskrivningen av systemet. Dessa båda egenskaper, att både vara rejält abstrakt men ändå meningsfull kan ibland synas motsägelsefulla. Ibland måste du för att beskrivningen skall bli meningsfull gå ned på en detaljnivå som andra bedömer som för låg, men om det behövs så behövs det, och i så fall ingår denna detaljerade beskrivning absolut i systemets arkitektur. Som framgår av nästa punkt är det arkitekten som avgör var gränsen mellan arkitektur och mer detaljerad design går. Arkitekten bestämmer gränsen. En av uppgifterna för ett systems arkitektur är att överbrygga klyftan mellan de krav som ställs på systemet och systemets detaljerade design och implementering. Det här kan också uttryckas så att systemets arkitektur lägger band på oönskad kreativitet. Om du som arkitekt anser att du för att säkerställa ett verksamhets- eller användarkrav måste beskriva någon aspekt på systemet på ett detaljerat sätt, då skall du också göra det. Då ingår denna detaljerade beskrivning i systemets arkitektur. Du som arkitekt har det övergripande ansvaret för att alla krav på systemet blir tillgodosedda så väl som möjligt, och eftersom det är du som sitter på kravbilden kan ingen vara en bättre domare än du över vad som skall ingå i systemets arkitektur och vad som skall vara detaljerad design. Det du beskriver ingår i systemets arkitektur det du utelämnar gör det inte. Var börjar arkitektens ansvar? Var börjar då arkitektens ansvar? Svaret är naturligtvis som alltid att det beror på. Bland annat beror det på vilken arkitektroll frågan avser. Olika arkitektroller är ett av föremålen för nästa månads artikel; för den här artikeln nöjer vi oss med att diskutera den arkitektroll både vi och Microsoft valt att kalla lösningsarkitekt. Denna roll har vi tidigare kallat för applikationsarkitekt, men i takt med att vi (långsamt men ganska säkert) rör oss i riktning mot en service- Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 4
orienterad paradigm blir det mer relevant att i stället tala om lösningsarkitekter. Vi stödjer oss här på potentater som Don Box och Pat Helland som båda menar att det är bäst att låta applikationsbegreppet stå för samma sak som det alltid har stått för, nämligen en tämligen sammanhållen programenhet som är till för att lösa ett specifikt problem. I en serviceorienterad miljö kommer motsvarande lösning att bestå av ett antal till varandra löst kopplade tjänster som samverkar till att åstadkomma lösningen. Många tycker det här är hårklyveri, men ju mer distinkta vi kan vara i våra ordval, desto lättare kommer det bli att kommunicera med precision. Frågan gäller alltså var lösningsarkitektens ansvar börjar. Många skulle säkert besvara den frågan med att lösningsarkitektens ansvar börjar när det finns en tydlig kravbild som skall omsättas i en övergripande arkitektur. Vi menar att den börjar tidigare, redan vid insamlingen av denna kravbild. Arkitekten måste ta ett ansvar för att den kravbild han eller hon skall utgå från är tillräckligt omfattande och tillräckligt tydlig. Om så inte är fallet kan inte arkitekten åstadkomma en relevant arkitektur; den kommer att sakna nödvändiga sammanhang. I en idealisk värld kommer beställaren av en lösning att kunna redogöra för sina krav på ett så bra sätt att arkitekten kan utgå från dem. I verkligheten är det ytterst sällan så; arkitekten måste ställa sin professionella kompetens i beställarens tjänst och hjälpa beställaren både att formulera och strukturera sina krav. Så är det för den traditionelle arkitekten, som i de allra flesta fall måste hjälpa husköparen att formulera och strukturera sina krav och önskemål, och så måste det också vara för en lösningsarkitekt inom IT. IEEE 1471-2000 Det finns en formell standard för arkitekturbeskrivningar inom IT. Den heter IEEE Std 1471-2000, och den utgör en rekommendation för utformandet av arkitekturell beskrivning av mjukvaruintensiva system. Den omfattar alltså inte på något sätt ett systems arkitektur endast beskrivningen av denna arkitektur. Som de flesta av denna artikels läsare säkert känner till är IEEE en standardiseringskommission med stort inflytande inom området elektricitet och elektronik. Det kan ändå vara intressant att i figuren till höger, som är ett klipp ur the About Box från IEEE s hemsida se omfattningen av denna kommissions åtaganden. Det formella namnet på denna standard är IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, och du hittar en formell beskrivning av den på följande adress: http://www.win.tue.nl/~mchaudro/sa2004/ieee1471.pdf Det finns åtminstone tre intressanta aspekter på denna standard: 1. Den kan hjälpa oss som lösningsarkitekter att strukturera innehållet i våra arkitekturbeskrivningar. Det måste vara av stort värde att formalisera sådana beskrivningar så att strukturen på flera olika arkitekturbeskrivningar påminner om varandra. Det borde också underlätta för konsumenter av sådana beskrivningar att de liknar varandra. 2. En sådan standard som IEEE Std 1471-2000 borde kunna hjälpa vårt yrke till en högre grad av mognad. Vi ligger långt efter traditionell arkitektur när det gäller former och innehåll för vårt arbete, vilket inte minst manifesteras av de många uppfattningar som finns om vad arkitektur och arkitekter är i vår bransch. 3. Det borde finnas ett marknadsvärde i att kunna säga att de arkitekturbeskrivningar jag/vi framställer är förenliga med den enda formella standard som finns på området. Av dessa skäl har vi gjort IEEE Std 1471-2000 till en av tre grundpelare för vår verksamhet med utbildning och certifiering av.net-arkitekter. En arkitekt som gått igenom hela vårt utbildningsprogram för arkitekter och som är certifierad av oss kan garanterat framställa arkitekturbeskrivningar som är förenliga med IEEE Std 1471-2000. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 5
Konceptuell modell av en arkitekturbeskrivning I beskrivningen av IEEE Std 1471-2000 ingår en konceptuell modell av en arkitekturbeskrivning. Denna modell se nedan beskriver vad en sådan bör innehålla för att vara förenlig med IEEE Std 1471-2000. Observera att en lösningsarkitekt måste anses vara ansvarig för ett systems arkitekturbeskrivning, även om arkitekten inte kan svara för varje del av beskrivningens innehåll. Man kan göra några intressanta observationer i denna modell: Varje system har ett eller flera distinkta uppdrag ( mission ), och dessa uppdrag måste ingå i systemets arkitekturbeskrivning för att den skall vara förenlig med IEEE Std 1471-2000. Det här är ett bra exempel på beskrivningsdelar där arkitekten är ansvarig för att de kommer in men knappast för innehållet. Ett systems uppdrag måste definieras av verksamhetsansvariga. Varje system existerar i en miljö, och denna miljö påverkar systemet. Även detta skall ingå i en arkitekturbeskrivning som är förenlig med IEEE Std 1471-2000. I systemets miljö ingår andra system som påverkar eller påverkas av systemet. Lägg märke till att ordet system inte inskränker sig till något som har med IT att göra utan med hela verksamhetssystem och delar av sådana. Det är alltså viktigt att arkitektoniskt kunna beskriva vilka verksamhetsdelar ett tänkt system kommer att påverka och vilka det kommer att påverkas av. I miljön ingår också de användare som skall utnyttja systemet. Användar- och användningskrav ingår alltså i den miljö som skall ingå i arkitekturbeskrivningen. Återigen ansvarar lösningsarkitekten för att de blir väl och tillräckligt beskrivna utan att därför nödvändigtvis kunna ta ansvar för innehållet i dessa krav. Innehållet måste komma från användare och områdesexperter; arkitektens ansvar är att få fram dem, ofta att dokumentera dem och alltid att inordna dem i sitt arkitektoniska sammanhang. Varje system har en arkitektur, känd eller okänd. Denna arkitektur är beskriven i en arkitekturbeskrivning (Architectural Description, ofta kallad AD). Varje system har en eller flera intressenter (stakeholders) som var och en har ett antal intressen (concerns) i förhållande till det tänkta systemet. Arkitekturbeskrivningens främsta uppgift är att tillgodose dessa intressenters intressen. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 6
Jag har redan nämnt svagheten i begreppet intressent som motsvarighet till originalets stakeholder. På liknande sätt är det svenska begreppet intresse en alltför oprecis översättning av originalets concern. Tittar man i Webster s Dictionary ser man att begreppet concern förklaras på följande sätt: an uneasy state of blended interest, uncertainty, and apprehension. När du tänker i termer av intressenters intressen i ett tänkt system måste du alltså förstå att dessa intressen har en hög angelägenhetsgrad och innehåller ett tydligt element av oro: kommer det här verkligen att bli bra för mig?. Det kan vara av intresse att också se hur IEEE 1471-2000 ser på begreppet system stakeholder. Så här förklaras det i dokumentationen: An individual, team or organization (or classes thereof) with interests in, or concerns relative to, a system. Det jag egentligen vill framhålla här är att du förlorar i precision när du använder de svenska begreppen intressent och intressen, och att det är bra att vara medveten om det. Själva föredrar vi på Sundblad & Sundblad att undvika denna förlust genom att använda originaluttrycken stakeholder och concerns. En arkitekturbeskrivning består av ett antal vyer, där varje vy består av en uppsättning modeller. En modell är en abstraktion av något verkligt och kan mycket väl bestå av en löpande text som beskriver det verkliga. Den kan också vara grafisk, som till exempel en datamodell eller en klassmodell uprättad i UML. Varje vy (eller view) är baserad på en så kallad viewpoint, och varje viewpoint är till för att adressera en viss uppsättning stakeholders och att täcka en viss uppsättning stakeholder concerns. Till det ändamålet specificerar varje viewpoint ett antal modeller. Vi vet från vår utbildningsverksamhet att det här med views och viewpoints är litet svårt att ta till sig, förmodligen för att de av IEEE valda begreppen inte riktigt stämmer överens med vårt eget svenska idiom. Jag skall ändå försöka att på kort utrymme klargöra relationerna mellan de båda och användningen av dem. Av erfarenhet vet jag dock att en sådan förklaring blir ännu mer svårsmält om man översätter begreppen till utsiktspunkt och vy så jag gör som i fallen med stakeholder och concern använder mig av svengelska. Hoppas du ursäktar! En viewpoint är en mall för views. Den specificerar vilka stakeholders som skall adresseras och vilka av deras concerns som skall täckas. Den specificerar också vilka modelleringsspråk (där engelska eller svenska är fullt godkända alternativ) för att beskriva någon aspekt av systemet, systemets omgivning eller systemets uppdrag. Views är implementationer av viewpoints. Du kan alltså ha ett förråd av viewpoints, där ingen av dem hanterar något system utan endast är mallar för views. En view beskriver alltid en aspekt på ett enda system och är alltid baserat på en viewpoint. Detta är vad IEEE 1471-2000 föreskriver om viewpoints och views. IEEE säger ingenting om vilka viewpoints du bör ha det avgör du helt och hållet själv. Figuren ovan till höger är en standard-viewpoint hämtad ur vårt utbildningsmaterial. Den är något framåtblickande i det att den specificerar ett verktyg och därmed ett modelleringsspråk som ännu inte finns (Microsoft Application Connection Designer). Vi räknar dock med att den kommer att ändras ytterligare något om och i så fall när Microsoft presenterar sitt eget språk och tillhörande verktyg för modellering och hantering av Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 7
verksamhetsmodeller. Fram till dess väljer vi bland många tillgängliga alternativ IDEF0, som är en formell standard för modellering av verksamhetsfunktioner och verksamhetsprocesser. En process i processen Arkitekturprocessen är en del av utvecklingsprocessen. Vi får ofta frågan om hur den arkitekturprocess vi förordar stämmer överens med förekommande utvecklingsprocesser som Rational Unified Process (RUP) eller Microsoft Solution Framework (MSF). Vårt svar är alltid att av oss föreslagen arkitekturprocess är oberoende av den utvecklingsprocess företaget i fråga redan använder. Det innebär emellertid inte att man bara utan vidare kan stoppa in vår arkitekturprocess i utvecklingsprocessen. Det skulle säkert gå, men det skulle vara ineffektivt. Man måste först se över vilken redundans som skulle uppstå i de olika artefakter som arkitekturprocessen respektive utvecklingsprocessen föreskriver och sedan förändra någon av dem för att undanröja denna redundans. Man kan emellertid med säkerhet påstå att i varje fall RUP och MSF har brister i sitt sätt att se på arkitektur och arkitektens ansvarsområde. En satsning på arkitekturdriven systemutveckling kräver för alla eller i varje fall de flesta ingrepp i utvecklingsprocessen oavsett hur arkitekturprocessen ser ut. Ett arkitektoniskt ramverk Ett arkitektoniskt ramverk kan vara ett bra sätt att styra arkitekturprocessen. Fadern till idén om sådana ramverk är utan tvekan John Zachman. Han arbetade på 70-talet för IBM med fokus på planering och strategi för utveckling av informationssystem och hjälpte bland annat Boeing att sätta upp planer för deras utveckling av informationssystem. Under det arbetet blev Zachman imponerad av företagets förmåga att tillverka relevanta, komplexa produkter, föra ut dem på en dynamisk marknad, och att underhålla och förändra dem när de väl var byggda. De arbetar sig steg för steg fram från en övergripande affärsmässig beskrivning av en tänkt produkt till en detaljerad beskrivning av de komponenter som behövs för att sätta ihop produkten. De köper en del komponenter och tillverkar andra. De monterar dem sedan till ett flygplan. De provflyger planet, och det flyger! Det är vi inte i närheten av att åstadkomma när vi bygger informationssystem. Det här citatet, hämtat ur minnet, var förmodligen inte en ordagrann översättning av vad Zachman har sagt, men det innefattar ganska väl det han ändå sade. Zachman har också sagt att han lärt sig mycket av flygplansoch byggnadsindustriernas förmåga att åstadkomma sådana relevanta och komplexa produkter och av de processer de använder för att göra det. Zachmans ramverk var från början tänkt för utveckling av enstaka produkter (läs applikationer), för det var det rådande perspektivet vid tiden för ramverkets tillkomst. Han vidareutvecklade det så småningom, och det uttalade syftet blev mer att bygga det elektroniska företaget (the Electronic Enterprise) än applikationer. Därför är det inte vare sig märkligt eller olämpligt att olika initiativ tagits för att ta fram alternativa arkitektoniska ramverk, som ofta är derivat av Zachmans kompletta modell. Microsoft har tagit fram ett sådant, kallat BAIT (för Business, Application, Information och Technology). Avsikten med BAIT var emellertid aldrig att bidra till en formell arkitekturprocess, endast att redovisa fack i vilka man kan stoppa in arkitektoniska artefakter. Det ser vi som en allvarlig brist, och därför har vi utvecklat vårt eget derivat se ovan till höger som påminner både om BAIT och om Zachman men som också skiljer sig från båda. Det är emellertid mera likt Zachman än BAIT, vilket vi inte ser som en nackdel. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 8
Figuren visar också att vårt ramverk ger vägledning när det gäller vilka viewpoints man bör hålla sig med och utgå från. En av arkitektens uppgifter vid inledningen av en utvecklingsprocess bör vara att välja viewpoints till sina arkitekturbeskrivningar, och där kan Sundblad & Sundblads ramverk vara till god hjälp. Urfadern till alla arkitektoniska ramverk är emellertid utan tvekan Zachmans ramverk. Vi har hört tydliga signaler om att Microsoft har tagit fram ett nytt ramverk som är mera tydligt baserat på Zachmans ramverk än deras BAIT-ramverk är, och att Microsoft kommer att föra fram detta nya ramverk framför BAIT. Vi tycker det är bra, särskilt som det nya ramverket mer liknar vårt än det liknar BAIT. Vi säger inte det för att antyda att Microsoft skulle ha använt vårt som en utgångspunkt för sitt nya, för så är det inte alls. Men det nya ramverket är mer likt Zachmans än deras tidigare, och det är vårt också. Det innebär att en eventuell anpassning från vårt ramverk till Microsofts nya inte är särskilt problematisk. Vi räknar med att så småningom göra en sådan anpassning, för det finns ingen egentlig poäng i att vara avvikande. Det fanns ett värde i att avvika från BAIT eftersom BAIT inte var till hjälp i arkitekturprocessen; med det nya kommer denna anledning inte att finnas kvar. Ett arkitektoniskt ramverk bör också hjälpa till med urval av beskrivningsartefakter. Figuren ovan till höger också hämtad ur vårt utbildningsmaterial, ger exempel på innehåll i var och en av de celler (läs viewpoints) som är relevanta för arkitekturbeskrivningar. Se dem just som exempel! Varje organisation måste sätta upp sin egen modell för vilka artefakter organisationen vill använda för att tillgodose olika stakeholders behov. Fördelning av utvecklingstid Jag vill gärna avsluta den här artikeln med ännu något från Brooks. I ett kapitel som i likhet med boken heter The Mythical Man-Month har han ett avsnitt som handlar om optimism. Alla programmerare är optimister, säger han. Visserligen är vår industri nu ganska precis dubbelt så gammal som den var 1975 då Brooks skrev boken, men den är fortfarande mycket ung som industri. Brooks fortsätter: Datorer är en ung företeelse, programmerare är ännu yngre, och unga är alltid optimister. Han säger också att vi som mänskliga tillverkare av saker och ting inte blir uppmärksammade på brister och motsägelser i våra tankar och idéer förrän i samband med att de implementeras. Som de optimister vi tenderar att vara tror vi alltid att allting skall gå bra, men om vi inte tänkt igenom dem tillräckligt väl innan vi började implementera dem kommer de att visa sig felaktiga. Då är vår inneboende optimism ogrundad, menar Brooks. För att undvika ogrundad optimism, som alltid spräcker alla tidsuppskattningar när den först visar sig vara ogrundad, använder Brooks följande tumregel när han tidsplanerar ett utvecklingsprojekt: En tredjedel av tillgänglig tid och tillgängliga resurser allokerar Brooks till det han kallar planering. I det ingår analys och dokumentation av krav samt övergripande arkitektur och design. Brooks menar att även om en så stor andel av projektets resurser går till planering räcker det inte om man måste inkludera undersökning av nya teknologier. Endast en sjättedel sätter Brooks av till kodning. En fjärdedel sätter han av till komponenttester och till tidig systemtest. Ytterligare en fjärdedel sätts av till systemtest med alla komponenter inblandade. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 9
Kanske allra mest intressant är det att Brooks sätter av halva den tillgängliga produktionstiden till test och att endast en sjättedel av tiden sätts av till kodning. Det är också intressant att han sätter av dubbelt så stora resurser till planering som till kodning. En liten tabell illustrerar förhållandet mellan de olika delarna ännu bättre. Jag har tänkt mig ett projekt om 36 manmånader, eftersom denna siffra lätt går att dividera med både 3, 4 och 6. Fördelningen kommer att se ut så här: Aktivitet Manmånader Planering (Kravanalys, arkitektur, design) 12 Kodning 6 Komponenttest och tidig systemtest 9 Systemtest med alla komponenter tillgängliga 9 Summa 36 Det som gör att det är så svårt att åstadkomma en så stor andel för planering av ett mjukvarusystem är naturligtvis att nästan alla vill komma till kodning så snart som möjligt. Det är först när det börjar finnas något så när körbar kod som det går att se några påtagliga resultat av allt arbete som har lagts ner. Brooks menar att inblandades brådska att få se resultat kan påverka planerat datum för färdigställande av systemet men inte verkligt datum. Han jämför med situationen för en kock: En omelett som utlovats inom två minuter kan se ut att utvecklas på ett positivt sätt under huvuddelen av den utsatta tiden. Men när de två minuterna har gått och omeletten inte har stelnat har kunden två alternativ att välja mellan. Han kan vänta tills den blir färdig eller äta den så gott som rå. Kocken har ytterligare ett alternativ: han kan höja värmen under slutet av de två minuterna, men resultatet blir i varje fall inte gourmetmat utan en omelett som är bränd på den ena sidan och närmast rå på den andra Brooks budskap är tydligt. Det är viktigt att avsätta tillräckligt med tid för att bestämma, dokumentera och kommunicera vad det tänkta systemet skall uträtta. Det är också viktigt att sätta av ordentligt med tid för att planera utformningen arkitektur och övergripande design av de delar systemet skall bestå av. Om allt detta arbete görs med tillräcklig noggrannhet förenklas kodningen rejält. Ändå kommer det att behövas mycket tid för att testa och stabilisera systemet så att det utför de uppgifter det är till för på ett korrekt sätt och att det tillgodoser alla verksamhets- och användarkrav. Vi kan tydligt se att Brooks idéer från 1975 vinner i betydelse. Aldrig tidigare har arkitektur varit så på tapeten i vår industri som nu, och aldrig tidigare har så mycket tid och pengar lagts ner på att utbilda arkitekter och ge dem utrymme tidigt i projekten. Kan det vara så att det vi åstadkommit hittills har visat att det behövs mer av arkitekturinsatser än vi varit beredda att sätta in? Kan det också vara så att den ökade komplexitet vi idag möter, jämfört med tidigare, gjort det uppenbart att vi måste tänka mer i förväg än vi hittills har gjort? Rörelserna XP och Lean Software Development då? Det kan tyckas som om rörelsen mot mer och bättre arkitektur står i djup kontrast mot rörelser som Extreme Programming (XP) och Lean Software Development. Vi menar att det inte är så, men det finns inte utrymme i den här artikeln att utveckla den tanken. Ändå vill vi säga att idéerna bakom Lean Software Development kan genomsyra hela arkitekturprocessen och kanske också bör göra det. När det gäller Extreme Programming finns det på ytan ett tydligt motsatsförhållande mot arkitekur, men det finns absolut inget som hindrar att man använder principerna för XP när man till exempel implementerar en service. XP-programmerarna kommer att ha ett tydligt servicegränssnitt att implementera och kan excellera i parprogrammering, testdriven utveckling och annat inom ramarna för sitt uppdrag. Det kanske till och med är så att man bör använda XP-principer för implementering av services. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 10
Om nästa artikel Därmed sätter vi punkt för januari månads artikel 2005. Den blev längre än jag tänkt mig. Jag hade tänkt göra den kortare än de tre artiklarna om SOA, men jag tror faktiskt att det blev tvärtom. Hoppas du har överseende med det och att du skall finna något för dig i den. Februari månads artikel kommer att handla om olika arkitektroller och arkitektens ansvar i förhållande i dessa roller till beställare, användare och utvecklare. Fokus i hela artikelserien, över alla de tre teman som är beslutade, ligger dock även fortsatt på lösningsarkitektens roll och uppdrag. Referenser I Frederick P. Brooks, Jr., The Mythical Man-Month Addison-Wesley, USA. ISBN-0-201-83595-9 II III IV V VI Marcus Vitruvius Pollio (Edited by Inrid D. Rowland and Thomas Noble Howe), Ten Books on Architecture Cambridge University Press, United Kingdom. ISBN 0-521-00292-3 Alan Cooper & Robert Reimann, About Face 2.0 The Essentials of Interaction Design Wiley Publishing Inc., USA. ISBN 0-7645-2641-3 Alan Cooper, The Inmates Are Running the Asylum Sams Publishing, USA. ISBN 0-672-31649-8 Marvin Trachtenberg, From Pre-History to Postmodernism Prentice Hall, USA. ISBN 0-8109-1077-2 Paul Clements, Rick Kazman, Mark Klein, Evaluating Software Architectures Addison-Wesley, USA. ISBN 0-201-70482-X Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 11