SOA rollespil med gamle og nye ansigter

Før jeg tog på efterårsferie havde jeg nogle hektiske uger med en voldsom masse events. I de næste par post vil jeg gerne fortælle om dem og håber at de kan give andre den samme inspiration, som det har givet mig.

I uge 38 var jeg med til 'SOA på 24 timer' arrangeret af CSC og EA fellows . Jeg havde tilmeldt fordi jeg tit har på fornemmelsen at vi - folk fra IT branchen -  har helt forskellige vokabularier omkring SOA og at jeg, ved at møde ligesindede på et arrangement som dette, kunne få en fælles forståelse og ' tør jeg sige det ? referenceramme.

Nå, men jeg kom til et dejligt landsted ved Sørup på midtsjælland for at konstatere at ca 30 andre hoveder fra leverandører, offentlige myndigheder, private virksomheder ? små, såvel som store og meget andet godt folk havde fundet vej til Sørup. Der var kendte IT folk, grå eminencer og helt nye ansigter i blandt deltagerne.

CSC's Inge Speiermann, som går under titlen 'innovation manager? faciliterede det praktiske omkring arrangementet, mens Allan Bo Rasmussen og allestedsnærværende hr. Gøtze fra EA fellows faciliterede det faglige.

De 24 timer workshop forløb på følgende måde:

Efter at have fået en minimal introduktion til workshoppen og den tilhørende case (et flyselskab skal opdeles i 3 dele: et executive, "first class" selskab, et discount og et selskab til at vedligeholde flyflåde og andre ground opgaver ) fik vi en dejlig frokost (!).

Herefter returnerede vi til workshoplokalet hvor vi blev bedt om at katagorisere vores personlige kompetence inden for SOA med 'Akademisk ekspert' som den ene yderlighed til 'Praktisk gris' som den anden.

Denne øvelse var dels lavet for at vi kunne præsentere os over for vores meddeltagere som vi skulle tilbringe de næste 24 timer med og dels for at vi i forbindelse med den næste øvelse hvor vi på bedste 'fodboldholds-indeling-i-skolegården'(aka 'første-vælger ') skulle vælge hold sammensætning. Dette var en hjælp til at kunne vælge et hold som var sammensat med flest mulige forskellige kompetencer.

Herefter fik hver gruppe tildelt et af de tre nye selskaber og blev som første opgave bedt om at formulere 5 arkitektur principper for deres selskab. ...og puha , hvordan er det nu lige man gør det og hvad er det?

For at vi ikke skulle stå på alt for bar bund ' gav de flinke instruktører os et eksempel på enterprise arkitektur rammeværk som vi kunne bruge for at få vores principper positioneret!...og ja, jeg skrev 'positioneret' fordi principper kan vi hurtigt komme med, men hvorfor smide et princip om 'Vi vil konsolidere alt IT på en platform fra en leverandør' ' hvis princippet ikke understøtter andre principper i f.eks Forretningsarkitekturen eller Informationsarkitekturen. Så ideen fra instruktørernes side var at et princip skal beskrives (en regel eller beslutning), begrundes (hvad gør dette vigtigt) og have en betydning eller implikation (hvad er de forventede følger af dette princip).

F.eks kunne jeg have et Informationsarkitektur princip fra min hjemmeside ' minfantastiskeboghandel.xyz ' om at kunderne/brugerne skal vedligeholde og udtrække de identitets informationer de lagre via handlinger på min hjemmeside.

Det princip hænger så i øvrigt sammen med det Forretningsarkitektur princip jeg har om at kundens og mine muligheder for at bruge de lagrede identitets er tilstede for at kunne give kunden og mig de bedste forudsætninger for at få en optimal oplevelse på mit website.

Dette princip kan så kædes sammen med den vision jeg har om at kunden er det vigtigste asset for min side og at min differentiator i markedet er at min boghandel i modsætning til alle andre tillader kunden af vedligeholde og medtage identitetsinformationer fra min side.

