Nyligen bloggade Tom Graves om att vi borde dumpa den så kallade bdat-stacken (”business, data, applications, technology”). Huvudargumentet är att den uppdelningen är alldeles för it-centrerad: tre lager handlar om it och bara ett om affären, och i det lagret ska alltså allt som inte är it få plats. Han menar också att stacken bara fungerar i ena riktningen, nerifrån och upp. Allt börjar med it-infrastruktur (som är fokus – basen), sedan data, som är den information som it-infrastrukturen underhåller, applikationer som körs på it-infrastrukturen, och sist all icke-it som påverkas av it. Han är tydlig med att det inte går att vända på stacken och tänka tvärtom.

Läs också: Stockholm har Europas bästa it-chef

Jag har nyligen också läst en (ännu ej publicerad) akademisk artikel som handlar om att eam, enterprise architecture management, också behöver definieras om. Istället för att fokusera på arkitekturen, som Graves, handlar det om hur arkitekturen hanteras. Där finns, precis som i bdat-fallet, också en av industri och akademi accepterad och vedertagen konceptuell modell. Nämligen: 1) modellera din nuvarande arkitektur, 2) modellera din framtida arkitektur, 3) ta fram en plan för att gå från ett till två, och 4) genomför planen. Problemet, enligt författaren, är att nästan ingen lyckas med någon ea-satsning genom att följa denna modell. Och ea lider av detta.

(Författarens förslag på lösning kan jag tyvärr inte gå in på här då artikeln inte är publicerad ännu, men den innehåller egentligen inget revolutionerande.)

Det första som slår mig är att varken Tom Graves eller akademikern i fråga har fel i sina åsikter, och särskilt i den akademiska artikeln underbyggs de väldigt väl. Samtidigt tycker jag inte heller att de har rätt. Det stora problemet är för mig väldigt akademiskt, det vill säga hur vi i studier väljer att definiera ea eller eam, snarare än hur industrin bör använda dessa. Jag tar för givet att industrin använder sunt förnuft och anpassar stack och modell efter behov. Jag ser inget fel i att baka ihop data-applikation-teknologi till ett it-lager och vända på stacken, så att affärslagret blir bas i en tvådelad stack. Om det fattas något i affärslagret, lägg till det. Om något känns överflödigt, ta bort det. Om något behöver flyttas eller döpas om, gör det. Det är ni själva som bestämmer över er arkitektur och hur den ska definieras. I eam-fallet kan man till exempel välja att inte modellera sin arkitektur för hela företaget på en gång, utan kanske istället modellera för en avdelning, en process, ett projekt, eller något annat mer avgränsat. Då kanske man missar en del aspekter, men i gengäld tror jag att man faktiskt kommer i mål och kan visa på nytta av det som gjorts.

Läs också: Digitaliseringen slår sönder företagens organisation – så får du med alla på tåget

Min poäng är på sätt och vis att argumentera mot Tom Graves: praktiker ska inte ta allt så bokstavligt – lämna det åt forskarna att grotta ner sig i begrepp och definitioner, som sedan gott kan anpassas efter behov.