SOA – Hierarki eller organisk vækst?

English version: http://www.tigerteam.dk/2014/soa-hierarchy-or-organic-growth/

Der er en interessant udvikling i gang indenfor SOA og den kommer fra en uventet kant.

Jeg har arbejdet med SOA (et fantastisk akronym som reelt intet siger) i over 10 år og har igennem min tid set virksomheder bygge mere og mere hierarki og struktur på deres SOA landskab for på den måde at opnå “forretnings agilitet gennem forretning og it alignment og øget genbrug”. Hvis du får tendens til reflux ved at høre den sætning føler jeg med dig.

Ideen og intentionen er god nok, men udførelsen er til -3 (på den nye 7 trins skala). I stedet for at have opnået agilitet gennem løst koblede services, er man istedet endt op med hårdt koblede services, en dyr og organisatorisk tung Enterprise Service Bus (ESB), der centralt skal koordinere de hundrede til tusinde services man har fået opbygget. Det svarer lidt til at hyrde får med en kummefryser og et reb bundet til hvert får.

Det er rodet og ustabilt. Ikke ustabilt som i at ESB’en er ustabil, men ustabilt som i at man med vold og magt forsøger at skabe orden i kaos uden at forstå virkningsmekanismerne.

Hverdagen i enhver større virksomhed  byder på et rivende strøm af nye service kontrakter, ændringer til eksisterende service kontrakter. Nye systemer som bliver indkøbt, systemer bliver bygget for at erstatte gamle systemer (med det resultat at man nu har 1 ekstra nyt system udover det gamle system der ender med stadig at være i drift). Væksten er organisk, men måden vi håndterer den på er ved at indføre mere hierarki, bureaukrati og koordinering. Her er det naturens kræfter der styrer og som bekendt bliver man våd hvis man vælger at tisse mod vinden.

Så hvad gør man typisk for at komme denne uorden til livs? Man hyrer Enterprise Arkitekter der kan tegne stiliserede diagrammer over hvordan organisationen og systemerne burde se ud. Man hyrer data arkitekter der kan tegne kanoniske modeller for hele forretningen i et håb om at vi har tid og råd til at sikre at alle har samme opfattelse af et begreb som f.eks. kunde. Det meste af det er spild af penge og tid.

Vi laver en central organisatorisk enhed der skal stå for at betvinge ESB’en og som på heroisk vis skal sikre at services kan snakke sammen og nye integrationer kan blive bygget. Vi har indsat en mellemmand der på bedste vis skal magte at forstå forretningen, service aftageren og service tilbyderens behov og krav. Der er meget at forvente af en mellemmand, som blot helst vil sælge… jeg mener levere.

Al magten kan meget nemt ende med at ligge hos ESB gruppen og dermed danne en organisatorisk og projekt mæssig flaskehals. Det er her ansvaret/ansvarsfriskrivelsen ligger, og det er her, at vi lige så stille ender med at flytte større og større dele af vores forretnings logik ind i form af orkestreringer. Lige så stille ender vores services med at blive degraderet til CRUD (Create/Read/Update/Delete) Data Services.

Men det kan vel ikke være dårligt? Vi opnår jo en høj grad af genbrug af (data) services og der var jo derfor vi ville have SOA ikke?
Hvor mange kan nikke genkendende til nedestående SOA (arkitektur) billede?

Hvad nu hvis vi tegnede samme ansvarsfordeling på denne måde?

I min verden opnår begge løsninger det samme med omtrent samme højre grad af data/logik kobling. SOA løsningen har en anelse svagere teknisk kobling, men til gengæld er performance og transaktions håndtering noget der fordyrer og gør SOA løsningen langt mere teknisk kompliceret. Vi har reelt erstattet databasens transaktions håndtering og tabel joining funktionalitet med SOAP, XML og HTTP. Og nej, løsningen er ikke at gøre databasen til en central spiller igen. Hele problemet er blevet vendt på hovedet og der findes meget bedre løsninger.

Hvem var det der fik ideen til at den lagdelte SOA skulle være best practice, når den nu bidrager med høj kobling (både datamæssigt og temporalt), høj latenstid og tung teknisk bagage for at håndtere opdateringer af flere autonome services?

I næste blog post vil jeg dykke mere ned i problemerne med lagdelt SOA, den centrale ESB og hvordan er anderledes syn på design og opsplitning kan hjælpe. Men hvad med den interessante udvikling er og hvor den kommer fra? Det kommer vi også til at kigge nærmere på sidst i næste blogpost.
🙂