Verksamhetsarkitektur(VA) och behovet av VA

En insikt efter paneldebatten är att vi deltagare talar förbi varandra. Anledningen är att vi har olika definitioner av vad en arkitekt är och att vi har olika problembilder som vi vill lösa.

Rollen som jag företräder här i detta inlägg heter verksamhetsarkitekt och området heter verksamhetsarkitektur(VA). Jag vill ge ett exempel på ett problem som är lagom komplext men som visar på behovet av VA. Nedan finns en skiss över Scrum-teamens ansvar:

3 team med totalt 20 personer

3 Scrum-team med totalt 20 personer

Utvecklingsarbetet är uppdelat i tre olika oberoende Scrum-team som samarbetar eftersom det anses vara det mest effektiva i den aktuella situationen. Om alla 20 skulle arbeta i samma team blir resultatet sämre. Uppdelningen i team leder i sin tur till problem som redovisas längre ner.

Kund – teamet utvecklar ett CRM-system som fokuserar på kunder, många länder, många marknader, komplicerade kundorganisationer med dotterbolag, marknadsbolag och internationella koncernbolag med personal med olika roller.

Produkt – teamet utvecklar ett produkt och konfigurationssystem med många olika produkter som består av komponenter, där produkterna kan sättas samman i sammansatta produkter och där man ute vid sälj- och leveransprojekt önskar få hjälp med vilka komponenter som fungerar i vilka produkter och i olika versioner.

Installerade produkter – teamet utvecklar ett system som har som mål att hålla reda vilka produkter i vilka konfigurationer har installerats hos vilka kunder och på vilka platser. Man vill kunna svara på frågor som:  Vilka avtal finns och vad avser de? Vilka tjänster, garantier och service ingår? Vem är kontaktpersonerna hos det egna företaget och hos kunderna?

I verksamhetsarkitekturen beskrivs i enkla modeller och innehåller övergripande processbeskrivningar, informationsmodeller, existerande system och gemensamma tjänster enligt SOA. Det finns också matriser som visar existerande beroenden mellan processer, informationsobjekt, system och SOA-tjänster.

Verksamhetsarkitekturens modeller ligger lagrat gemensamt och tillgängligt för att alla teamen skall ha tillgång till en gemensam bild på helhetsnivån. Avsikten är att modellerna skall underhållas ute i de olika teamen och att ändringar av gemensamma modeller skall ske kontrollerat och därefter spridas.

Problem: De olika teamen har olika syn

Det finns i exemplet tydliga beroenden mellan teamen men trots att man utsett en ansvarig för modellerna och möts i gemensamma möten enligt federativ modell så kan man inte enas. Produkt och Kundteamen tycker inte att det är viktigt att uppdatera de gemensamma modellerna. ”Installerade produkter”-teamet anser att det är viktigt. De är också i högsta grad beroende av de andras modeller.

Min fråga till agilisterna: Vad gör man?

Vad gör man om man är renlärig agilist (förespråkare av Agile Manifesto) om man är beroende av varandras modeller mellan teamen men ett eller flera team prioriterar kortsiktigt och man efter samtal inte kan påverka de andra teamen att ändra sig? Samlar man produktägarna? Eller beställaren? Eller bidar man sin tid till fler blir medvetna/mogna och inser problemet och vill lösa det?

Mitt förslag på lösning: Verksamhetsarkitektens arbete och ansvar

En utsedd ansvarig verksamhetsarkitekt eller en styrgrupp går in med mandat och anger ramarna för hur viktiga modellerna är och hur de skall underhållas av teamen. Teamen anpassar sig till dessa ramar. De gör fortfarande inte lika (vilket är tillåtet), men de håller sig inom de uppsatta ramarna, om inte så måste någon styra upp det hela efter sitt mandat. Det finns ett motsatt problem när teamen arbetar för mycket med sina modeller. Det är inte heller tillåtet.

