Service Oriented Architecture
Service Oriented Architecture (SOA) is de magnetron van deze tijd. Toen enkele decennia geleden deze nieuwe keukenmachine werd geïntroduceerd, was de belofte groter dan dat uiteindelijk de praktijk uitwees. De marketing heeft zelfs tot excessen geleidt zoals het hondje drogen in de magnetron. SOA staat hetzelfde te wachten. De Agility van het bedrijf zal niet verbeteren door de ontkoppeling van services. Agility is iets menselijks en dus kan dit alleen bereikt worden door een cultuur verandering.
De belofte van een verbeterende Governance, waarmee beheersbaarheid en wijzigingen van de bedrijfslogica wordt bedoeld, zal alleen toenemen mits er wordt overgegaan tot uitfaseren van legacy en herbouw conform SOA. Dit is het echte probleem waarmee de meeste bedrijven te maken hebben. De investering en risico’s die gepaard gaan met uitfaseren van systemen zijn dusdanig dat je dit alleen kan met de support van de CEO kan realiseren. Wat dus vaak wordt voorgesteld is het evolutie scenario waarin aan SOA invulling wordt gegeven door een Service-laag als abstractie laag boven legacy-systemen te leggen. Echter, de implementatie van de service wordt nog steeds ingevuld door de legacy-systemen. Systemen met miljoenen regels code, oost duitse schermen en complexe database structuren die volkomen met elkaar verweven zijn. Volgens mij zal de beheersbaarheid niet toenemen maar eerder afnemen. Een wijziging in een service houdt niets anders in dan een wijziging in het legacy-systeem. Dit negatieve effect zal alleen maar toenemen mocht er veelvuldig hergebruik van services gaan plaatsvinden, iets wat volgens mij een utopie is.

Business Proces Management
Algemeen wordt gesteld dat SOA een basis vormt voor Business Process Management (BPM). Ik ontken dit niet, maar ik heb vraagtekens bij de verwachtingen die leven bij BPM. Niet alleen heb ik sterke twijfels bij de ratio van business service hergebruik (aantal services en hoe vaak aangeroepen) maar meer nog bij het modeleren van de processen. Onderzoek na het hergebruik van services bij een niet nader te noemen bank bevestigd de vermoedens. Maximaal tot 30% van de services zouden hergebruikt (kunnen) worden en het aantal keer dat een service wordt hergebruikt is schrikbarend laag op een uitzondering na.
Ik durf te stellen dat de huidige opvattingen omtrent BPM gelijk staat aan Workflow en dat er geen sprake is van echt het managen en dus sturen op business processen. Ik zal dit proberen te illustreren door een vergelijking te maken met een routeplanner. Een route plannen kun je doen voorafgaand aan de trip door ouderwets met een pen op een kaart te tekenen of door software te gebruiken als bijv. maps.google.nl . Maar in onze huidige tijd wordt de route gepland tijdens de trip (TomTom) en deze berekent continue opnieuw de meest optimale route gegeven de omstandigheden. Dus pre-trip route planning is vergelijkbaar met workflow en een daadwerkelijke BPM kun je vergelijken met een navigatiesysteem. De huidige BPM systemen vereisen een pre-trip planning waarin je dus alle mogelijke afwijkingen moet gaan modelleren denk daarbij aan situaties zoals files, sluiproutes, gebruikersgedrag wat niet aansluit bij de route en zo kan ik nog wel even doorgaan. Iedereen zal begrijpen dat dit niet mogelijk is. Een echt business proces is dusdanig complex dat deze niet in een twee dimensionaal model gemodelleerd kan worden. Wat we modelleren is Workflow, opéénvolgende activiteiten die doorlopen moeten worden met al dan niet een conditionele beslissing om links of rechts te gaan.

Event Driven Architecture
Een systeem dat werkelijk bedrijfsprocessen ondersteund, zal enorm veel voordeel halen uit een SOA maar er is meer nodig, een andere manier van denken. Een business event is een gebeurtenis, het ontstaan van een situatie, waarop de organisatie vanuit de aan haar gestelde verantwoordelijkheden, taken en doelstellingen moet of wil reageren. Een Event-Oriented Architecture neemt deze business events als uitgangspunt wat resulteert in informatie-systemen die real-time kunnen reageren en dus een meer natuurgetrouwe benadering van de werkelijkheid oplevert en minder complex is dan de traditionele procedurele benadering. Als we de vergelijking met de routeplanner en het navigatiesysteem aanhalen kunnen we stellen dat het navigatiesysteem een implementatie is van een event-Oriented Architecture. Er komen continue events binnen (file, positie) die het systeem real-time verwerkt en die resulteren in advies aan de bestuurder van de auto en het bijwerken van de route, dit alles met als doel de plaats van bestemming te bereiken (business goal).
In het bedrijfsleven zou een event bijvoorbeeld een verhuizing van een klant kunnen zijn of het afsluiten van een (tweede) lening. Dit brengt ons dan ook gelijk bij in mijn ogen het grootste probleem van de meeste bedrijven. Het ontbreekt aan een enterprise brede consistente kijk op de klant. De stelling dat een SOA hiervoor een oplossing zou bieden trek ik dan ook sterk in twijfel aangezien het een gigantische investering met zich mee zal brengen en de complexiteit zoals hiervoor beschreven flink zal toenemen.