Det var principperne som de udspiller sig mod den forretningsmæssige del af min arkitektur ' hvis vi kigger mere i retning af den tekniske arkitektur så hænger mit Informationsarkitektur princip sammen med mit Løsningsarkitektur som lyder: Mine IT systemer skal understøtte 'claims based authentication? baseret på åbne standarder. Dette passer også fint sammen med min tekniske arkitektur som jeg har valgt skal baseres på Security Token Services fra WS-Trust spec?en og udstedelse af SAML security tokens.  

Jeg springer beskrivelse og begrundelse af mine principper i dette online boghandel eksempel over ellers bliver denne post for lang (to late!!!!).  

Nå, men ' vores erfaring i gruppe blev hurtig at vi gjorde det vi var bedst til ' opstillede principper for den tekniske arkitektur, men kom hurtigt til den erkendelse at vi vidste for lidt om forretningsbehovene og at vi ? de fleste af os med en teknisk baggrund - måtte bevæge os mod de forretningsmæssige principper.

Dette var den lektie som for mit vedkommende var hele sceancens kodensat ' IT arkitekter skal ' når de får formuleret en opgave - lave push-back til forretningen hvor og når det er nødvendigt.

Efter præsentationerne og aftensmaden var det (selvfølgelig!') tid til at købe konsulent bistand. Vi have et sæt fiktive midler som kunne benyttes til at købe artifakter, som var lavet af nogle 'konsulenthuse' ' sytembeskrivelse, analyser oma. På den måde kunne vi komme forretningsprincipper og andet nærmere. Det forskellige teams forhandlede med konsulenterne i plenum ? meget morsomt og ret lærerigt.  

Kl 0.00 sluttede første workshopdag ? og så på hovedet i seng!

Næste dag skulle de forskellige teams inden kl 10.00 færdigøre en præsentation til ledelsen i flyselskabet, som viste hvordan man havde tænke sig at udtrykke ledelsens vision i principper, hvilke omkostninger disse ville have, hvordan disse principper implementeres og hvordan denne arkitektur vedligeholdes.

Herefter havde hvert hold 20 min foran ledelsen og med efterfølgende kommentarer og eval fra ledelsen og de andre grupper.

Nu var rollespillet så færdigt og EA Fellows gav os en introduktion til en real world case som var omkring flyselskaber.

Det sidste vi lavede var at lave en times evaluering over de 24 timer.

Mine take-aways fra denne workshop var:

Jeg havde forventet mig noget helt andet af en 'SOA Workshop' ? service modellering, ESB beskrivelse, BAM best practice, BPM governance og tooling, service granularitet ...etc. måske, men istedet endte jeg med at blive en smule fustreret over hele tiden at skulle bevæge mig fra den tekniske arkitektur og ind på det forretningsmæssige. Jeg ved jo da for f****** ikke noget om forretningsarkitektur!

Jeg havde en klar fornemmelse af hele tiden at svømme mod strømmen i de 24 timer hen mod det velkendte som jeg gerne ville lave, men hele tiden at blive skubbet mod den ukendte forretningsarkitektur som jeg ikke ville lave. Det galdt iøvrigt også for mange af de andre deltagere. Lige præcis der ? i det overraskende og ukendte - ligger styrken i denne workshop og derfor er jeg i retrospekt så glad for at jeg deltog og fik en lille flig af en ny kompetence.

Den ovenstående beskrivelse er ikke udtømmende nok til at give den credit som skal gives, der er et utal af andre nuancer i workshoppen, som jeg ikke skal komme ind på her ' bl.a af hensyn til de som skulle komme på workshoppen i den nærmeste fremtid ' der er nogle sjove overraskelser og gimmicks indlagt.

Nu vil jeg bare sige tak til mine meddeltagere for nogle gode timer ? i var og er en inspiration!