Comments on: SOA, BPM, EDA een andere kijk (Dutch) http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/ A weblog about software engineering, Architecture, Technology an other things we like. Thu, 29 Jul 2010 07:45:23 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Freddie http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/comment-page-1/#comment-13 Freddie Sun, 10 Feb 2008 17:23:29 +0000 http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/#comment-13 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." 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.”

]]> By: Freddie http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/comment-page-1/#comment-12 Freddie Sun, 10 Feb 2008 17:22:37 +0000 http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/#comment-12 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) 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)

]]> By: wout http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/comment-page-1/#comment-10 wout Sat, 09 Feb 2008 22:10:38 +0000 http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/#comment-10 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. 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.

]]> By: Freddie http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/comment-page-1/#comment-8 Freddie Thu, 07 Feb 2008 07:04:36 +0000 http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/#comment-8 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. 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.

]]> By: wout http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/comment-page-1/#comment-7 wout Wed, 06 Feb 2008 21:38:27 +0000 http://www.gridshore.nl/2008/02/06/soa-bpm-eda-een-andere-kijk-dutch/#comment-7 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. 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.

]]>