, Sundblad & Sundblad ADB-Arkitektur, Uppsala Så var det dags att återuppta skrivandet på den artikelserie jag inledde i våras för Microsofts svenska arkitektwebb. Den här gången vänder jag mig minst lika mycket till verksamhetens folk och beslutsfattare som till IT-sidans utvecklare, designers och arkitekter. Vad vi borde göra bättre Computer Sweden redovisade i en artikel våren 2005 en undersökning gjord av IDC. IDC presenterar sig på sin hemsida som the premier global provider of market intelligence, advisory services and events for the information technology and telecommunications industries. Organisationen har funnits i mer än 40 år och har mer än 775 analytiker spridda i 50 länder. Artikeln var skriven av Per Andersen, IDC Nordic, och redogjorde för resultaten av en undersökning om avdelningschefers viktigaste IT-prioriteringar. Avdelningscheferna prioriterade på följande sätt: 1. Program och tjänster som är bättre integrerade med företagets affärs- eller verksamhetsprocesser (36,2%). 2. Bättre åtkomst till relevant information (35,2%). 3. Bättre system för samverkan och kommunikation (31,6%). 4. Lägre systemkostnad (26,1%). 5. Förbättrad IT-säkerhet (23,4%). 6.... plus ytterligare några prioriteringsområden med lägre prioritet. Undersökningens resultat antyder att vi inom IT-industrin åtminstone delvis misslyckats med att ge våra uppdragsgivare det som borde vara allra viktigast för dem, nämligen stöd för deras viktigaste affärs- eller verksamhetsprocesser och tillräcklig tillgång till relevant information om verksamheten. Alltför teknisk arkitektroll Vi är övertygade om att felet ligger både på verksamhetssidan och på IT-sidan. Det som främst behövs är ett bättre och effektivare arkitekturbegrepp på IT-sidan och ett bättre utnyttjande av arkitekter på verksamhetssidan. Den uppfattning om arkitektur som idag dominerar är tämligen tekniskt orienterad. Vi menar att den borde vara mera verksamhetsanknuten. De företag och organisationer som tar till sig ett modernt och verksamhetsorienterat arkitekturbegrepp, anlitar moderna och verksamhetsinriktade systemarkitekter, och ger dessa arkitekter inflytande och frihet att verka i företagets tjänst har goda möjligheter att vinna betydande konkurrensfördelar. Jämfört med traditionell arkitektur är arkitektur av IT-system en extremt omogen företeelse. IT har ju inte som begrepp förekommit i mer än 60-talet år, inte ens om vi inkluderar data som var den usprungliga benämningen. Detta skall jämföras med till exempel romersk och grekisk byggnadsarkitektur från 100-tals år före Kristus. Marcus Vitruvius Pollio skrev under kejsar Augustus 10 böcker om arkitektur (Decem Libri de Architectura) cirka 30-20 år före Kristus. Dessa böcker finns fortfarande att köpa i översättning till engelska och med kommentarer och illustrationer, till exempel från företag som Amazon.com I. Det intressanta är att dessa urgamla böcker har en hel del att lära ut till oss moderna IT-människor, och att de kan hjälpa oss att etablera ett mera produktivt och verksamhetsorienterat arkitekturbegrepp än det som är gängse. Det är egentligen inte särskilt relevant att tala om ett gängse arkitekturbegrepp inom IT; sanningen är att det finns många. Det som förenar de flesta av dem är att de mera definieras som tekniska företeelser än som verksamhetsorienterade. IEEE Std 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems definierar arkitektur på följande sätt: Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

