Systemet fungerar – men patienten dog

Peter Tallungs & Håkan Edvinsson onsdag 5 sep 12


EA Det pratas mycket om distansen mellan verksamheten och IT. Men det glappar också inom IT. Dags att överbrygga gapen mellan professionerna som bygger system.

På flera håll har det utvecklats ett dike mellan systemutvecklare och verksamhetsarkitekter. Ibland kan utvecklare uppleva verksamhetsarkitekter (VA) som senfärdiga och förändringsovilliga medan utvecklarna däremot sedan länge är goda mottagare av nyttiga nyheter inom Lean, Agile, Extreme Programming, med mera. Å andra sidan anser arkitekterna att utvecklarna är alltför detalj-, teknik- och lösningsintresserade.

Vi har inte råd med att hålla dessa två professioner distanserade. Vi måste sluta se till egen sak och istället ägna oss åt den gemensamma uppgiften att se till att önskade verksamhetseffekter faktiskt blir verklighet.

Det är därför vi sysslar med utveckling. Annars får vi fel lösningar som inte ger verksamhetseffekt, eller bra enskilda lösningar som tyvärr inte passar in i helheten. Det blir då lite som läkarjargongen: ”lyckad operation, patienten dog” medan de inblandade pekar skyllande på varandra.

Detta är en fristående uppföljning av tidigare EA-spaning inom ”Lean architecture”.

Många arkitekter lever ännu i en tillvaro utan tydlig koppling till verksamhetsmål. Det finns exempel där leveransprocesserna går på knäna medan arkitekturgruppen är fullt upptagen med att säkerställa att alla modeller ritas i UML.

Samma mållösa tillvaro gäller för många utvecklare: det finns exempel på att ett lyckat utvecklingsprojekt anses vara 75 procent uppfyllda krav till max 33 procent överskridna resurser, det vill säga kriterierna är blott resultat och resurser.

Båda grupperna behöver vidga perspektivet. Idag ligger fokus mellan behov och lösning. Men båda abdikerar när det gäller att ta höjd för att verksamhetseffekterna uppnås. De loggar ut efter första processfisken nedan eftersom systemet är klart och då är det dags för nästa utmaning. Det som kommer efter blir istället beställarens problem.

Olika arenor

Innan vi diskuterar ett bättre börläge så får vi klargöra varför det kan finnas ett dike mellan systemutvecklare och verksamhets¬arkitekter. Deras arena och vardag är inte lika. Några av de viktigaste skillnaderna är:

  • Systemutvecklarna är fler än arkitekterna. Istället har arkitekterna många fler olika slags kontaktytor i övriga organisationen.
  • Systemutvecklarna gör ganska tydliga leveranser, till exempel fungerande system. Arkitekternas resultat är mer otydligt: de levererar kunskap, etablerar samarbete, gör beslutsunderlag och planer samt utövar påverkan i en rad olika möten.
  • Utveckling och byggnation av system har pågått så länge att utvecklare har funnit roller, styrning och processer som liknar industriell produktutveckling och fysisk konstruktion. Arkitekterna har vanligtvis inte lika tydliga arbetsformer.
  • Arkitekter arbetar oftare med de stora dragen medan systemutveckling handlar mer om precision och att täta till även de minsta detaljsituationerna.

Olikheterna syns tydligt när de åker på (var sin) konferens för att se över sitt sätt att arbeta. När verksamhetsarkitekter vidareutvecklar sig så handlar det ofta om värderingar, inställning, generella principer, arbetsformer, motivation och kunskapsåtervinning.

Systemutvecklarnas egen förbättring handlar gärna mer om utvecklingsprocessen, ibland inkluderande metoder för affärs- och verksamhetsutformning, men ofta inte vidare än ”från verksamhetsanalys till test”. Här har Lean gjort sitt intåg liksom många utvecklingssynvinklar som den moderna historien har berikat oss med.

Både bra system och bra arkitektur krävs för rätt effekt

Om en beställare startar en utvecklingsinsats så är det i slutänden en verksamhetseffekt som önskas. Dels vill man göra saker som inte kunde göras förut, dels vill man göra saker bättre till lägre kostnad eller högre kvalitet. Verksamhetseffekt kan alltså innebära såväl innovation som optimering.

Alla inser att detta kan möjliggöras av bra systemleveranser men att det inte är målet i sig. Både systemutvecklare och verksamhetsarkitekter har sin del i att uppnå den önskade effekten. Det innebär att förbättringskonferensen bör innehålla avsnitt där de diskuterar sin egen del i effekthemtagningen.

Systemutvecklare och verksamhetsarkitekter har därmed egentligen samma mål och samma kund. Enade vi stå, söndrade vi falla.

Dessutom behöver dessa grupper tänka i vidare termer. Affärsinnovation, omorganisation, processutveckling och datainnehåll ska också finnas i åtanke. Horisonten bör sträckas ut till att ta höjd för verksamhetsförändringar: det behöver finnas ingredienser för att känna till att förändring har skett och hur det påverkat effekten, t ex prestanda, kvalitet eller kostnad.

Vår mening är att man som arkitekt eller utvecklare inte helt kan abdikera från det. Det innebär inte att ha det fulla ansvaret för förändringar men bidra till att utfallet blir det rätta. Att patienten inte dör. Alla som jobbar med utveckling jobbar faktiskt också med verksamhetsförändringar.

För att lyckas med detta krävs tre saker:

  • Att arkitekter och utvecklare måste enas om och formulera en gemensam målbild
  • Att det i den målbilden ingår att uppnå önskade verksamhetseffekter, alltså en bredare målbild än vanligtvis idag
  • Att dessa mål mäts. Systemutveckling och arkitektur mäts så gott som alltid på kostnad, prestation och ibland på resultat, men sällan på bidrag till verksamhetseffekt.

I en kommande spaning ska vi pröva att ge exempel och diskutera hur effektmål och mått kan uttryckas.

Hur är det på din arbetsplats? Står de verksamhetsinriktade och övergripande arkitekterna på en sida och systemutvecklarna på en annan med var sin uppfattning om vad som är en bra dag? Eller har ni till och med hittat gemensamma mål och mått för hur ni successivt förbättrar verksamheten?

Den som skriver en kommentar i anslutning till artiklar på trendspaning.se är själv ansvarig för innehållet. Kommentarerna omfattas inte av yttrandefrihetsgrundlagen inom utgivningsbeviset för trendspaning.se.

Redaktionen förbehåller sig rätten att ta bort kommentarer som är olämpliga i enlighet med lagen om ansvar för elektroniska anslagstavlor.

Annons från dfkompetens.se
Visualisera verksamhetens förmågor
Synliggör värdeflödet
Läs mer på dfkompetens.se
Läs mer
Annons från dfkompetens.se
IT-arkitektur – en introduktion
Läs mer på dfkompetens.se
Läs mer