Arkitektrller ch arkitektansvar, Sundblad & Sundblad ADB-Arkitektur, Uppsala Nu är det februari 2005 ch dags för artikel två av tre m arkitektur, temat för Micrsfts arkitektwebb under första kvartalet 2005. Sm framgår av rubriken handlar den här artikeln m lika arkitektrller ch arkitektens ansvar i dessa rller. Artikeln innehåller inga absluta sanningar, det finns alldeles för många uppfattningar m arkitektur ch arkitektrller inm IT för det, men jag har gjrt ett allvarligt försök att utgå från Micrsfts framväxande bild. Jag har sedan dekrerat den med egna synpunkter ch input från andra håll ch hppas att slutresultatet skall vara användbart. Jag har strävat efter att så mycket sm möjligt använda det svenska språket. Ibland finns det inte någn riktigt bra översättning av ett engelskt uttryck, ch då kan användning av svenska missleda snarare än vägleda. För att undvika det har jag i förekmmande fall inm parentes visat vilket engelskt uttryck ett använt svenskt uttryck är avsett att mtsvara. Arkitektrller ch arkitektens rllansvar Innan jag går in på att beskriva lika arkitektrller vill jag betna vikten av att skilja på persn ch rll. En viss persn kan spela en eller flera arkitektrller, ch en arkitektrll kan spelas av en hel grupp. I svenska sammanhang hör man fta rd sm IT-arkitekt ch systemarkitekt. IT-arkitekt får ses sm ett övergripande begrepp medan systemarkitekt används av lika människr vid lika tillfällen i lika betydelser. De begrepp sm i växande utsträckning används i arkitektrienterade dkument från Micrsft Crp., varav en del ännu inte är publicerade, är de sm följer här: Glbala arkitekter (Glbal Level Architects) Företagsarkitekter (Enterprise Level Architects) Infrastrukturarkitekter (Infrastructure Architects) Lösningsarkitekter (Slutin Architects) Denna lista blir ckså utgångspunkten för våra resnemang m arkitektrller. Glbala arkitekter En glbal arkitekt arbetar mt mål sm delas av mängder av rganisatiner världen runt. Han etablerar ch publicerar generellt användbara referensarkitekturer ch generella standardmönster. En glbal arkitekt kan ckså ta fram exempellösningar sm skjuter fram vad man kan se sm best practices för specifika prblem ch lösningar. Primära mttagare av det sm levereras av en glbal arkitekt är företagsarkitekter, lösningsarkitekter ch infrastrukturarkitekter i lika företag ch rganisatiner. Vi vill gärna lista persner ch rganisatiner sm vi klassificerar sm glbala arkitekter: Pat Helland ch Maarten Mullender är två framstående arkitekter sm är anställda av Micrsft. (Detta gäller i varje fall i slutet av februari, då detta skrives. Pat har bestämt sig för att lämna Micrsft ch blir i stället företagsarkitekt, möjligen ckså lösningsarkitekt, hs Amazn.) Deras uppgift är framför allt att identifiera ch definiera ptentiella prblem i samband med utvecklandet av SOA-baserade miljöer ch att redvisa förslag till arkitektniska lösningar på dessa prblem. De arbetar alltså inte främst med Micrsftare sm mttagare av sina resultat; det är i stället andra arkitekter runt m i världen sm kmmer att använda ch implementera deras alster. Här skiljer sig dessa arkitekter från till exempel Steve Swartz ch Dn Bx. Dessa båda är arkitekter i det team sm är ansvarigt för Micrsfts Indig. Indig ingår i nästa versin av Micrsft Windws, kallad Lnghrn. Indig sammanför ett antal Micrsft-teknlgier sm COM+, MSMQ, ASP.NET
Arkitektrller ch arkitektansvar Web Services (ASMX) ch Remting samt ett antal transprtprtkll sm HTTP, TCP, UDP ch IPC under en ch samma huv. Idén bakm Indig är att erbjuda Micrsftkunder ett enhetligt ramverk ch ett enhetligt runtime-system för byggande ch exekvering av distribuerade system i allmänhet ch SOA-baserade system i synnerhet. Det är ingen tvekan m att så gtt sm alla sm utvecklar sådana system i Micrsftmiljö kmmer att få str glädje av det Steve Swartz ch Dn Bx lämnar ifrån sig, men det är inte vi sm kmmer att ta hand m ch implementera deras alster. Det kmmer i stället andra Micrsftare att göra, ch resultatet av deras arbete blir en implementatin av Indig. Därför är Steve ch Dn inte glbala arkitekter, i varje fall inte i sitt nuvarande dagliga värv, medan Maarten ch Pat är det. Jag vill sluta den här delen med att ge någt exempel på alster sm prducerats av Pat ch Maarten: Pat Helland har prducerat ch spelat in ett webb-baserat seminarium kallat Metrplis : Envisining the Service-Oriented Enterprise I. Maarten Mullender har skrivit en intressant artikel m servicegränssnitt vid förändring av innehåll i databas. I artikeln visar Maarten hur de flesta av ss dramatiskt kan minska användningen av CRUD-rienterade gränssnitt II. Micrsfts PAG Team är ett annat exempel på en glbal arkitekt. PAG står numera för Platfrm Architecture Guidance. Från början std det för Prescriptive Architecture Guidance. Gruppens allra första namn var emellertid the NAG team, där NAG std för Need Architecture Guidance. Den ursprungliga gruppen hade emellertid svårt att leverera resultat. Därför rganiserades den m ch döptes ckså m. Tanken med det nya namnet var att framhålla vikten av att ge ett eller ett fåtal föreskrivande råd snarare än en flra av mål för varje prblemsituatin. Med ny chef ch ny inriktning började the PAG Team ckså att leverera både referensarkitektur, designmönster ch böcker m Best Practices. The PAG Team har bland annat tagit fram Reference Architecture fr Applicatins and Services (RAA). Förkrtningen kan tyckas litet underlig eftersm den inte innehåller någn referens till rdet Services, men den passar ändå bra eftersm denna referensarkitektur inte är riktigt SOA-fähig utan mer lämplig för tätt sammanhållna applikatiner. PAG har ckså tagit fram ett antal böcker m designmönster, integratin, best practices ch inte minst viktigt säkerhet. Vi refererar inte till var ch en av dessa böcker ch skrifter för sig utan buntvis i frm av en URL till PAGs hemsida. III Det är ingen sm helst tvekan m att Micrsfts PAG Team är en glbal arkitekt. PAG-flket hämtar impulser från andra glbala arkitekter ch från resurser inm Micrsft. De filtrerar ch srterar möjliga element för att planera vad de skall publicera. De bidrar sedan med strt eget kunnande när de prducerar sina alster. Micrsfts PAG Team kan ses sm en mdell för liknande företagsspecifika grupper. Vi på Sundblad & Sundblad tycker att varje rganisatin sm menar allvar med sin satsning på.net-baserade lösningar bör fundera på att bygga upp ett eget mini-pag. Build yur wn PAG Team blir vår rekmmendatin till dessa företag ch rganisatiner. Vi på Sundblad & Sundblad brukar ckså se ss själva sm glbala arkitekter. Vi har alltsedan 1995 publicerat ett antal böcker m designmönster för användning i Micrsftmiljö, flera publicerade av ss själva IV ch en av Micrsft Press V. På senare tid har vi ckså tagit fram ett mfattande utbildningsmaterial sm vi i samarbete med Micrsft Sverige använder för utbildning ch certifiering av Micrsft.NET-arkitekter VI VII. I samband med dessa utbildningar har vi ckså tagit fram referensarkitektur för några lika typer av services. Utgångspunkterna har dels varit PAGs RAA ch dels våra egna mönster, publicerade i Design Patterns fr Scalable Micrsft.NET Applicatins IV. Martin Fwler är en annan glbal arkitekt. Han har prducerat sig flitigt i bkfrm, bland annat med en bk m refactring VIII, en m enterprisemönster IX ch nu senast en m UML 2.0. Han har ckså till Addisn-Wesley lånat ut sitt namn för en hel serie böcker m arkitektur med lika författare. Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 2
Arkitektrller ch arkitektansvar Mitt sista exempel på glbala arkitekter i Micrsftvärlden är Rger Sessins. Sessins är förankrad både i.net-lägret ch Javalägret ch skrev bland annat en bk m enterprise-plattfrmar. I den bken jämförde han COM+ med CORBA 3.0 ch med Enterprise JavaBeans X. Sessins är nu en ivrig förespråkare för SOA-idén ch har, starkt stimulerad av Pat Hellands mdell med fiefdms ch emissaries skrivit den läsvärda bken Sftware Frtresses XI. Han ger ckså peridiskt ut den kstnadsfria Object Watch Newsletter XII. Jag kunde ha räknat upp flera arkitekter sm enligt min uppfattning främst är glbala arkitekter. Syftet är emellertid inte att åstadkmma ett vem är vem inm glbal arkitektur utan att klargöra begreppet med hjälp av några exempel. Det hppas jag att jag nu har gjrt ch går därför över till nästa arkitektrll, företagsarkitekten. Företagsarkitekter Det engelska uttryckt är Enterprise Architect, men jag har valt att använda den åtminstne ungefärliga mtsvarigheten företagsarkitekt. Rllens psitin ch status skiljer sig åt i lika företagsstrlekar ch även i individuella företag myndigheter ch ffentliga institutiner inte undantagna men det bör ändå gå att ge en hygglig bild av företagsarkitektens ansvar. Det är inte vanligt att en företagsarkitekt har titlar sm IT-ansvarig (CTO Chief Technical Officer) eller infrmatinsansvarig (CIO Chief Infrmatin Officer). Det är inte heller vanligt att dessa rller helt separeras från företagsarkitekten, eller att rllen sm företagsarkitekt spelas av en hel grupp eller kmmitté. I en sådan grupp kan även andra arkitektrller ingå. Att vara företagsarkitekt är inte att ha ett jbb sm i första hand är tekniskt. Jbbet är i allra högsta grad verksamhets- ch affärsrienterat. Bland en företagsarkitekts viktigaste egenskaper ingår förståelse av verksamheten, dess strategi ch visiner, dess kunder ch knkurrenter. Där ingår ckså en förmåga att utifrån denna kunskap etablera en övergripande arkitekturell visin för företagets IT-stöd ch IT-resurser. Företagsarkitektens mål En företagsarkitekt arbetar mt övergripande mål sm är gemensamma för hela företaget. Det innebär till exempel att företagsarkitekten: äger den stadsplan sm dels ger en ögnblicksbild av hur företagets IT-stöd ser ut just nu, men ckså ger en visin av hur det bör se ut i en bestämd framtid; stadsplanen talar m vilka system, tjänster ch resurser sm finns idag ch sm enligt en uttalad visin kmmer att finnas i ett senare skede; stadsplanen talar m vem sm äger respektive system, tjänst ch resurs; stadsplanen beskriver tillståndet för varje system, tjänst ch resurs. Tillståndet beskrivs i termer av prblem ch önskemål m förbättringar, men ckså i termer av vad sm fungerar bra; äger eller ansvarar för en prjektprtfölj, där varje prjekt klassificeras i termer av: bidragsptential, det vill säga den ptential prjektet har att direkt eller indirekt bidra till företagets resultatrad. En str bidragsptential ökar självklart intresset för att genmföra prjektet; kmplexitet, det vill säga hur enkelt eller kmplicerat prjektet förefaller att bli. Ett enkelt prjekt är relativt fristående medan ett kmplext prjekt har många kpplingar till andra system ch tjänster. En hög kmplexitetsgrad ökar naturligtvis risken att prjektet blir misslyckat ch att bidragsptentialen inte kmmer att uppnås; strlek i termer av hur kstsamt det kan bli att genmföra prjektet. Figur 1Errr! Reference surce nt fund. visar ett enkelt exempel på ett diagram sm redvisar ptentiella prjekt utifrån dessa dimensiner. Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 3
Arkitektrller ch arkitektansvar Prjekt P1 exemplifierar det amerikanerna kallar lw hanging fruit. Cirkelns strlek visar att det inte krävs särskilt mycket tid eller flk för att genmföra prjektet. Prjektets placering i diagrammet visar att det är ett kmplicerat prjekt sm förmdligen inte kräver särskild expertkunskap ch inte invlverar alltför många andra system eller tjänster. Därför är prjektets frukter lättåtkmliga hanging lw, ch det bör gå att utnyttja tillfälligt ledig kapacitet för att plcka dem. Figur 1 - Diagram över prduktprtfölj Företagsarkitektens nätverk En företagagsarkitekts primära nätverk kan se ut sm i Figur 2. Skissen förutsätter att företagsarkitekten inte samtidigt är CTO eller CIO; m så är fallet får företagsarkiktekten då ch då byta hatt ch kmmunicera med sig själv. Figur 2 - Företagsarkitektens primära nätverk Följande lista utgör en kmmentar till vanstående figur ch redgör i stra drag för hur företagsarkitekten kan utnyttja sitt nätverk: Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 4
Arkitektrller ch arkitektansvar Företagsledningen Företagsarkitekten kmmunicerar med företagsledningen för att få infrmatin m verksamhetens idéer ch innehåll, m prdukter ch tjänster, ch m strategier, visiner ch ht från knkurrenter. Företagsarkitekten redvisar ckså till företagsledningen sina visiner ch planer för en förbättrad verksamhet via IT-stöd. CTO ch CIO I den mån företagsarkitekten ch CTO eller CIO inte är samma persn samverkar de för att utarbeta de visiner ch planer för förbättrad verksamhet via förbättrat IT-stöd sm skall redvisas för företagsledningen. Prcessägare ch ägare av "Capability Grups För att etablera den prtfölj av ptentiella prjekt sm exemplifieras i Figur 1 måste företagsarkitekten samarbeta med ägare av företagets verksamhetsprcesser ( business prcesses ). Om företaget har anammat Micrsfts kmmande taxnmi sm icke-redundant ch hierarkiskt bryter ner företagets handlingsförmåga i ett antal cre capabilities, capability grups ch business capabilities samarbetar företagsarkitekten i stället med ägare av capabilities. Figur 3 visar hur en capability map kan mfatta tre eller vanligen flera nivåer, där nivå 1 utgörs av ett antal cre capabilities sm i tur ch rdning specificeras i de underliggande nivåerna. Figur 4 - Micrsfts generiska Capability Map i nivå 1 Kartan mfattar ckså sex externt tillgängliga capabilites: A. Kunder, sm köper företagets prdukter. Figur 3 - "Capability taxnmy" Figur 4 visar hur Micrsfts generiska Capability Map ser ut på högsta nivå. Den består av fem interna cre capabilities sm tillsammans ger en fullständig bild av vad varje affärsdrivande företag måste klara av att utföra: 1. Det måste kunna utveckla prdukter ch tjänster. 2. Det måste kunna generera efterfrågan på dessa prdukter ch tjänster. 3. Det måste kunna leverera de prdukter ch tjänster sm företagets kunder köpt. 4. Det måste kunna planera, styra ch redvisa verksamheten. 5. Det måste kunna samverka med andra företag. B. Sådana partners sm via lika kanaler fungerar sm mellanhand mellan företaget ch dess kunder. C. Leverantörer till företaget av prdukter ch tjänster. D. Leverantörer till företaget av lgistiktjänster. Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 5
Arkitektrller ch arkitektansvar E. Leverantörer till företaget av finansiella tjänster. F. Tillgänglig infrastruktur. Ett företag sm anammar denna mdell utser en persn sm ansvarig för var ch en av dessa fem cre capabilities. Företagsarkitekten blir ansvarig för att etablera ch underhålla mdellen, vilket bland annat innebär att tillsammans med respektive ägare av cre capabilities mdifiera den generiska mdellens översta nivåer i varje fall till den nivå sm består av det Micrsft kallar capability grups. Figur 5 är ett exempel på en mdifierad capability map sm åtminstne delvis är öppnad till nivå 3. Mdifieringarna har gjrts av ett av Micrsft skapat exempelföretag i finansbranschen. 3. Purchase and Certify Assets är exempel på en cre capability; 3.1 Purchase Decisin är exempel på en capability grup; 3.1.1 Submit Asset är exempel på en business capability. Lämpligt är att den sm är ansvarig för en cre capability utser en ansvarig för varje ingående capability grup. Denne persn blir en utmärkt samtalspartner för lösningsarkitekten när ett prjekt skall förbättra eller nyutveckla stöd för en viss capability grup. Figur 5 - Exempel på Capability Map delvis nedbruten till nivå Infrmatinsägare På samma sätt sm aktiviteter ch förmåga till handling kan inrdnas i en icke-redundant hierarkisk struktur kan infrmatinsentiteter inrdnas i ett icke-redundant mönster av infrmatinsmråden. Både företagsledning ch de flesta anställda har fta en gd idé m vilka dessa infrmatinsmråden är. Kunder, prdukter, rder, leveranser, fakturr, kundreskntra, leverantörer, leverantörsreskntra ch persnal är några sm lätt kmmer på tungan (eller kanske snarare på tangenterna). En av uppgifterna för en företagsarkitekt är att tillsammans med ledningen ch ägarna till respektive infrmatinsmråde frmellt bestämma hur den infrmatin företaget är berende av för sin verksamhet ch förfgar över skall indelas i infrmatinsmråden ch åtminstne med tiden klargöra gränserna mellan de lika infrmatinsmrådena. I en servicerienterad miljö blir varje infrmatinsmråde en stark kandidat till en entitetstjänst ( entity service ) sm är tänkt sm den enda auktriteten ch den enda sanna källan till den infrmatin sm ingår i detta infrmatinsmråde. Lösningsarkitekter Företagsarkitekten har en tät ch intensiv samverkan med företagets lösningsarkitekt eller lösningsarkitekter. Inför varje utvecklingsprjekt måste företagsarkitekten tillsammans med ägare av prcesser, capabilities ch infrmatin ge lösningsarkitekten kntextuell infrmatin m det system sm skall byggas eller mdifieras. För att göra ett bra jbb måste lösningsarkitekten förstå det sammanhang i termer av infrmatinsmråden, prcesser ch capabilities inm vilket systemet skall fungera. I sammanhanget (kntexten) ingår ckså de mål det nya systemet är tänkt att uppfylla ch de restriktiner inte minst de eknmiska sm påverkar utvecklingen av det. Företagsarkitekten förser ckså lösningsarkitekten med standards ch riktlinjer sm måste följas vid utfrmning ch implementering av det tänkta systemet. Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 6
Arkitektrller ch arkitektansvar Sm sig bör är företagsarkitekten ckså en viktig intressent ( stakehlder ) till den arkitekturbeskrivning lösningsarkitekten tar fram. Särskilt gäller det den kntextuella delen av beskrivningen (den nivå vi kallar för Business Views i vårt arkitektniska ramverk), men ckså den knceptuella delen (sm vi kallar för Cnceptual Views). Figur 6 visar hur vårt ramverk är indelat i fyra abstraktinsnivåer ch fem aspekter på det tänkta systemet. Det är på den översta nivån den kntextuella sm företagsarkitekten ch lösningsarkitekten har störst utbyte av varandra. Figur 6-2xSundblads arkitektniska ramverk Infrastrukturarkitekten Företagsarkitekten måste ckså tämligen flitigt kmmunicera med infrastrukturarkitekten, sm ju är ansvarig för den tekniska infrastruktur sm behövs för att förverkliga företagsarkitektens planer ch visiner. Infrastrukturarkitekten måste vara väl förtrgen med dessa planer ch visiner för att kunna stödja dem, ch företagsarkitekten måste i grunden förstå de restriktiner ch begränsningar sm nuvarande ch planerad infrastruktur utgör för företagsarkitektens planer. Andra företagsarkitekter Att vara företagsarkitekt är att ha ett ganska ensamt jbb. Åtminstne är det så för rätt många företagsarkitekter. Det finns i regel bara en företagsarkitekt på ett företag, i varje fall på de företag sm inte har en grupp i stället för en persn sm spelar företagsarkitektens rll. Därför kan det vara ganska bra för en företagsarkitekt att söka kntakt med företagsarkitekter på andra företag. Det ger möjlighet till ett infrmellt utbyte av infrmatin, kunskap ch erfarenheter mellan jämlikar, någt sm kan bidra till skapandet av både trygghet ch drivkraft. Infrastrukturarkitekter En infrastrukturarkitekt har sm sin huvuduppgift att etablera en teknisk infrastruktur sm tillgdser de behv sm specificerats av företagsarkitekten. Infrastrukturarkitekten måste självklart ta hänsyn till de restriktiner sm förekmmer inte minst de budgetrestriktiner sm styr tillgången till eknmiska medel, men huvuduppgiften är likväl att etablera en teknisk infrastruktur sm tillgdser verksamhetens behv. Infrastrukturarkitektens mål Infrastrukturarkitekten arbetar mt mål sm är gemensamma för hela företaget. Huvudmålet är att till överkmlig kstnad etablera en teknisk infrastruktur sm tillgdser företagets behv av infrmatinsåtkmst ch infrmatinshantering, samt sådant sm säkerhet, tillgänglighet, skalbarhet, prestanda ch pålitlighet. För att uppnå detta mål måste infrastrukturarkitekten: ha förmåga att förstå verksamhetens behv ch prblem; ha gd bredd i sina kunskaper m tillgängliga teknlgiska möjligheter; ha djup teknlgisk kunskap inm någt eller några relevanta teknlgimråden; Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 7
Arkitektrller ch arkitektansvar ha en stark vilja att hänga med i teknlgiska trender ch att hålla sina kunskaper aktuella; ha gd kunskap m användbar teknisk referensarkitektur sm till exempel Micrsft Enterprise Data Center (EDC) ch Internet Data Center (IDC); ha gd förmåga att beskriva ch specificera en föreslagen teknisk infrastruktur; klara av att presentera ch försvara valet av teknisk infrastruktur för lika grupper på lika kunskapsnivåer både vad gäller teknik ch verksamhet; kunna samverka med systemingenjörer för att säkerställa att en beslutad teknisk infrastruktur blir krrekt implementerad. Infrastrukturarkitektens nätverk En infrastrukturarkitekts primära nätverk kan se ut sm i F igur 7. Skissen förutsätter, vilket inte alltid är fallet, att infrastrukturarkitekten ch CTO inte är en ch samma persn. Figur 7 - Infrastrukturarkitektens primära nätverk Till skillnad från företagsarkitekten är infrastrukturarkitektens jbb primärt tekniskt m än på en tämligen hög abstraktinsnivå. Sm framgår av följande lista påverkar detta infrastrukturarkitektens kmmunikatin med sina nätverkspartners. Detta mtsäger emellertid inte det jag redan knstaterat: att infrastrukturarkitekten måste ha en gd förmåga att kmmunicera en tänkt eller befintlig teknisk infrastruktur till icke-teknisk persnal. Företagsledningen Företagsledningen är ett bra exempel på samtalspartners sm nrmalt inte är tekniskt rienterade. Ändå måste infrastrukturarkitekten kunna kmmunicera effektivt med företagsledningen, dels för att få infrmatin m företagets affärsidé, strategi ch inriktning, dels för att förhandla m budgetmedel ch dels för att på ett säljande sätt kunna presentera befintlig ch föreslagen teknisk infrastruktur. CTO Om inte CTO ch infrastrukturarkitekten är en ch samma persn måste de gemensamt arbeta fram riktlinjer för en teknisk infrastruktur sm inm givna eknmiska ramar tillfredsställer verksamhetens Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 8
Arkitektrller ch arkitektansvar behv. Vid behv måste de gemensamt knstatera att tillgängliga eknmiska ramar är tillräckliga ch då bygga upp en hållbar argumentatin för utvidgade ramar eller (åtminstne tillfälligt) reducerade krav på den tekniska infrastrukturen. De måste även i övrigt intimt samarbeta för att nå uppsatta mål. Företagsarkitekten ch CIO tillsammans En av de saker infrastrukturarkitekten måste kmma överens med både CTO ch företagsarkitekten m är vilken plattfrm eller vilka plattfrmar den tekniska infrastrukturen skall bestå av. Endast de allra minsta företagen kan räkna med en hmgen IT-plattfrm; för större företag är det så gtt sm självklart att IT-miljön är blandad, även m en av de använda plattfrmarna anses sm mest strategisk ch därför dminerar åtminstne vid nyutveckling. Systemingenjörer Systemingenjörer har uppgiften att implementera infrastrukturarkitektens tekniska arkitektur. Därför är det självklart att infrastrukturarkitekten måste kmmunicera med sina systemingenjörer ibland ganska intensivt. Det gäller ju dels att kmmunicera infrastrukturens arkitektur till systemingenjörerna, men ckså att övervaka att den verkligen blir implementerad sm det var tänkt. Det finns även andra skäl för infrastrukturarkitekten att ha ett gtt förhållande till sina systemingenjörer. En typisk infrastrukturarkitekt har större bredd än djup i sin tekniska kunskapsarsenal. Detta är sant även m man bör begära ett hyggligt kunskapsdjup inm åtminsne ett par teknlgimråden. Om det inte är så i början av karriären sm arkitekt blir det gärna så med tiden, eftersm det breda ansvaret inte tillåter tillräckligt mycket djupdykning för att de riktigt djupa kunskaperna skall bestå över tiden ch vidareutvecklas. Med systemingenjören är det tvärt m. Han eller hn har i allmänhet större djup men mindre bredd än infrastrukturarkitekten. En klk infrastrukturarkitekt drar fördel av den här skillnaden ch knsulterar gärna sina systemingenjörer innan några avgörande beslut m förändrad infrastruktur fattas. Operatinsansvariga En peratinsansvarig blir med nödvändighet infrmerad m brister i den tekniska infrastrukturen. Därför är peratinsansvariga bra ch värdefulla medlemmar i infrastrukturarkitektens nätverk. Lösningsarkitekter En lösningsarkitekts uppgift är att etablera en övergripande arkitektur för lösandet av ett specifikt verksamhetsprblem i taget. Det kan vara att effektivisera sälj-, inköps- eller tillverkningsprcessen, eller att utfrma ett nytt system för någt särskilt ändamål. Lösningsarkitektens arbete medför så gtt sm alltid utveckling av nya tjänster, kmpnenter ch databaser. Dessa måste spridas över ch installeras på infrastrukturens element. Lösningsarkitektens tjänster ch kmpnenter ställer krav på infrastrukturen, sm i sin tur är behäftad med restriktiner sm infrastrukturarkitekten fta värderar högt. När lösningens krav är förenliga med infrastrukturens restriktiner kan ingen av parterna ensam lösa prblemet de måste kmma överens m en lösning. Lika högt sm infrastrukturarkitekten värderar sina restriktiner värderar lösningsarkitekten sina krav ch behv. De förra garanterar ju kntrll ch säkerhet de senare kmmer från verksamheten. Därför kan just denna kntaktyta mellan de båda arkitektrllerna ses sm ett farligt kraftfält sm det gäller att beträda varsamt. Förmdligen är det främst här sm den för varje arkitektrll så viktiga egenskapen att vara en gd diplmat ställs mest på prv. Någn har sagt att en diplmat är en persn sm kan be en dra åt ett mycket hetare ställe på ett sådant sätt att man ser fram mt resan. Kanske är det sådana diplmatiska anlag sm behövs när en lösningsarkitekt ch en infrastrukturarkitekt träffas för att diskutera deplyment. Andra infrastrukturarkitekter Den typiske infrastrukturarkitekten är förmdligen lika ensam sm den typiske företagsarkitekten. Därför kan det vara bra även för infrastrukturarkitekten att söka kntakt med klleger utanför företaget för att få igång ett givande infrmellt utbyte mellan jämlikar av infrmatin, kunskap ch erfarenhet. Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 9
Arkitektrller ch arkitektansvar Lösningsarkitekter En lösningsarkitekt ( slutin architect ) har sm redan nämnts uppgiften att lösa verksamhetsprblem genm att utfrma lösningar. En typisk sådan lösning utgörs av en övergripande arkitektur sm sedan implementeras av designers ch utvecklare. Lösningsarkitektens rll kan lätt förväxlas med applikatinsarkitektens men de skiljer sig från varandra, särskilt i SOA-sammanhang. Lösningsarkitekten har i SOA-sammanhang ett övergripande ansvar för den arkitektur sm beskriver hur en lösning utnyttjar lika samverkande services. Ett viktigt resultat av lösningsarkitektens arbete är en detaljerad skiss över ett servicerienterat system. Skissen visar sådant sm vilka services sm är invlverade i lösningen ch hur de samverkar med varandra; vilka servicegränssnitt ( endpints ) var ch en av dessa services expnerar; vilka servicemetder sm skall expneras av respektive servicegränssnitt; vilka scheman sm skall deklarera innehållet i de meddelanden sm utväxlas i respektive servicemetd. Steve Swartz, sm är Prgram Manager ch arkitekt i den grupp sm utvecklar Indig, använder sig av begreppet Service Authr. Så här säger Swartz m de uppgifter en sådan har: Define a set f endpints int which messages will cme in ; Each service will have a bunch f endpints ; (En web service är ett typiskt exempel på en endpint vår kmmentar); Define peratins fr each endpint ; Define schemas fr each endpint. Swartz säger ckså att en service authr inte gör någt annat än att definiera endpints ch metadata sm till exempel XSD-scheman. Det är sedan upp till utvecklare att på insidan av tjänsten implementera var ch en av dessa endpints. Applikatinsarkitekten ansvarar för att etablera arkitektur för en applikatin, vilket innebär ett mera bjektrienterat ansvar. En applikatin skiljer sig från ett servicerienterat system genm att de delar sm bildar applikatinen är mera tätt sammanhållna ch mera intimt berende av varandra i termer av bjektmdell, prgrammeringsspråk, perativsystem ch annat. Både Dn Bx ch Pat Helland har vid flera tillfällen pängterat att begreppet applikatin i ITsammanhang är ett tydligt begrepp m vars innebörd de flesta av ss är överens. Båda menar att vi även frtsatt bör låta detta begrepp stå för vad det står för idag ch att det då blir irrelevant i SOAsammanhang. I SOA-miljö bygger vi inte längre applikatiner, säger Bx, vi bygger system av prgram sm kmmunicerar med varandra genm att utväxla meddelanden. Vi på Sundblad & Sundblad menar att lösningsarkitektens huvuduppgift är att definiera services, service endpints ch interaktin mellan services på sätt sm angivits i den första punkten van. Den är däremt inte primärt att definiera arkitektur för innehållet i en service. Denna senare uppgift liknar mer den traditinelle applikatinsarkitektens, men en service är ju nu inte en applikatin, så det verkar inte relevant attkalla en sådan arkitekt/designer för applikatinsarkitekt. Vi har föreslagit uppdelning av rllen sm lösningsarkitekt i två huvudrller, där chief slutin architect är ansvarig för definitin av services, endpints, peratins and schemas medan junir slutin architects är ansvariga för definitin av innehållet i varje service. Skissen i Figur 8 visar hur arkitekturarbetet skulle kunna fördelas mellan lika arkitektrller ch utvecklingsteam: Företagsarkitekten förser lösningsarkitekten med kntextuell infrmatin sm till exempel vilka infrmatinsmråden ch vilka capability grups sm kmmer att beröras av det tänkta systemet. Finns det befintliga prcess-, aktivitets- eller entitetstjänster ingår uppräkning av dem i den kntextuella infrmatinen. På så sätt säkerställer företagsarkitekten att lösningsarkitekten är medveten m den stra bilden, vilket förhppningsvis leder till att risken för skadlig subptimering minskar. Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 10
Arkitektrller ch arkitektansvar Företagsarkitekten hjälper ckså verksamhetsansvariga att frmulera ch till lösningsarkitekten överföra infrmatin m det tänkta systemets uppgifter. Lösningsarkitekten samarbetar med företagsarkitekten för att på ett riktigt sätt dkumentera den kntextuella infrmatin, de uppgifter m det tänkta systemets uppgifter ch mål ch de standards ch riktlinjer sm kmmer ut av den samverkan sm beskrivs vid den föregående punkten. Därefter samarbetar lösningsarkitekten med verksamhetsmrådets experter ch användare för att analysera infrmatinsbehv ch infrmatinsbidrag, verksamhetsprcesser ch användningsfall, standards ch riktlinjer, krav på säkerhet ch allt annat sm behövs för att i grunden förstå det verksamhetsprblem sm skall lösas, de verksamhetsmål sm skall uppfyllas, ch de restriktiner sm måste inverka på lösningen. När all sådan infrmatin föreligger är det lösningsarkitektens uppgift att i en övergripande arkitektur visa vilka services sm skall skapas ch vilka eventuellt befintliga services sm skall återanvändas. I det arbetet ingår uppgiften att i detalj beskriva varje service utsida i termer av servicegränssnitt ( endpints, varav de mest vanligen förekmmande är eller blir web services), servicemetder ch scheman för requests ch respnses. Junirarkitekterna (Junir Slutin Architects) utgår från den knceptuella arkitektur sm tagits fram av lösningsarkitekten ch etablerar en arkitektur sm övergripande beskriver insidan av varje tjänst. Man kan se denna arkitektur sm en implementatinsarkitektur, ch dess uppgift är att implementera de endpints sm definierats av servicearkitekten. Lösningsarkitekten finns hela tiden i närheten när detta arbete pågår. En viktig uppgift för lösningsarkitekten är att övervaka junirarkitekternas arbete så att den arkitektur de etablerar inte bryter mt den övergripande arkitektur sm skall implementeras. En annan uppgift är att vara mentr till de ftast yngre ch mindre erfarna junirarkitekterna. En tredje är att ständigt finnas till hands för att lösa prblem, till exempel genm att mdifiera sådana delar av den övergripande arkitekturen sm visat sig inte hålla för alla inblandade. Slutligen behövs implementatin teams sm implementerar varje service utifrån den interna arkitektur sm etablerats av junirarkitekterna. Figur 8 - Möjlig rganisatin av grupper för arkitektur ch implementatin. Lösningsarkitektens mål Sm säkerligen har framgått av tidigare delar av detta avsnitt arbetar lösningsarkitekten mt mål sm är specifika för delar av verksamheten ch sm skall lösas i ett visst prjekt. Lösningsarkitekten bör emellertid undvika subptimering ch bör därför intimt samarbeta med företagsarkitekten. Prjektrienterad subptimering är synnerligen vanligt ch blir så gtt sm undvikligen resultatet av alltför vattentäta sktt mellan lika prjekt sm vart ch ett arbetar utan tydlig kntextuell infrmatin. I vårt ramverk se Figur 6 är det abstraktinsnivån Business Views sm skall ge den kntextuella infrmatin sm är nödvändig för undvikande av subptimering. Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 11
Arkitektrller ch arkitektansvar Lösningsarkitekten måste få ett tydligt uppdrag där det tänkta systemets sammanhang (kntext) är tydligt angiven. Det är ckså viktigt att lösningsarkitekten ch företagsarkitekten har ett nära samarbete så att lösningarkitektens resultat fungerar väl, inte bara per se utan ckså i sitt sammanhang. Lösningsarkitekten måste ckså ha ett gtt samarbete med infrastrukturarkitekten. Den lösning sm tas fram av lösningsarkitekten måste installeras i den teknlgiska infrastruktur sm infrastrukturarkitekten ansvarar för. Det är långt ifrån alltid sm lösningsarkitektens krav ch önskemål är förenliga med infrastrukturens restriktiner, ch då måste de båda arkitekterna kunna kmma överens m vad sm skall göras, avsett m det initialt verkar möjligt för de båda att nå fram till en överenskmmelse. Det är här sm den viktiga egenskapen hs varje arkitekt, nämligen att vara en gd diplmat, verkligen ställs på prv. Lösningsarkitektens nätverk En lösningsarkitekts primära nätverk kan se ut sm i Figur 9. Figur 9 - Lösningsarkitektens primära nätverk Ledningsgruppen Det kanske inte främst är ledningsgruppen lösningsarkitekten har ett nära samröre med, men det är viktigt att det finns ett gtt samarbete mellan den eller de persner sm har huvudansvar för det verksamhetsmråde sm är föremål för utredningen ch den tänkta systemutvecklingen. De måste på ett tydligt sätt, fta i samverkan med företagsarkitekten, överföra infrmatin till lösningsarkitekten m de verksamhetsprblem sm behöver få en bättre lösning ch de verksamhetsmål systemet måste bidra till uppnåendet av. Ägare av Capability Grups eller prcesser ch deras mrådesexperter Prcessägare ch i varje fall när Micrsft gjrt stödet för businesess capability mapping tillgängligt ägare av capability grups är naturliga samtalspartners för en framstående lösningsarkitekt. Det främsta önskemålet sm verksamhetsflk i en nylig IDC-undersökning förde fram var att de önskade IT-stöd sm i högre grad än var fallet var förenligt med företagens verksamhetsprcesser. För att tillgdse det önskemålet måste lösningsarkitekten självfallet, möjligen med hjälp av prcessanalytiker, skaffa sig en tydlig ch detaljerad uppfattning m hur de av företagets verksamhetsprcesser sm är relevanta för prjektet ser ut. Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 12
Arkitektrller ch arkitektansvar Ägare av infrmatinsmråden ch deras mrådesexperter Det önskemål från verksamhetsflk sm i IDC-undersökningen km på en tydlig andraplats var önskemålet m bättre tillgång till mer relevant infrmatin m verksamheten. För att tillgdse det önskemålet måste lösningsarkitekten, möjligen med hjälp av infrmatinsanalytiker, skaffa sig en tydlig ch detaljerad bild av de infrmatinsstrukturer sm är relevanta för prjektet. Lösningsarkitekten måste i det sammanhanget ckså reda ut ch dkumentera de restriktiner sm avgör m infrmatin sm skall lagras är giltig eller ej. Företagsarkitekten Lösningsarkitektens samverkan med företagsarkitekten har jag pratat tillräckligt m i den här artikeln, så jag nöjer mig med att knstatera att en gd ch effektiv samverkan mellan dessa rller är av den allra högsta betydelse för ett gtt IT-stöd för verksamheten ch dess prcesser. Infrastrukturarkitekten Jag nöjer mig här med att referera till det sm tidigare sagts i den här artikeln m den synnerligen viktiga kmmunikatinen mellan lösningsarkitekten ch infrastrukturarkitekten. Vi kmmer att dyka ner litet djupare i den kmmunikatinen i nästa artikel i serien, den sm handlar m arkitektens verktyg ch metder. Säkerhetsansvarige Enligt vår erfarenhet här på Sundblad & Sundblad är det ganska vanligt att en lösningsarkitekt ckså är säkerhetsexpert. Icke dess mindre är det viktigt att säkerhetsaspekter tas med från början ch att de ingår i en lösnings arkitektur. Därför måste lösningsarkitekten ch säkerhetsarkitekten ha en frtlöpande dialg dels i samband med att säkerheten planeras för varje prjekt ch dels rent allmänt för att de båda skall kunna utbyta kunskap ch erfarenhet med varandra. Prjektledaren Att lösningsarkitekten ch prjektledaren måste ha en nära ch gd kntakt är så gtt sm självklart. Prjektledaren ansvarar för att lösningen blir krrekt ch för att den levereras i tid ch inm budget. Det är någt lösningsarkitekten måste ta hänsyn till. Alltför vidlyftig ch kmplex arkitektur kan negativt påverka möjligheten att leverera i tid ch inm budget; tillräckligt genmtänkt arkitektur kan påverka lösningens kvalitet ch lämplighet för sin uppgift; för sent levererad arkitektur kan ställa till med prblem för prjektledaren att allkera resurser ch hinna leverera i tid. Användare (ch mrådesexperter) Användare ch mrådesexperter är i varje prjekt naturliga samtalspartners till lösningsarkitekten. Det är de sm besitter den detaljkunskap arkitekten behöver för att kunna åstadkmma arkitektur sm är anpassad till ch lämplig för uppgiften ch sm löser den. Junirarkitekter (Junir Slutin Architects) Junirarkitektens uppgift är att etablera intern arkitektur för en eller flera av de tjänster lösningsarkitekten har definierat. Sm redan framgått av tidigare delar av denna arkitektur måste det finnas en intim kntakt mellan en lösningsarkitekt ch de junirarkitekter sm ingår i ett prjekt. Här är några exempel på samverkanspunkter: Lösningsarkitekten knsulterar sina junirarkitekter för att åstadkmma en så tekniskt relevant arkitektur sm möjligt. Även m lösningsarkitekten (Chief Slutin Architect) i början av sin karriär sm arkitekt var rganisatinens mest framstående utvecklare blir han eller hn snart msprungen. Ju mer effektivt en arkitekt arbetar ch ju bättre resultat han eller hn åstadkmmer, i dest högre utsträckning kmmer innehållet i framtida uppdrag att röra sig m arkitektur snarare än m teknik ch prgrammering. Även m arkitekten gör sitt allra bästa för att hålla sig a jur med sina teknikmråden kmmer snart den dag då andra har sprungit ifatt ch förbi. Då är det inte så dumt att dra fördel av den större tekniknärhet junirarkitekten trde ha. Lösningsarkitekten levererar sitt resultat till junirarkitekter. Lösningsarkitekten blir sedan mentr till sina junirarkitekter ch är ständigt beredd att ställa upp ch hjälpa till. Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 13
Arkitektrller ch arkitektansvar Lösningsarkitekten övervakar ckså junirarkitekternas arbete så att det slutliga resultatet, trts att flera arkitekter varit inblandade, präglas av knceptuell integritet snarare än av varje junirarkitekts eg. Externa lösningsarkitekter Förmdligen är den typiske lösningsarkitekten inte så ensam i sin yrkesrll sm den typiske företagseller infrastrukturarkitekten. Ändå är det ng inte så tkigt m lösningsarkitekten skapar sig ett nätverk av lösningsarkitekter utanför företaget för att få igång ett givande infrmellt utbyte mellan jämlikar av infrmatin, kunskap ch erfarenhet. Lösningsarkitekter ch applikatinsarkitekter Slutligen ännu några rd m skillnaden mellan lösnings- ch applikatinsarkiteter. Först ch främst måste vi då skilja på en applikatinsrienterad ch en servicerienterad miljö. I en applikatinsrienterad miljö identifierar man ch definierar ett prblemmråde. Arkitektens uppgift blir sedan att etablera arkitektur för en sammanhållen ch tätt integrerad applikatin. En typisk applikatin består av en uppsättning användargränssnitt, ett antal kmpnenter sm ansvarar för applikatinslgiken ch i ett business system en eller flera databaser. Applikatinen kan ckså behöva integreras med andra applikatiner, någt sm applikatinsarkitekten ckså måste ta hänsyn till. Arkitektur handlar m vad sm syns på utsidan. Det sm allra tydligast bildar en applikatins utsida är användargränssnittet ch eventuella integratinsgränssnitt mt andra applikatiner. Allting annat är egentligen internt för applikatinen. Applikatinen innehåller emellertid ckså ett antal kmpnenter, sm var ch en har sin utsida i frm av vanligen bjektrienterade prgrammeringsgränssnitt. Definitin av dessa måste ckså ingå i applikatinsarkitektens ansvarsmråde, vilket ckså innebär att han eller hn måste definiera gränssnittet till de klasser sm syns för kmpnentens mgivning. I en servicerienterad miljö etableras ingen arkitektur för en sammanhållen applikatin. I stället måste lösningsarkitekten definiera ett antal tjänster (services) av lika slag. Entitetstjänster ansvarar för tillhandahållandet av data ch infrmatin; prcess- ch aktivitetstjänster utför prcessrienterat arbete; presentatinstjänster presenterar infrmatin för sina användare ch tar ckså emt ny eller ändrad infrmatin från dem. Varje tjänst har en utsida sm består av ett eller (vanligen) flera servicegränssnitt, ch det är på dem lösningsarkitekten måste kncentrera sig. När det jbbet är klart finns det en tydlig ansvarsfördelning. En viktig skillnad mt applikatinsutveckling är att ingen tjänst tillhör det system för vars räkning det ursprungligen byggde. I stället utnyttjas tjänsten av detta system, men den kan ckså utnyttjas för andra system. Kpplingen mellan system ch tjänst är i en servicerienterad miljö alltid lös tjänsten är en fullständigt självständig prgramenhet, precis sm ett knsultföretag sm erbjuder liknande tjänster till åtskilliga kunder. När lösningsarkitekten är klar med sitt arbete tar en servicearkitekt (eller, sm vi säger i den här artikeln, en junirarkitekt) vid för att etablera arkitektur för tjänstens insida. I likhet med en applikatin består en tjänst av ett antal kmpnenter, sm var ch en har sin utsida. Denna utsida syns inte utanför tjänsten, men inm tjänsten definierar den ändå en kmpnent utan att alltför mycket avslöja hur kmpnenten kmmer att implementeras. Lösningsarkitekten arbetar alltså, jämfört både med applikatinsarkitekten ch servicearkitekten på en högre abstraktinsnivå. Därför är lösningsarkitektens arbete mindre tekniskt ch mer verksamhetsrienterat än de båda andra arkitektrllernas. Verksamhetskunnande ch förståelse för verksamhetsmål, verksamhetsprblem ch strategier är egenskaper sm är viktigare hs lösningsarkitekten än för de båda andra rllerna. Nästa månads artikel Därmed är den här månadens artikel avslutad. Nästa månad handlar det m arkitektens metder ch verktyg. Jag kmmer att kncentrera mig på lösningsarkitektens situatin, ch jag kmmer att titta framåt snarare än Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 14
Arkitektrller ch arkitektansvar bakåt. Det innebär framför allt att jag kmmer att berätta mer m de designverktyg sm Visual Studi 2005 ställer till arkitektens ch designers förfgande än m UML-baserade verktyg. Referenser I II III Pat Helland, Metrplis : Envisining the Service-Oriented Enterprise Applicatins http://msdn.micrsft.cm/architecture/verview/series/ Maarten Mullender, CRUD Only When Yu Can Affrd It http://msdn.micrsft.cm/library/default.asp?url=/library/en-us/dnbda/html/crud-affrd.asp http://www.micrsft.cm/resurces/practices/default.mspx IV Design Patterns fr Scalable Micrsft.NET Applicatins Sundblad & Sundblad, Sverige. ISBN 91-974463-0-0 V Designing fr Scalability with Micrsft Windws DNA Applicatins Micrsft Press, USA. ISBN 0-7356-0728-1 VI http://www.2xsundblad.cm/se/certmsdtnetarch.aspx VII VIII http://www.micrsft.cm/sverige/msdn/architects/hall_f_fame.asp Martin Fwler, Refactring Addisn-Wesley, USA. ISBN-0-201-48567-2 IX Martin Fwler, Patterns f Enterprise Applicatin Architecture Addisn-Wesley, USA. ISBN-0-321-12742-0 X Rger Sessins, COM+ and the Battle fr the Middle Tier Jhn Wiley & Sns Inc., USA. ISBN 0-471-31717-9 XI Rger Sessins, Sftware Frtresses Addisn-Wesley, USA. ISBN-0-321-16608-6 XII http://www.bjectwatch.cm Cpyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 15