5 thoughts on “SOA, BPM, EDA een andere kijk (Dutch)

  • February 10, 2008 at 6:23 pm
    Permalink

    Was even vergeten de quot van Ian Malcolm op te nemen
    “All the money spent on long-range forecasting – about half a billion dollars in the last few decades – is money wasted. It’s a fool’s errand. It’s as pointless as trying to turn lead into gold.”

  • February 10, 2008 at 6:22 pm
    Permalink

    SOA is meer dan een applicatie architectuur het is ook een principe dat gebruikt kan worden in de architectuur en strategie vorming door het onderkennen van “Diensten” zoals je kunt lezen op http://soa.computable.nl/2008/02/soa-gaat-over-d.html.
    Als een legacy systeem ontworpen is vanuit de gedachte dat het diensten aanbiedt aan afnemers en de implementatie van de diensten is gedaan met de principes uit Component based development (tight coupling and loose binding) dan zal onderhoud en wijzigingen op de implementatie van deze diensten lokaal blijven en dus gemakkelijk te testen.
    echter, ik stel grote vraagtekens bij de mate van hergebruik van deze “business” diensten. Natuurlijk zijn er altijd wel diensten te benoemen die wel vaak nodig zullen zijn denk bijv. aan klantgegevens maar zal het merendeel van de te onderkennen diensten niet vaak terugkomen in andere processen.

    Natuurlijk helpt Business Process Modeling bij de interactie met de business om requirements helder te krijgen. Mijn stelling is meer gericht op het automatiseren van deze business processen. Zoals Robert Mekking ook al schreef in zijn blog (http://www.atosoriginblog.nl/2008/01/24/soa-schaalt-niet/)

    In een complexe situatie beredeneren welke scenario’s kunnen optreden, zodat er een betrouwbaar en voorspelbaar proces wordt doorlopen is alleen mogelijk in eenvoudige situaties. Of, zoals Ian Malcolm zegt in “Jurassic Park”. (Het boek, niet de film, barbaren)

  • February 9, 2008 at 11:10 pm
    Permalink

    Even begrippen voor mij synchroniseren.
    Greenfield landschap -> outside-in ontwerpen/ontwikkelen
    Legacy landschap -> inside-out ontwerpen/ontwikkelen

    Goed, tijd voor een stelling.

    Als legacy goed (zoals hierboven bedoeld) is ontworpen en ontwikkeld, is het dan “gemakkelijk” te hergebruiken als services vergeleken met slecht ontworpen en ontwikkelde legacy? Of boeit dat niet of nauwelijks, en is service enabling altijd moeizaam en pijnlijk?

    Trouwens, BPM zie ik meer als (communicatie)hulpmiddel gedurende de fases van Requirements, Analyse, Design, Implementation, Operation. Zeg maar round-tripping tussen Business en IT. Als de Business graag dingen in Rules uitdrukt, dan zal BPM dat zeker mee moeten nemen.

  • February 7, 2008 at 8:04 am
    Permalink

    Dank je wel voor je positieve reactie. Het blijft lastig om hypes aan de kaak te stellen met name omdat in essentie de achterliggende ideeen wel goed zijn (oude wijn is vaak goed). Echter, de meeste mensen vergeten even voor het gemak dat we niet meer in een greenfield leven maar te maken hebben met legacy.

    BPM kan volgens mij alleen maar succesvol worden met een EDA en een goede pattern / rule-engine. Denk maar aan events in het lichaam. een pijnprikkel (event) wordt geprocessed door onze hersenen (rule-engine / pattern engine) die op zijn beurt weer signalen uitstuurt naar spieren (besturing events) waarop we onze hand wegtrekken.

    in ieder geval is het altijd leuk om over dit soort zaken na te denken en over te discussieren.

  • February 6, 2008 at 10:38 pm
    Permalink

    Was zo maar wat aan het googlen, en kom dit knisperverse stukje tegen. Erg goed stukje overigens.

    In het SOA deel herken ik veel. Het is een flinke hype, maar uiteindelijk oude wijn in nieuwe zakken. Ik zie weinig verschillen tussen gewoon goed ontwerpen en programmeren en puur-SOA ontwerpen en ontwikkelen (layers/modules/encapsulation en andere patterns).

    De BPM en EDA delen beschouw ik niet als gescheiden. Zeker niet als BPM echt executeerbare processen oplevert (runtime), en niet alleen maar een leuke plaatjesproducent is at designtime. Ten slotte moeten de Events uit EDA afgehandeld cq. begrepen worden, wat goed kan door kleine stukjes BPM, zeg maar TomTom. Die BPM-etjes kunnen ook weer Events afvuren, etc., etc., met alle complexiteit van dien.

    PS: leuke analogie trouwens, de routeplanner.

Comments are closed.