Denna definition innehåller inte minsta antydan om att arkitekten främst är till för att lösa problem och uppnå mål. Varje definition av arkitektur borde utgå från de problem som skall lösas och de mål som skall uppnås. Allt annat är mindre relevant. Redan Vitruvius visste det. Han räknade upp fyra egenskaper som god design måste uppvisa: God design måste lösa ett problem. Väl utformade föremål måste vara robusta. God design står emot tidens tand, vilket betyder att den måste vara tillräckligt formbar i händerna på olika människor över tiden. God design måste också skänka oss glädje; den måste röra vid våra hjärtan och få oss att må bra. Vitruvius talar också om arkitekturens tre grundbultar ( three pillars of architecture ). Grundbultarna benämns i följande lista på latin men förklaras på svenska. Jag har så gott jag kan försökt att fånga Vitruvius anda i de indirekta översättningarna från engelska till svenska: Utilitas. Den struktur som arkitekten etablerar måste vara användbar för sitt ändamål. Att presentera ändamålet är primärt beställarens ansvar, men arkitekten måste vara beredd att hjälpa beställaren att göra det. Att åstadkomma en struktur som är användbar för detta ändamål är arkitektens huvudansvar. Venustas. Strukturen måste ha stil och skönhet. Detta är helt och hållet arkitektens ansvar. Denna grundbult kan vi tolka på flera olika sätt. Vi kan tolka den så att den blir meningslös för IT-arkitekten, men vi kan också tolka den så att den blir en huvudsak. Mer om detta kommer i följande artiklar. Firmitas. Den måste också vara stark och hållbar. Att bygga för styrka och hållbarhet är primärt byggarens (utveckarens) ansvar, men det är också arkitektens ansvar att åstadkomma en struktur som tillåter det. Både när det gäller de fyra egenskaperna som god design måste uppvisa och de tre grundbultarna för arkitektur ser vi att Vitruvius mycket tydligt ger arkitekten ansvar för att den lösning han eller hon etablerar löser ett problem och är användbar för sitt ändamål. Vi ser också att arkitekten har ett övergripande ansvar för hela lösningen och fungerar som en bro mellan beställaren/användaren å den ena sidan och byggaren/utvecklaren å den andra. Inget av detta framgår av IEEEs definition av arkitektur. I artikeln Who Needs and Architect II berättar Martin Fowler om Ralph Jonhsons kritiska inställning till IEEEs definition av arkitektur. Johnson är också kritisk till RUPs definition av arkitektur, en definition som utgår från IEEEs. Johnson är inte vem som helst. Han är en av de fyra författarna till den klassiska boken Design Patterns III och tillhör därmed gruppen Gang of Four (GoF). Han är också en prominent företrädare för rörelsen Extreme Programming (XP). Man måste ta honom på allvar i frågor som rör programmering och design, och arkitektur är övergripande design. När dessutom en så respekterad förgrundsfigur som Fowler i positiva ordalag ( It s so good I ll quote it all ) refererar till Johnsons kritik finns det dubbel anledning att ta kritiken på allvar. Johnson erbjuder flera alternativa definitioner av arkitektur men är inte nöjd med någon av dem. Hans slutsats är att det blir svårt att tala om för folk hur de skall beskriva sin arkitektur och att architecture is about the important stuff. Whatever that is. Låt oss ta en kondenserad titt på de olika definitioner Johnson erbjuder. Han menar att var och en av dem är bättre än IEEE s och RUPs definitioner men kan ändå inte förorda någon av dem. Här följer några lösryckta citat, där vart och ett tänks uttrycka en av Johnsons definitioner av arkitektur: In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called architecture. Architecture is the decisions that you wish you could get right early in the project, but that you are not necessarily more likely to get them right than any other. Whether something is part of the architecture is entirely based on whether the developers think it s important. Lägg märke till att alla de här tre definitionerna enbart utgår från utvecklarens perspektiv. Det är som om utvecklaren är den ende intressenten (eng. stakeholder) av ett systems arkitektur och arkitekturbeskrivning. Det som är viktigt för utvecklaren ingår i systemets arkitektur; det som inte är viktigt för utvecklaren ingår inte! Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 2

