SOA – Hierarki eller organisk vækst?

Flattr this!

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.

Hyrdning af får med en ESB kummefryser og et reb bundet til hvert får

Hyrdning af får med en ESB 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?

Lagdelt SOA ("best practice")

Lagdelt SOA (“best practice”)

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

Lagdelt med database

Lagdelt med database

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.
🙂

Share Button
The following two tabs change content below.
Profile photo of Jeppe Cramon

Jeppe Cramon

Partner/Arkitekt/Udvikler af TigerTeam ApS
Partner i TigerTeam. Erfaren software arkitekt/udvikler.

8 kommentarer for “SOA – Hierarki eller organisk vækst?

  1. 24. januar 2014 at 12:35

    “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?”

    Jeg tror man glemte “autonome” i den sammehæng… 🙂

  2. 24. januar 2014 at 21:58

    På en eller anden måde ringer det en klokke. Og jeg synes de to diagrammer indeholder et enormt fint “twist” til historien.

    Jeg har på et eller andet plan været ude af enterprise software siden 2010 og jeg havde egentlig bildt mig selv ind at dem der sagde at “SOA is dead” endte med at få ret deromkring og selve den kanoniske hovedet-under-armen tilgang til SOA som “det skal vi selvfølgelig ha'” var forsvundet. I bedste fald var det en god inspiration til genbrug og Law of Demeter agtige synsvinkler på arkitektur etc. En form for tankegods der giver input når man tænker sig om – f.eks. tanker som “microservices” https://www.youtube.com/watch?v=2rKEveL55TY og http://yobriefca.se/blog/2013/04/29/micro-service-architecture/

  3. Profile photo of Jeppe Cramon
    25. januar 2014 at 10:41

    Min erfaring, fra egne oplevelser og fra kollegaer, er at lagdelt SOA og hierarki er endnu mere i fokus i de store virksomheder for tiden, omend jeg også ser tegn på at flere og flere er ved at indse at den nuværende tilgang ikke holder. Vi mangler stadig at få ledelsen til at indse det, men det er bare meget svært når de nu har brugt så mange penge på at indkøbe ESB’ere, opbygge afdelinger, uddanne, etc.
    Microservices er rigtig interessante (og hypede) og er noget jeg kommer ind på i de følgende blog post.

    • 26. januar 2014 at 15:27

      Venter spændt på post (s) om Micro-Services. Umiddelbart lyder det fra Fred George næsten for godt til at være sandt, så jeg drømmer om at komme i nærheden af noget der er mere konkret. Kode f. eks. 🙂

  4. Profile photo of Kristjan Wager
    25. januar 2014 at 14:41

    Interessant indlæg. Jeg støder sjældent ind i begrebet SOA disse dage, men jeg ser ofte arkitektur som er baseret på de tanker som danner grundlag for SOA, så på det plan render jeg ind i SOA.

    Problemet med SOA var vel i virkligheden at mange folk troede at det stod for “Servicebus Oriented Architecture”.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *