SOA, POLPOT og BOB’s

En af de helt karakteristiske ting ved SOA er, at det er en arkitektur/begreb der er så simpelt, at det er – næsten – helt umuligt at forklare. Da jeg er autodidakt i helt-umulig-kommunikation vil jeg vove forsøget efter KISS princippet. Man behøver ikke anvende et højt lixtal bare for at lyde dum …. “Make everything as simple as possible, but not any simpler”, Albert Einstein.     

Dette indlæg tjener til inspiration og eftertanke ifbm SOA og IT iøvrigt.     

Nogle spørgsmål, der måske trænger sig på ….     

  • Er der noget nyt i SOA ?     Næ …
  • Har man hørt salgsbudskaberne tidligere med andre arkitekturer og teknologier ? Ja, i høj grad.
  • Giver SOA nogen mening for en kun del af virksomheden ?   Næ …. Fordelen ligger ofte i stordrift (komponentbaseret udvikling fordrer genbrug)
  • Giver SOA mening for mindre virksomheder ? måske ikke …. værktøjer til stordrift er dyre. TCO (Total Cost of Ownership) under pres.
  • Giver SOA mening for mindre virksomheder som leverer IT baseret services til andre ? ja, i høj grad.
  • Vil man med succes kunne indføre SOA uden hensyntagen til brugerhåndtering a.k.a IDM/IAM (Identity/Access Management)? Ja, men udbyttet bliver begrænset på sigt. Ikke at medtage overvejelser mht brugerstyring vil ramme én med grusom styrke senere. MEN IDM integration kan være meget bekosteligt alene.
  • Er SOA ikke bare en IT teknisk videreførsel af princippet bag Legoklodsen? Jo!
  • Er SOA en god ide ? Ja, i høj grad. Magten tilbage til virksomheden og medarbejderne … hvis de får lov (jvf. POLPOT)
  • Er omkostningstyngden ligesom de-gode-gamle-CASE værktøjer ?  Ja, investeringerne er store i starten, men så kommer gevinsten også (Er det déjà vu  eller clair voyance?)
  • Kan man indføre SOA uden fuld opbakning (prokura og økonomisk råderum til SOAP-team) fra ledelsen ? Aldrig.
  • Kan man indføre SOA uden at flytte ansvar ? Aldrig.

Det var der vist ligeså mange spørgsmål som svar i. Meget kendetegnende for emnet mærker man den blide brise fra varmluftkanonerne(marketing)….     

Hvorfor SOA ?     

Hvis man går et par hundrede år tilbage(tidsmæssigt omkring brug af kugleramme) og ser på de første motivationer for Computeren(Beregneren), lå fordelen I, at den var i stand til at beregne ting, som mennesker næppe kunne gøre indenfor en livstid ; At trække viden ud af data (ofte store datamængder). Selve arkitekturen i computerer har stort set ikke ændret sig – de er blot blevet i stand til større og større ydeevne til mindre og mindre pris. Den mindre pris gjorde så, at PC’en blev en værdig afløser for skrivemaskinen (ETB) især mht arkivering. Næste skridt var så automatisering af manuelle processer. Varelager, regnskab, statistik ja mulighederne var uendelige. Egenudviklede systemer så nu dagens lys i hidtil usete mængder. De tog en evighed at udvikle, men de passede præcis ind og afbilledede virksomhedens måde at drive forretning på. Det var for såvidt også fint i mange år. Produkterne var i centrum og time-to-market var lang. Det er ikke tilfældet længere, hvor forandringsmulighed og forandringsvillighed er blevet meget vigtigt. Hvad gør konkurrenten? Hvad gør vi ved at konkurrenten gør som de gør ? For en offentlig virksomhed kunne kravet været styret af lovgivning eks. beregningsgrundlag for en tilskudsordning.  Systemerne er nød til at blive ændret – ikke opdateret – men ændret! Det tager tid. Her er den eksisterende teknologi har haft det lidt svært. Det har aldrig været let at følge med ændringer i samme tempo som forretningen(IT gap). Summen af kardemommen er, at forretningen ændrer sig hurtigere end man kan nå at ændre sin forretningssoftware. Hvordan kan et princip baseret på Lego-klodser være så svært at implementere? Man har tidligere med vekslende held forsøgt sig med komponentbaseret udvikling – CORBA, DCOM, RMI/EJB, JavaBeans etc … Planen var egentlig den samme, men det viste sig, at disse teknologier og frameworks ikke rigtigt slog til. Masterplanen var business agility/flexibility/interoperability/ maintainability/scalability… det var bare svært i praksis. Men nu tror jeg teknologien er her. Der er dog nogle hensyn af ikke teknologisk art som kan spænde ben (som altid).     

Uanset hvordan man vender og drejer det ønsker man (se figur):
IT skal nemt kunne implementere processer
IT skal nemt kunne ændres hurtigt     

Agility er tidsreduktion mellem processændringer

Agility er tidsreduktion mellem processændringer

Mindst er tre CSF’er være opfyldt/adresseret (“Critical Success Factors” fra de gode gamle Business Process Reenginering(BPR) dage)     

Vi har en P.O.T situaze:     

People – mennesker hader forandring.
Især hvis de ikke selv har bedt om forandringer, ikke forstår dem eller bliver usikre på deres betydning for dem. De kan udvise mere eller mindre civil ulydighed på alle niveauer. Det har altid været vigtigt at “sælge” beslutninger herunder budskaber ifbm indførelse af “ny” teknologi. Nogle firmaer gør sig meget umage med information, andre påkalder sig Amnesty International’s opmærksomhed 😉     

Organisation – applikationssiloer skal nedbrydes/udjævnes.
Integrationsgevinsten sorterer herunder. I en større virksomhed kan der eksistere meget ens systemer fordelt over flere LOB (Lines Of Businesses). Disse systemer er tunge at vedligeholde og/eller er i bedste fald tæt koblet i form af megen kode – dvs kode der forretningsmæssigt tager langt tid at ændre. På toppen af alle disse siloer skal man placerer en beslutningsstærk enhed af arkitekter/folk for forretningen. De skal have den fornødne prokura til at lave nogle gange radikale ændringer på tværs af LOB’s – en hurtigindsatsstyrke, et SOAP team. Igen kan mennesker – her de ansvarlige for siloerne – komme i klemme, idet ansvaret flyttes. Her rammer “People” dobbelt.     

Technology – teknologien skal kunne implementere/sikre løst koblet systemer, infrastruktur med QoS (Quality of Service ex. sikkerhed, pålidelighed… )     

Det er her SOA og ikke mindst SOA produkter såsom Oracle SOA Suite (BPEL, Mediator, Business Rules, Workflow/Human task), Oracle Service Bus, Oracle Business2Business Suite, Oracle Enterprise Repository, Oracle Service Registry, Oracle Business Activity Monitoring, Oracle WebService Manager, Oracle Enterprise manager, Oracle Business Transaction Monitoring, Oracle Grid Control og loads af technology JEE JCA Adapter’s. Dertil kommer Oracle Web Center Suite herunder Oracle Application Development Framework(ADF) på UI-siden og en palette af IDM/IAM komponenter i Oracle Identity Management Suite.     

Det kan nok være, at hele eller dele stakken kommer til at koste lidt, men teknologien er klar!     

Den sidste faktor, og nok værste forhindring, kommer fra afdelingen for ufatteligt ødelæggende opførsel på tværs af LOB’s. En ofte usynlig variant af “People” nemlig politik. Det kan være meget svært at adressere denne muterbare faktor, men udspringer ofte af vigende ledelse og dårlig information om det fælles mål – vi taler da om “The Queen Mother of POT” : POLPOT.
Derfor INDEN man starter rejsen mod SOA’s forjættede land af forandringsparathed bør man minimum have taget stilling til ovenstående! Man vil sikkert (igen) indse at P+O er og bliver den største udfordring overhovedet …. de færreste vil blot indrømme det.     

Man må også holde sig for øje hvad den ikke-sagte motivation er for transformeringen. Uanset hvad man kommer frem til vil følgende udsagn kunne helt eller delvis være sande. De har altid været en del af den skjulte agenda:     

  • Vi gør det fordi de samme mennesker skal kunne lave mere på den samme tid?
  • Vi gør det fordi de samme mennesker skal give kunder/borgere bedre service?
  • Vi gør det fordi vi vil spare penge på services – afskedige folk eller outsourcing?
  • Vi gør fordi de samme mennesker skal fritages for meningsløst arbejde, så de kan lave noget andet som giver mere værdi for forretningen?

Der kan nævnes langt flere over samme læst – nogle mere sympatiske end andre. Fælles for dem er, at medarbejdere har ret til at vide besked!
Lad os antage, at ovenstående er på plads og den egentlige forretningsudvikling kan påbegynde.     

Hvor starter man?
Jeg ser 2 metoder som ikke er gensidigt udelukker hinanden eller for den sag rækkefølgen, men bør bruges sammen:     

Den første tager udgangspunkt i medarbejderne, den anden tager de eksisterende systemer i ed:     

  1. Måske lidt overraskende vil jeg starte med information og uddannelse af de aktive aktører. ALLE medarbejdere skal stille skarpt på “tankesættet” og ikke mindst ledelsen skal især skal kende betydningen/konsekvenserne af beslutningen.  Beslutningsansvar skal flyttes (SOA Team) og the chain-of-command skal gøres kort! Agility i alle led.
  2. Lav et “Process improvement system” efter KISS princippet (ex. WordPress blog application). Et system, hvor ALLE medarbejdere NEMT kan rapportere forslag til forbedringer af forretningsprocesser.  Alt skal adresseres, vurderes af et SOAP team og ikke mindst kommenteres. En fremragende mulighed for at få diskuteret forretningen igennem og evaluere på eksisterende systemers formåen. Systemet tjener som motionering af alle led i forretningen – nogle gange som gigtmedicin.
  3. Ovenstående system skal også have en ANONYM “stikkerlinie”, hvor brokkerøvene kan udfolde sig bramfrit jvf. (http://ing.dk/artikel/76859-pas-paa-rygklapperen-dyrk-brokkeroeven). Tjener som antiinflammatorisk blokade, når beslutningstagere laver flyverskjul istedet for at handle. Round-the-table-talks kan ligeledes være en mulighed, men har begrænset virkning.

Bevæggrundene for de 2 sidste punkter er, at ALLE virksomheder har en eller flere BOB’s, som gør tilværelsen sværere for mange medarbejdere. BOB’s er processer af typen “Business Obstructive Behaviour”. Det vil sige processer, der er åbenlyst torskedumme, fungere forfærdeligt og/eller mange lider voldsomt under dem. De er karakteriseret ved at være det diametrale modsætning til “Business Agility”, koster enorme summer, men som ingen rigtigt ønsker/tør at måle på eller anskueliggøre konsekvenserne af dem. De er multiresistente af natur (mere i en senere bloog).
Mange af dem udspringer af kontroller, hvor den eneste forretningsmæssige bevæggrund er, at nogle har snydt dvs alle skal straffes. Andre udspringer af et tidsmæssigt perspektiv, som ikke længere er opfyldt, hvilket har tilskrevet BOB’en en deskruktivt karakter, som dræber frit initiativ og innovation. Endnu flere skyldes blot mangelfuld implementering, som følge af økonomiske, politiske eller tekniske årsager, der  udspringer af mangelfuld viden. Ofte er det virksomheder, som tilbeder innovation, som har flest BOB’s – skrevne som uskrevne. ALLE har BOB’s!
Er en BOB kundevendt bliver den skadelige virkning mangedoblet, da den sår kimen til illoyalitet, som er ren gift for virksomheden.     

Et lille eksempel er fra en teleudbyder et sted på planeten. Efter at have erhvervet en mobil skulle jeg via en “Selvbetjenings-webside” registrere automatisk betaling via PBS. Efter endeligt at have bemægtiget mig adgang til systemet, skal jeg indtaste betalingsoplysninger. Siden beder om et “aftalenummer”. Hjælpesystemet beskriver, at aftalenummeret skal fremgå af girokortet. Problemet er bare, at der ikke findes noget girokort kun et betalingsid og fakturanummer på den elektroniske betaling af telefonen via websiden. DERFOR er jeg nødsaget til at ringe til teleudbyderen. Jeg får oplyst mit aftalenummer og ser, at det er del af fakturanummeret. Det oplyser jeg til deres telefonservice og forespørger om de ikke kan tilføje denne information i deres hjælpesystem. Jeg møder en mur af tavsheds og modviljen er stor mod at påtage sig denne opgave. Hvorfor ved jeg ikke, men konsekvensen er, at tusindevis af “Selvbetjeningskunder” på skift kontakter teleudbyderen for denne info, som jo er dyrt for alle.
Løsninger til de værste BOB’s optræder ofte i kategorien “no-brainer”.     

En anden metode er den mest brugte og tager udgangspunkt i en teknisk systemgennemgang:     

For mange kan det virke som en uoverskuelig process at dokumenterer eksisterende processer, datagrundlag og grænseflader. Større virksomheder har heterogene miljøer, som langt fra alle – om nogen overhovedet – kender værdien af (“Rat’s nest” jvf. “Service Orient or be doomed”, Jason Bloomberg og Ronald Schmelzer). Men man skal jo starte et sted, så hvorfor ikke tage Top 10 af de vigtigeste processer i virksomheden. Man kender dem jo i forvejen, så det kan vel næppe være et problem at modellere dem som “as-is”. Under modelleringen dem er man nød til at nedbryde dem i mindre klodser, eller sæt af klodser(services moduler). Nedbrydningen spænder over kategorisering jvf. ex. “the-six(eight)-domain model” (http://onlineappsdba.com/upload/BEADomainModelForSOA.pdf ). Husk det er iterativ udvikling, men man har mulighed at indbygge “to-be” funktionalitet, wrappers og isolation services. Det vil sige en unik mulighed for at remodellere tidligere tiders mangler!
Det bedste ved SOA er, at magten burde være tilbage hos dem der virkelig forstår processerne. Udviklere reduceres til skibssnedkere med sans for implementeringstekniske detaljer. Sådan har det vel altid været tænkt at IT skulle implementeres.     

Arbejdsbyrden bør fordeles med
50 pct til forretningen/processfolk(ex. Indkøbsprocess),
20 pct til service implementering (Hvordan skal indkøbsprocessen forløbe teknisk),
20 pct til fejlhåndtering(Når indkøbsprocessen ikke forløber normalt hvad så ..),
10 pct til måling af den af forretningen beskrevne process. (Forløber Indkøbsprocessen forløber som den skal?)
Dvs 60 pct af tiden bruges på forretningsværdi kun 40 pct på IT. Hvis Agility lykkedes forbedres denne ratio over tid, hvis ikke, har SOA fejlet.     

Der bliver tit spurgt til “Best practices” ?
Men er “Best practices” ikke bare en kortsigtet erfaringsudveksling, som ofte baseres på workarounds og uhensigtmæssigheder (aka bugs) i teknologierne. Man kunne sige “Erfaring blot en evne til at genkende en fejl, når man begår den igen”. Mange ser “Best practices” som en Schweizer-kniv som skal løse alle problemer, men brug dog den stærkeste resource af alt – tankens kraft! Det gælder i det branche specifikke proceslag, som det teknologiske udviklingslag; der er ingen nemme løsninger! Ægte innovation udspringer enten fra stor viden eller det diametralt modsatte; fordomsfri, abstraktivt uspoleret og ikke-ensrettet tankevirksomhed, som ofte kendetegner mindre børns syn på verden. Efter min mening kommer de bedste ideer ikke fra innovation (i branchen fejlagtigt fortolket som nye tiltag), men fra simple/banale procesforbedringer herunder afskaffelse af BOB’s.     

Selvom motivationen og tankegangen bag SOA er ikke ny, muliggør arkitekturen “Business Agility” uafhængigt af IT systemers mangel på samme. Forskellen er, at branchen har, gennem udviklingen af SOA specifikationerne, stiltiende indrømmet, at IT agility aldrig rigtigt har eksisteret.     

Råd for 2011+ :
Kun en tåbe frygter ikke brokkerøve som brøler “BOB, BOB, BOB”, når nye politikker søsættes.     

Vi lader billedet stå et øjeblik ……     

Godt nytår!

Dette indlæg blev udgivet i Arbejdsområde. Bogmærk permalinket.

Et svar til SOA, POLPOT og BOB’s

  1. It’s really a nice and helpful piece of information. I’m glad that you shared this helpful info with us. Please keep us informed like this. Thanks for sharing.

Der er lukket for kommentarer.