Här kan det också vara intressant att ta del av Frederick P. Brooks Juniors arkitekturbegrepp. Brooks var projektledare för det dittills i särklass största mjukvaruprojektet någonsin utvecklingen av operativsystemet för IBM System/360. Han skrev en bok The Mythical Man-Month IV som delvis handlade om hans erfarenheter från detta projekt. Titeln refererar till det författaren kallar Brooks s Law som säger adding manpower to a late project makes it later. Bokens första upplaga gavs ut redan 1975, och den innehöll i varje fall det första jag läste om arkitektur i samband med databehandling (som det ju hette på den tiden). Brooks beskriver arkitektur som det man kan uppleva från en extern position. Han säger att arkitekten är ansvarig för alla de produktens aspekter som kan upplevas av dess användare. Så här säger Brooks: The architect forms and owns the public mental model of the product that will be used to explain its use to users. This includes the detailed specification of all of its function and the means for invoking and controlling it. The architect is also the user s agent, knowledgeably representing the user s interest in the inevitable tradeoffs among function, performance, size, cost, and schedule. Även Brooks lägger alltså, i likhet med Vitruvius och till skillnad från Fowler och Johnson, stor vikt på användbarhet och ändamålsenlighet. Det som kan upplevas från utsidan är arkitektur, det som kräver insyn i interiören är implementation. Detta synsätt stämmer exakt med det som Pat Helland, tidigare arkitekturprofessor i Microsofts arkitektgrupp och nu på Amazon.com, brukar framhålla om serviceorientering. Services handlar om deras meddelanden allt annat är bara implementering brukar Pat säga. En bredare arkitektursyn Även IEEE har ett bredare perspektiv på arkitektur än det som framgår av deras definition av arkitekturbegreppet. IEEE 1471-2000, som är den enda formella standard för beskrivning av IT-arkitektur som finns, räknar upp följande fyra obligatoriska stakeholders : a) Användare av systemet. b) Beställare (ägare) av systemet. c) Utvecklare av systemet. d) Underhållspersonal för systemet. IEEE 1471-2000 räknar också upp följande obligatoriska concerns : 1) Systemets ändamål och uppgift. 2) Systemets lämplighet att fylla sin uppgift. 3) Möjligheten att konstruera systemet. 4) Risker i systemets utveckling och användning för användare, beställare och utvecklare av systemet. 5) Hur görligt det är att underhålla, installera och vidareutveckla systemet. Beställaren, den som skall äga systemet och som är ansvarig för den verksamhet systemet skall stödja, måste vara den i särklass viktigaste intressenten i ett systems arkitektur. Om systemet inte bidrar till lösandet av verksamhetsproblem och uppnåendet av verksamhetsmål spelar det ingen roll hur det struktureras. Det inser IEEE och gör beställaren till en obligatorisk intressent av och systemets uppgift till ett obligatoriskt intresseområde för arkitekturbeskrivningar. En av idéerna bakom IEEE 1471-2000 är att en arkitekturbeskrivning måste adressera varje prioriterad intressent och täcka varje prioriterad concern. (Ordet concern är svåröversatt. Det motsvarar delvis den svenska termen intressent, men det finns också ett element av bekymrad oro i ordet concern.) Johnsons definition av arkitektur (och därmed av arkitekturbeskrivning) adresserar endast utvecklaren och dennes bekymrade intressen, inte till exempel beställaren eller användaren. Enligt både Johnson och Fowlers artikel är arkitektur alltså främst något för de utvecklare som skall implementera den och mindre något för att säkerställa att företagets verksamhetsprocesser får effektivt IT-stöd. Arkitektur är alltså mera till för att få en tillämpnings interna komponenter att samverka på ett bra sätt än för att få företagets hela tillämpningsportfölj att samverka för bästa stöd av företagets verksamhetsprocesser. SÅ BEHÖVER DET INTE VARA! Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 3

