Av
Att ta Maslows behovshierarki och översätta den till affärstermer är en, i olika situationer, mer eller mindre lämplig analogi och inte heller ett helt ovanligt grepp. När det gäller verksamhetsarkitektur har jag dock bara sett det beskrivas som ett sätt att ta sig upp i hierarkin, exempelvis som det beskrivs av Andy Blumenthal i detta bloginlägg. Jag tror Andy har rätt i att EA kan hjälpa till i detta arbete och att det är så man borde använda verksamhetsarkitektur. Samtidigt tror jag att verksamhetsarkitekturen som sådan ligger en bra bit upp i en organisations behovstrappa, det är först när man är en relativt mogen verksamhet som man har motivationen att skapa arkitekturen. Så länge större delen av tiden går åt till brandsläckning, inom affärsverksamheten såväl som IT, är det svårare att tänka i termer av arkitektur.
Om det fungerar på det sättet blir resultatet att verksamhetsarkitekturen bara används för att trimma in den allra sista delen av en organisations effektivitet. Det är synd då den i grunden kunde använts till så mycket mer, inklusive att helt undvika de bränder som hindrade skapandet av arkitekturen. En invändning mot detta resonemang skulle kunna vara att motsvarande gäller för alla former av strategi och att strategier i olika former behövs redan i de tidigare faserna av en organisations livscykel. Som jag ser det är skillnaden att den typ av strategi en verksamhetsarkitektur utgör ofta är så arbetsintensiv att skapa, framförallt sett till datainsamlingskostnaden.
Har man detta i åtanke kan man istället använda det som ett underlag för att skapa sin arkitektur. Om man är det mer mogna företaget som vill använda EA för att just trimma in den allra sista effektiviteten kanske det är möjligt att vara mer ambitiös i sin ansats. Är man istället ett mindre moget företag ska man vara väldigt noggrann med att inte ta sig an allt för mycket initialt, till det kommer aldrig motivationen att räcka. I det senare fallet kanske man ska nöja sig med att formulera några korta principer som kan hjälpa i det dagliga beslutsfattandet. Dessa principer i sin tur kanske gör att man slipper släcka bränder och kan få motivationen till att skapa den mer ambitiösa arkitekturen.
Om det fungerar på det sättet blir resultatet att verksamhetsarkitekturen bara används för att trimma in den allra sista delen av en organisations effektivitet. Det är synd då den i grunden kunde använts till så mycket mer, inklusive att helt undvika de bränder som hindrade skapandet av arkitekturen. En invändning mot detta resonemang skulle kunna vara att motsvarande gäller för alla former av strategi och att strategier i olika former behövs redan i de tidigare faserna av en organisations livscykel. Som jag ser det är skillnaden att den typ av strategi en verksamhetsarkitektur utgör ofta är så arbetsintensiv att skapa, framförallt sett till datainsamlingskostnaden.
Har man detta i åtanke kan man istället använda det som ett underlag för att skapa sin arkitektur. Om man är det mer mogna företaget som vill använda EA för att just trimma in den allra sista effektiviteten kanske det är möjligt att vara mer ambitiös i sin ansats. Är man istället ett mindre moget företag ska man vara väldigt noggrann med att inte ta sig an allt för mycket initialt, till det kommer aldrig motivationen att räcka. I det senare fallet kanske man ska nöja sig med att formulera några korta principer som kan hjälpa i det dagliga beslutsfattandet. Dessa principer i sin tur kanske gör att man slipper släcka bränder och kan få motivationen till att skapa den mer ambitiösa arkitekturen.
Den här artikeln har 0 kommentarer:
Freddie Larsson, CIO, Xdin:
Håll koll med våra
I IDG:s stora pdf-shop kan du köpa artiklar och hela tidningar i digitalt format.