Problem med Agile-synen

Agilisterna(förespråkare av Agile Manifesto) saknar lösning på problemet ovan om de inte accepterar någon som har mandat att styra när teamen har olika åsikter och inte kan påverkas. Agilisterna gillar oftast inte heller det faktum att teamen måste uppdatera de centrala modellerna. Anledningen är att modeller inte är fungerande programvara som är det enda resultat som verkar räknas inom Agile, eller som det står i manifestetWorking software over comprehensive documentation”. Egentligen är källkoden också slags en modell, ett perspektiv över systemet. Fast det har man ofta inte tänkt på.

Lösning: Vidareutveckla Scrum/Agile

Min åsikt är att agilisterna är alltför begränsade i sin problemdefinition. Deras nuvarande arbetssätt fungerar bara i mindre sammanhang i små företag eller för arkitektur inom en lösning.

Det bör vi ändra på. Det kan lösas om vi vidareutvecklar Scrum/Agile-rollerna och tillåter modeller som resultat och använder redan etablerade och fungerande sätt att snabbt ta fram dessa modeller.

Modellerna får inte ta för mycket tid

Modellerna får inte ta mer än max 2 månader att ta fram initialt och de finns sedan gemensamt tillgängliga. Specialister(verksamhetsarkitekter) och inte teamen är ansvariga för att det finns modeller att utgå ifrån. De första modellerna tas fram i seminarieform av erfarna seminariehandledare tillsammans med sakkunniga från verksamheten.

Teamens ansvarar för återkoppling

Teamen är ansvariga för att underhålla och uppdatera modellerna mer eller mindre kontinuerligt och att bevaka och anpassa sig och införa förändringar i de gemensamma modellerna som berör teamets ansvarsområde.

Lösningen ovan finns nästan i verkligheten också

Lösningen ovan är inspirerad av ett företag i telekombranschen. Mandatet att ge riktlinjer, granska och styra projekten är i den organisationen delegerat till en grupp, ett forum (Information Model Architect Forum). På det företaget har man inte anammat Agile/Scrum än annat inom små projekt inom teknisk produktutveckling.

Vinster med verksamhetsarkitektur(VA)

Företag som har ordning och reda på sin verksamhetsarkitektur kan tjäna mycket på det eftersom det ger klarhet och tydlighet. IT-systemen förbättras. Ledningen får bättre kontroll, även på kostnaderna. Kvaliteten höjs. Systemlösningarna kan bli mer flexibla och beslutsunderlagen för ledningen kan förbättras inför stora förändringar som inför uppköp och sammanslagningar.

Debatt ”Agile vs Architecture”

IASA

Denna vecka satt jag med i en debatt, en frukostpanel kring ämnet ”Agile vs Architecture” tillsammans med några av de mest kunniga på området i Stockholm: Peter Tallungs, Henrik Kniberg, Joakim Holm, Lennart Eriksson, Tomas Karlsson och Martin Völker på inbjudan av IASA, AgileSweden och DSDM. Moderator var Daniel Akenine, Microsoft, ordf i IASA. Han har skrivit om det på sin blog. Man kan även lyssna till debatten på mp3.AgileSweden

Det blev nästan ingen debatt. Alla var i stort sett eniga och i praktiken förespråkare för agilt arbetssätt i team. Alla menade att agilt arbetssätt inom systemutveckling förutsätter en arkitektur. Det som skiljer är vilket problem man sitter i dagligen och därmed fokuserar på att lösa. För en del räcker det med en skiss. För andra krävs det mycket arbete för att ta fram olika modeller som tillsammans utgör en arkitektur.