Olika arkitektroller ger bättre verksamhetsanknytning Varje företag av något så när storleksordning kan ta ett stadigt tag i sin IT-arkitektur och organisera en grupp IT-arkitekter med hela verksamhetens bästa för ögonen snarare än med målet att så effektivt som möjligt suboptimera varje tillämpning för sig. Verksamhetsarkitekter (Enterprise Architects) ansvarar för den stora helheten. En verksamhetsarkitekt är mer intresserad av att bygga det elektroniska företaget än av att bygga varje enskild tillämpning för sig. Verksamhetsarkitekten är också ansvarig för företagets nuvarande och planerade stadsplan av ITlösningar. En bra verksamhetsarkitekt är förmodligen mer en verksamhetsperson med IT-kunskap än en ITperson med verksamhetskunskap. Om vi jämför med traditionell arkitektur kan verksamhetsarkitekten förmodligen jämställas med stads- eller samhällsplaneraren. Lösningsarkitekter (Solution Architects) ansvarar för att enskilda lösningar ges en så effektiv övergripande externt synlig arkitektur som möjligt inom ramen för en övergripande verksamhetsarkitektur. En bra lösningsarkitekt är förmodligen en IT-person med god förståelse för verksamheten och för verksamhetsfrågor. Jämfört med traditionell arkitektur ligger nog lösningsarkitekten närmast byggnadsarkitekten. Service- eller tillämpningsarkitekter utgår från en övergripande lösningsarkitektur och etablerar en intern arkitektur för en enskild service eller tillämpning. Det är denna arkitektroll som ligger närmast den roll som Fowler och Johnson diskuterar i den tidigare nämnda artikeln. Det är ingen tvekan om att det är denna arkitektroll som ligger närmast utvecklare, men det är inte heller någon tvekan om att den behöver agera inom ramen för en arkitektur som säkerställer att nyutvecklade lösningar är optimerade för högre mål och problem än den enskilda lösningens. En bra service- eller tillämpningsarkitekt är förmodligen en utåtriktad seniorutvecklare med goda kunskaper i design. När vi inom IT-världen diskuterar arkitektur är det nog oftast den här rollen vi diskuterar. Så är säkert fallet med Fowlers artikel och dess referenser till Johnsons definitioner av arkitektur. En servicearkitekt skiljer sig från en tillämpningsarkitekt så att tillämpningsarkitekten har ansvar för den interna strukturen i en hel tillämpning. Servicearkitekten får i stället ansvar för den interna strukturen i en del av en lösning, den del som representeras av en specifik service. Tillämpningsarkitekten måste (eller bör) därför låna drag av lösningsarkitekten, en roll som knappast finns i objektorienterade sammanhang men får en stark roll i serviceorienterade. Tillämpningsarkitektens roll uppfattas allmänt som främst teknisk och utgår från beskrivningar av verksamheten som andra främst analytiker har gjort. Vi på Sundblad & Sundblad tror detta är en stor del av orsaken till att av IDC tillfrågade avdelningschefer så högt prioriterar orientering åt verksamhetens processer, åt åtkomst till relevant information, och åt samverkan och kommunkation. Om arkitekten har ett för tekniskt perspektiv, och om den analytiker som beskriver verksamheten inte fullt ut förstår tillämpningsarkitektens behov, kan det inte undvikas att de IT-system som produceras åtminstone delvis missar verksamhetens mål och behov. Eftersom både servicearkitekten och tillämpningsarkitekten främst sysslar med frågor som är interna för en service eller en tillämpning bör de närmast kunna jämföras med inredningsarkitekten. Hur det ser ut Tittar man på hur det ser ut idag har nog de flesta större företag och organisationer verksamhetsarkitektens roll besatt. Det är långt ifrån säkert att det finns en person med titeln verksamhetsarkitekt, men det finns alldeles säkert någon som åtminstone har ansvar för övergripande IT-frågor. Tillämpningsarkitekter finns det också rätt så gott om. De har det övergripande ansvaret för hur en tillämpnings komponenter skall struktureras och samverka med varandra, precis så som sägs i IEEEs definition av ett systems arkitektur. Den roll som nog saknas i de flesta företag är servicearkitektens, men det beror självklart på att serviceorientering ännu inte slagit igenom i den grad att lämpliga arkitektroller har etablerats. Tillämpningsarkitekten kan se till att en tillämpning får en så bra struktur som möjligt. Eftersom tillämpningsarkitekten i bästa fall är en seniorutvecklare med goda anlag för design, och eftersom tillämpningsarkitekten typiskt är med hela vägen till kod, är chansen också god att kod och arkitektur följer Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 4

