Tijdens het feestgedruis van Koninginnedag 2008 viel het me weer eens op dat een feest staat of valt met een begiftigd DJ. De kunst om de selectie van muziek af te stemmen op het aanwezige publiek en de platenkeus continu bij te sturen op basis van de sfeer, dat vereist talent. Veel zakelijke it-gebruikers dromen van het moment dat een dergelijk talent hun belevingswereld eens tot een sprankelende sensatie maakt…
Voor een succesvolle DJ is een goed gevulde platenkoffer onontbeerlijk. Die platen zijn de ‘standaard bouwblokken’ voor de opbouw van de sfeer. Alleen die koffer is niet genoeg natuurlijk. Er een goede sfeer in de zaal mee kunnen creëren en die vast kunnen houden, daar gaat het om. Een aaneenschakeling van de juiste sfeerbouwblokken op het juiste moment. En zeg nou zelf, zo’n geheel op jouw stemming toegespitste mix, dat wil je toch eigenlijk ook gewoon voor jezelf, thuis of op kantoor? Je persoonlijke DJ James?
Laat me een geheim met je delen: de individuele it-gebruiker ziet zoiets interactiefs voor zich voor zijn zakelijke toepassingen! Vraag is dan wel hoe je die it-gebruikersbeleving realiseert, hoe je de volgorde van de bouwblokken op de juiste wijze stuurt en bewaakt, en hoe je überhaupt aan zulke standaard it-bouwblokken komt. De gemakken die in de muziekwereld normaal zijn, zijn namelijk niet zo vanzelfsprekend in de it-wereld. Wel eens een DJ gezien met in zijn platenkoffer zowel 78-toeren platen als blu-ray disks? Of een it-functie die rap de sfeer kan bijsturen, door andere bouwblokken op te nemen in de mix?
De juiste toon kunnen zetten binnen de it vergt een team van it-architecten. Het samenstellen van een degelijk it-architectenteam is echter lang niet eenvoudig. Het team moet de transformatie van de transactiegestuurde it naar interactiegestuurde it kunnen bedenken en bewaken. Door de wol geverfd voor wat betreft maatwerk én op de hoogte van de standaardservices in op soa gebaseerde pakketsoftware. Dat ook de beperkingen kent van dergelijke pakketsoftware en daar op een juiste wijze mee om kan gaan.
De mix van muziek bepaalt het succes van een avondje uit. Het succes van it ligt in de mix van gebruikersbeleving en standaard it-bouwblokken met daar over heen een excellente sturings- en bewakingsfunctie. En zo is het ook met het architectenteam. De crux zit ‘m in de mix. Oh ja, ook architecten gaan af en toe lekker een avondje uit: inspiratie opdoen met beide beentjes op de dansvloer. Yo DJ, pump that party!
Het is leuk om een SOA architect als DJ te beschouwen. Een DJ probeert de sfeer aan te voelen en op basis daarvan muziek te draaien. Een wereld DJ als Armin van Buuren is ook in staat om met zijn muziek een bepaalde sfeer te creeeren.
SOA zelf heeft helaas niets te maken met het creeen van emotie, hoe graag we dit ook willen. SOA is wat mij betreft alleen een manier van ontwikkeling, inrichting, etc. Wat in de wereld van IT vooral van belang is, is hoe klantvragen worden ondersteund met technische oplossingen gebaseerd op SOA. We kunnen technologie toepassen gebaseerd op taaltechnologie om deze klantvragen te vertalen naar achterliggende services. IT architecten hebben de uitdaging om een ‘infrastructuur’ in te richten om niet gedefinieerde klantvragen te vertalen in bestaande diensten om daarmee te komen tot een optimale gebruikersbeleving.
Degene die dit goed begrepen hebben, zijn de partijen als Google en anderen. Zij bieden zogenaamde mash-ups gebaseerd op bestaande diensten. Denk maar eens aan Google maps, waar een gebruiker informatie uit verschillende bronnen kan combineren. Hier ligt dan ook de toekomst en elke organisatie die hier aan mee wil werken, kan zijn diensten over het Internet voor deze mash-ups aanbieden.
Grappig genoeg komt het woord Mashups uit de disco-industrie. In de jaren 70 werden tunes met elkaar gemixed om tot een nieuwe song te komen, dus de DJ parallel zie ik zeker zitten.
Maar het mixen van willekeurige songs maakt niet automatisch een hit. Het gaat om voorzichtige afstemming van juiste ritme en pitch. En zo ook met SOA implementaties. SOA standaardisatie vereenvoudigt gelukkig het mixen van bedrijfsprocessen. Maar ook de afstemming van business en IT moet wel ritmisch met elkaar overlopen. Daar speelt granulariteit van de servicedefinitie een grote rol. Zit je te hoog qua granulariteit (de pitch), dan kunnen de SOA-services niet meer herbruikt worden in andere bedrijfsprocessen en verdwijnt het voordeel van SOA. Te laag, dan wordt het voor de IT alleen maar complexer voor ontwikkelen en beheer met meer overhead.
Dus verschillende factoren moeten goed afgestemd worden, ben benieuwd wie de zomerhit gaat scoren?
DJ of dirigent van een filharmonisch orkest? Ik zie meer de analogie met het orchestreren van de verschillende muziekinstrumenten, melodielijnen en het managen van de musici, kortom het ontwikkelen van een UNIEK stuk.
De muziekindustrie is een massa-industrie en massa-industrie functioneert alleen bij de gratie van standaarden en het voldoen aan deze standaarden. Standaarden gaan verder dan de interface, ze beschrijven ook het gewenst gedrag onder bepaalde condities. Voldoet een product niet, dan is er geen afzetmarkt. Dit geldt voor zowel de muziekspeler als de muziekdrager. De inhoud (de daadwerkelijke muziek) is NIET van belang voor de muziekspeler maar bepaalt natuurlijk wel voor een groot gedeelte het succes van de muziekdrager. De muziekspeler is zelf ook opgebouwd uit componenten die voortkomen uit massa-productie en vanzelfsprekend ook voldoen aan alle eisen.
In tegenstelling tot wat veel mensen ons willen doen geloven is Software Development niet te vergelijken met massa-productie. We spreken hier niet voor niets over Development en niet over Manufacturing. We bouwen eenmalig een systeem (development) net als we eenmalig een muziekstuk componeren, uitvoeren, etc. Willen we massa-productie dan wordt de uitvoering op een media geplaatst (DVD) en miljoenmaal gedupliceerd.
Ook SOA is geen massaprodukt (al doen de leveranciers ons soms anders geloven) maar een specifieke oplossing voor een specifieke situatie. In tegenstelling tot de muziek industrie speelt de inhoud wel degelijk een belangrijke rol. We maken geen massa-product dus zal de SOA Architect moeten bewaken dat de standaarden gevolgd worden. Niet alleen de interfacestandaarden maar evenzo belangrijk de werking onder bepaalde condities (input – output). En hier zit de echte uitdaging, wie investeert in het altijd kunnen garanderen van de juiste output gegeven een bepaalde input? In de massa-industrie is dit een vanzelfsprekendheid, in Software Development zal iemand moeten opstaan en deze verantwoordelijkheid op zich moeten nemen om hergebruik (hoe weinig dan ook) te kunnen garanderen.
Kortom een SOA Architect is meer een dirigent die gebruik maakt van standaarden (notenschrift) een UNIEK stuk tot uitvoering brengt en daarbij strak de regie in handen heeft en daar waar nodig bijstuurt op de uitvoering.
De crux zit inderdaad in de mix. Net als bij muziek gaat het bij een SOA-project over het orchestreren van verschillende rollen.
De business architect, in zijn rol overziet hij alle aspecten, van de bedrijfsprocessen tot aan de infrastructuur.
De proces analist heeft kennis van de specifieke processen binnen de organisatie/branche.
Er is een applicatie architect die de processen vertaalt naar de eisen voor integratie en die veel verstand heeft van de te gebruiken middleware.
In het team zit een ontwikkelaar die services ontwikkelt op verschillende niveaus van granulariteit.
Dan is er een infrastructuur architect, verantwoordelijk voor de hardware configuratie: zorgt voor de veiligheid, virtualisatie en de optimale beschikbaarheid.
Daarnaast is het handig dat er iemand verantwoordelijk is voor een goede gebruikersacceptatie: de front end designer.
Deze optimale mix klinkt als muziek in de oren!
Sinds kort heb ik de MusicIP mixer (www.musicip.com) ge?ntegreerd in de spelers van mijn (digitale) muziekcollectie. Ik heb op mijn speler nu een knopje erbij: ‘more like this’. Als er een leuk nummer speelt doe ik ‘more like this’ en MusicIP mixer maakt een playlist van 20 nummers uit mijn eigen collectie die hierop aansluiten. Leuk! Hiermee hoor je nummers die je nooit zelf meer draait en allang vergeten bent en die uitstekend blijken aan te sluiten.
De software werkt door het scannen van je muziekcollectie. De belangrijke parameters van de muziek (tempo, toonsoort, stem, etc) gecodeerd en gekoppeld aan een 768-bit key (‘PUID’). De functie ‘more like this’ zoekt vervolgens PUIDs die lijken op het nummer wat er speelt, en zet die achter elkaar. Presto, je eigen huis-tuin-keuken DJ.
Stel je voor, je kunt zoiets maken voor services. We hebben dan een spider nodig die alle systemen uit je landschap afstruint en alle belangrijke parameters in kaart brengt. Welke entiteiten, welke operaties ondersteunt dit systeem? Synchrone of asynchrone communicatie? Welke service levels? Welke beveiligingsniveaus?
Vervolgens moeten we een mix-and-match systeem maken, dat op basis van de gevraagde functionaliteit alle nodige en bij elkaar passende services op een rijtje zet. Arbeidsvoorwaardensysteem voor je personeel? Personeelsysteem, stukje autorisatie en authenticatie, uitgebreide auditing. Communicatie over voorraad en productie met je decentrale vestigingen? Beveiligde netwerkinfrastructuur, berichtenservers, ERP-systeem. More like this!
Die D in DJ staat dus eigenlijk voor Demand.
De DJ werkt namelijk aan de vraagkant. Op de dansvloer combineert hij real-time de standaard ‘services’ van de platen maatschappij tot een naadloos op de behoeften aansluitend, dansbaar geheel.
Voordeel van een DJ is dat hij veel goedkoper is dan een traditionele band (of in IT termen ‘maatwerk’), maar hetzelfde resultaat bereikt.
Goede DJ’s hebben overigens ruim voldoende talent om zelf platen te maken, zij kiezen dus bewust voor de vraagkant. Het verdient namelijk beter, heeft momenteel meer aanzien en bovendien zijn er al zoveel platen (componenten) van gerenommeerde spelers, dat het erg lastig is daar tussen te komen.
Grappig dat men net na koninginnendag ook op SAPhire het licht zag en aankondigde dat het niet meer gaat om de platen, maar om hoe je ze draait. Daarmee wordt BPM de draaitafel van de IT-er.
Of kunnen we voortaan beter praten over IJ-er (Information Jockey, uitspraak: ie-jee-er) of DJ-er (Demand Jockey).
Een DJ vergelijken met een SOA-architect. Leuk, en inderdaad gaat de vergelijking in gesteld voorbeeld tot een bepaalde hoogte wel op: beiden moeten in staat zijn om bouwstenen (Platen vs IT-bouwblokken) naadloos in elkaar te laten overlopen.
Alleen daar houdt m.i. de vergelijking ook op. Een DJ zal wel naar het publiek luisteren maar kan dat maar in beperkte mate! Waarom? Omdat een DJ zich over het algemeen specialiseert in een bepaald gebied. Ooit DJ Tiesto Bubbling zien draaien? Een Armin van Buren Hardhouse? Om de metafoor door te trekken: zet 1 van deze beiden in een groep mensen (lees: klanten) die dit soort muziek verlangt en het gaat fout. De kennis (type muziek) is er niet en de bouwstenen (platen)zijn niet aanwezig. De DJ kan aangeven dat dit zijn gebied niet is en eventueel naar een andere collega DJ wijzen die het wel ‘gebied’ wel beheerst.
Zoals Mendel Koerts al stelt zal een SOA-architect zal zich veel meer naar de wensen van de klant moeten richten. Als de klant ‘hardhouse’ i.c.m. ‘bubbling’ verwacht dan, dan zal de architect dat moeten leveren. Geen kennis van beiden of onmogelijke opgave? Dan zorg maar dan dat kennis er komt of dat duidelijk kan worden aangetoond dat het niet gaat. Een team met de juiste kennis is onontbeerlijk.
SOA is een service…de klant vraag en u draait.