Peter TallungsLennart Eriksson arbetar med hälsovårdsfrågor på EU-nivå. Joakim Holm arbetar på en stor bank med att utveckla arbetssättet och införa teamarbete för att leverera bättre systemlösningar med högre kvalitet. Peter Tallungs(på bild till höger) vill samordna alla projekt och initiativ på ett kortföretag för att på sikt få fram bättre beslutsstöd. För lösningsarkitektur räcker det ibland med en skiss på en gemensam tavla. På EU-nivå krävs det många månaders eller års arbete för att förändra det gemensamma regelverket och arkitekturen så att lösningarna kan fungera tillsammans i många länder. På kortföretaget är de existerande lösningarna så komplicerade och sambanden med externa partners i nätverket så omfattande att det krävs modellframtagning i månader för att överhuvudtaget förstå och kunna få fram goda arkitektur-modeller.

Det finns också många dåliga exempel. Det är ett problem. Arkitekter som inte bidrar med nytta utan bara hindrar. Agila team som inte vill se helheten utan bara levererar kortsiktiga lösningar som inte förstått den bakomliggande innebörden av det agila manifestet. Vi kan inte låta de dåliga exemplen och avarterna hindra utvecklingen mot den enda möjliga lösningen nämligen en framtid där både arkitektur och agilt arbetssätt kombineras.

Arkitekterna av de gamla skrået kan lära mycket från den agila kulturen och principerna. Agilt arbetande utvecklare kan lära sig av arkitekternas fokus på helheten och lära sig att förstå arkitekternas modeller och se dem som krav. Inte som krav som är skrivna i sten utan krav som i dialog kan modifieras i processen för att realisera visionen.

Jag intresserar mig mest för arkitekturfrågor på medelstora företag/koncerner. Hur skall man undvika att projektens resultat leder till suboptimering på helhetsnivå? Det blir lätt flera nya databaser och flera nya applikationer för varje nytt projekt. Även om applikationen/standardsystemet fungerar bra enskilt så blir det problem eftersom antalet databaser och applikationer ökar hela tiden. Återanvändningen av information är ofta liten. Dubbellagringen är enorm. Allt detta skall sedan underhållas till höga kostnader. Ofta får användarna sitta emellan och lov att själv uppdatera i många system till höga kostnader. Integration används ibland som lösning men kostnaderna skenar och flexibiliteten blir låg. Det säger sig självt att det blir kostsamt, till slut även för kunderna eller ägarna.

Det krävs stora krafter och starkt ledarskap för att styra och hålla emot en sådan utveckling. Projektkulturen är i sin natur kortsiktig. De agilt arbetande projekten likaså, men det finns erfarenheter också där man lyckas inom några företag. De är ofta vinnare i en global konkurrens där IT-system är ”verksamheten”.  Verksamhetsarkitektur(VA) eller Business Architecture(BA) är initiativ för att få kontroll och förståelse för helhetsperspektivet.

Beslutsfattarna får med VA/BA bättre underlag och därmed blir det bättre beslut med högre kvalitet. I Scrum kan produktägaren eller rättare sagt hans produktägarteam använda VA/BA-modeller för att både styra och kommunicera med teamet av utvecklare.

Jag arbetar med att utveckla och paketera en ny modifierad produktägarroll tillsammans med många i AgileSweden-nätverket och kombinera det bästa ur agilt arbetssätt och arkitektur. Du är välkommen att vara med och bidra om du är intresserad.

Nytt koncept: Tastecasting.se

TasteCasting.se

Ett nytt sätt för arrangörer att nå ut i sociala nätverk heter Tastecasting.se. Det verkar vara ett kul koncept. Man blir inbjuden att testa olika restauranger, barer och dylikt gratis.

Träffade och talade med Agnieszka Baltyn, en av grundarna, igår på en provsmakning på ett företag som heter Bar-Deli. Jag blev nyfiken, både på Bar-Deli, som gör nya snacks och mat för hotell och restauranger och på konceptet. Idag gick jag med. Återkommer med recensioner senare.

Det känns som om det finns bara två sorters konjunkturer, högkonjunktur och ny-konjunktur. Nu är det verkligen Ny-konjunktur…