varandra ganska väl. Refactoring hjälper till en hel del med det. Det är alltså inte säkert att ursprunglig arkitektur håller hela vägen; huvudsaken är dock att den löser sin uppgift. Den roll man nog kan säga saknas är lösningsarkitektens. Det beror återigen på att serviceorienteringen ännu är i sin linda; Gartner Group har ju spått att den omkring år 2008 kommer att dominera systemutvecklingen, men där är vi ju inte riktigt ännu. Många har börjat resan mot en serviceorienterad miljö men de flesta står ännu i bästa fall i startgroparna. Orsaken till att kopplingen mellan serviceorientering och rollen som lösningsarkitekt är så stark är att en av dennes uppgifter är att beskriva vilka tjänster som är inblandade i lösningen och hur de kommunicerar med varandra. Diagrammet i Figur 1 visar en grafisk arkitekturell översiktsbild av en lösning. Det verktyg vi har använt här är den Application Designer som kommer i Microsoft Visual Studio 2005 Team System. Figur 1 - Lösningsarkitektur för kapplöpningssystem Diagrammet visar ett antal var för sig fristående program som löser en uppgift genom att på ett lösaktigt sätt kommunicera med varandra för att få operationer genomförda. De tre grönaktiga ikonerna längst upp till vänster (RacingDataMaintainer, RaceHandicapper, RaceDataImporter) är Windowstillämpningar. De båda blåaktiga längst upp till höger (RaceBrowser, SubscriptionManager) är webbtillämpningar. De fyra nedersta ikonerna (HorseRaces, Subscriptions, Geographics, Customers) representerar fyra services som endast kan nås genom att sända meddelanden till dem. Exemplet är enkelt men ändå illustrativt. Det är denna typ av strukturer som lösningsarkitekten är ansvarig för. Jag vill gärna peka på några intressanta aspekter på en sådan lösning: Lösningen består av fem användartillämpningar och fyra services eller tjänster. Användartillämpningarna är specifika för den här lösningen medan tjänsterna är till för bred återanvändning. Man kan till exempel tänka sig att tjänsten Subscriptions också kommer att användas i en lösning för hantering av prenumerationer på de tryckta galopprogrammen. En tjänst som Customers kommer utan tvekan att återanvändas i åtskilliga lösningar. Namnen på både användartillämpningar och tjänster är direkt hämtade ur verksamhetens vokabulär. Folk från verksamheten kommer att ha lätt att förhålla sig till dessa namn och jämförelsevis väl förstå vad som ligger bakom dem. Det är en stor fördel! Lägg märke till de små ringarna som är startpunkt och slutmål för diagrammets pilar. Varje sådan ring utgör en så kallad endpoint, det vill säga en punkt från vilken eller till vilken meddelanden kan sändas. I vårt diagram har vi endast använt en typ av endpoint, nämligen web services endpoint. Varje Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 5

sådan mottagande ring representerar alltså en web service. Det är denna web service, inte tjänsten som exponerar den, som är relevant för tjänstens konsumenter. Ingen konsument behöver alltså förstå den helhet en tjänst representerar, endast de delar som är exponerade för konsumenten via en web service eller annan endpoint. Utvecklaren som användare Lösningsarkitekten tar alltså fram en struktur sådan som den i Figur 1. När denna struktur skall implementeras kan dess olika delar fördelas till olika utvecklargrupper. Dessa grupper blir då beroende av att dela på de kontrakt som bestämmer hur en konsument skall kunna konsumera med en tjänst. Då räcker det inte med att lösningsarkitekten presterar ett diagram sådant som figurens. Han eller hon måste bidra med detaljer om hur kontrakten ser ut så att implementeringen kan genomföras med så små friktioner mellan grupperna som möjligt. Då inträder något intressant. Ta en ny titt på diagrammet i Figur 1. RacingDataMaintainer är en formulärbaserad Windowstillämpning som är till för administratörens underhåll av den informationsresurs som tjänsten HorseRaces har ansvar för. Dessa båda program är helt olika till karaktären. Det ena är ett användartillvänt program som primärt har ett användargränssnitt; det andra har inget användargränssnitt men har ett stort och viktigt ansvar för en informationsresurs. Det är mycket troligt att dessa båda program i ett större projekt kommer att utvecklas av olika utvecklare. Den utvecklare som skall utveckla RacingDataMaint blir då en användare av tjänsten HorseRaces eller mer specifikt den web service som heter RacingDataMaint och som exponeras av HorseRaces. Arkitekten måste alltså ta hänsyn till denne utvecklares intresse av att utnyttja tjänsten. Det gör arkitekten genom att noggrant och detaljerat beskriva det gränssnitt RacingDataMaint som utvecklaren skall använda. Den beskrivningen måste utgå från utvecklarens behov att förstå vad som krävs för att utnyttja tjänsten och exakt vad resultatet blir av att göra det. Den andre utvecklaren är i lika hög grad en intressent av arkitektens design, men i en helt annan avsikt. Denne utvecklare måste ha lika god kännedom om gränssnittets detaljer eftersom hans eller hennes uppgift är att implementera gränssnittet. Båda är lika intresserade av tjänstens externa egenskaper. Den ena har till uppgift att implementera dessa egenskaper och därför även av de interna egenskaperna; den andre har inte ett uns intresse av de interna egenskaperna, inte så länge de är sådana att tjänsten uppfyller sitt externt synliga ansvar. Därför måste lösningsarkitekten också specificera kontraktet för varje web service. Det innebär bland annat att varje operation i varje web service måste definieras. Figur 2 visar ett exempel på dialogrutan Web Services Details där lösningsarkitekten har definierat operationerna för den web service som heter RaceBrowsing. Lägg märke till att varje operation returnerar ett XmlDocument och att de operationer som tar emot parametrar också tar emot dem som XmlDocuments. Figur 2- Web Services Details Om lösningsarkitekten har gjort ett bra arbete med att definiera tjänster, tjänsters gränssnitt, gränssnittens operationer och scheman, då vet implementationsgrupperna vad de har att implementera. Då minimeras friktionerna mellan implementationsgrupperna som i stället kan ägna sig åt att göra sitt jobb. Det går emellertid inte att helt utesluta behovet av kommunikation mellan grupperna, för inte heller lösningsarkitekten är felfri. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 6

