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 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 manifestet ”Working 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.




Lennart Eriksson arbetar med hälsovårdsfrågor på EU-nivå. 