För att detta skall bli möjligt krävs också en del textuell dokumentation. Både tjänster, web services och serviceoperationer måste textuellt dokumenteras till sitt syfte. Dessutom måste både de scheman som reglerar struktur och innehåll på de dokument som utväxlas vara definierade, liksom även de villkor (transportprotokoll, säkerhet och annat) som reglerar kommunikationen vara tydligt dokumenterade. Vi visar inte hur det kan gå till i denna artikel utan nöjer oss med att antyda behovet. Att lämna ut en arkitektur till implementering innan den är ordentligt specificerad är att be om bekymmer. Lägg märke till att en sådan arkitektur fokuserar på utsidan snarare än på någon insida. Vi följer idéer från både Brooks och Vitruvius, och vi gör det möjligt för verksamhetens folk och beslutsfattare att, kanske med någon hjälp, utvärdera om den arkitektur vi har etablerat har chansen att uppnå verksamhetens mål och lösa deras problem. En arkitektur som fokuserar på insidans komponenter har inte en chans att åstadkomma det. Information, processer och regelverk Ett företag, oavsett om det är affärsdrivande, offentligt eller en myndighet, är helt beroende av den information som beskriver företagets tillstånd och ställning vid olika tidpunkter. Utan tillgång till sådan information kan företaget liknas vid ett skepp i storm. Denna information ger företaget den kunskap det kan ha, och måste ha, om verksamheten. Man kan lugnt hävda att den utgör företagets ryggrad och benstomme. Ett företags informationsresurs kan emellertid bara ge en statisk bild av tillståndet i företaget. Om något av intresse skall kunna hända krävs också ett dynamiskt element. I ett verksamhetsorienterat system är det verksamhetens processer och aktiviteter som svarar för dynamiken. Företagets processer kan liknas vid människokroppens muskler. Det är ju musklerna som ger människokroppen dess handlingskraft. Musklerna är emellertid helt beroende av benstommen; utan den struktur benstommen skänker åt musklerna blir de inget annat än en hög dödkött. På samma sätt blir företagets processer impotenta om de inte kan utgå från hyggligt korrekt information om företagets aktuella tillstånd. Hur skall till exempel en faktureringsprocess kunna skapa fakturor om den inte vet vad företaget har levererat till vem? Människokroppen har också ett nervsystem som får musklerna att reagera på yttre stimulans. Nervsystemet innehåller också ett hämmande regelverk som hindrar oss från att reagera på olämpligt sätt. Även verksamhetssystemet behöver ett regelverk som både stimulerar till önskade reaktioner på yttre och inre händelser och förhindrar oönskade reaktioner. Varje verksamhetssystem bygger alltså på tre grundbultar, och det är dessa grundbultar en lösningasarkitekt måste studera och utgå från för att kunna etablera ett effektivt IT-stöd för verksamheten. Grundbultarna är: 1. Företagets informationsresurs. 2. Företagets verksamhetsprocesser. 3. Företagets regelverk. Var och en av dessa måste studeras och dokumenteras både för sig och tillsammans. Ett problem med dagens systemutveckling är att vi vanligen inte gör det. Det är därför vi behöver ett modernare och mera moget arkitekt- och arkitekturbegrepp än det som är mer eller mindre gängse i dag. Detta resonemang kommer jag att utveckla i de två återstående av nio artiklar i den pågående artikelserien för Microsofts arkitektwebb. Jag återkommer närmast om cirka en månad. Referenser I Vitruvius, Ten Books on Architecture, Cambridge University Press, ISBN 0-521-00292-3. II Martin Fowler, Who Needs an Architect, http://www.martinfowler.com/ieeesoftware/whoneedsarchitecture.pdf III Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addison-Wesley Publishing Company, ISBN 0-201-63361-2 IV Frederick P. Brooks, Jr., The Mythical Man-Month. Addison-Wesley, ISBN 0-201-83595-9. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 7