Dit op de wegblog van Marc Andreessen.
Zou wel eens een boeiende ontwikkeling kunnen zijn. Ontwikkelen voor platforms als Salesforce.com, of Amazon, of wat dan ook is natuurlijk mooi, maar je zit niet te wachten op weer een nieuwe platform-lock-in.
Ik zie in ieder geval een model-driven aanpak als remedie, maar een universele API helpt natuurlijk ook.
Affijn, ik ga erin duiken.
woensdag 31 oktober 2007
ESB: wat moet je ermee? nogmaals
Rik vraagt zich af;
"Niet helemaal duidelijk wordt of 1) ESB's in zijn geheel niet nodig zijn in een applicatie landschap, of 2) ESB's wel nodig zijn maar dat je deze niet zelf in huis hoeft te halen (SaaS) of 3) je ze wel nodig hebt maar dat de standaarden die ze aanhangen op dit moment te complex zijn.
Ik denk dat je ESB's nodig hebt. Om de reden dat - indien applicatie landschappen straks zijn opgebouwd uit een veelheid aan inwisselbare services - je een "makelaar" achtige functie moet hebben om de vraag naar en het aanbod van services bij elkaar te brengen. Of je de ESB dan in-house of bij een provider neer moet zetten, vind ik een andere discussie."
3 vragen dus:
1. zijn ESB's nodig?
Ja. Althans: er is een message broker nodig die berichten rondstuurt, de aankomst van berichten bewaakt, etc. In hoeverre adapters, Business Rule Engines, etc daarvan deel moeten uitmaken, is een andere vraag.
2. moet je ze in huis halen?
Nee, dat hoeft niet, behalve wellicht in het geval van integratie van legacy-applicaties. (Hoewel ook in dat geval goede adapters al een heel stuk helpen.)
Voor de goede orde: op dit moment is het in huis halen van een ESB moeilijk te vermijden, maar in de toekomst zal, zeker bij gebruik van SaaS-oplossingen, de implementatie van een eigen ESB niet nodig zijn.
Bovendien kun je de functionaliteit van een ESB zelf ook als service inhuren (Amazon biedt dit al aan.)
3. zijn de standaarden te complex?
Ja, dat denk ik eigenlijk wel. Ik verwacht dat hierin nog veel verandering zal komen, en dat in veel gevallen een simpeler, meer REST-achtige benadering de overhand zal krijgen.
Hoe dan ook: ik denk dat Rik en ik het wel met elkaar eens zijn.
"Niet helemaal duidelijk wordt of 1) ESB's in zijn geheel niet nodig zijn in een applicatie landschap, of 2) ESB's wel nodig zijn maar dat je deze niet zelf in huis hoeft te halen (SaaS) of 3) je ze wel nodig hebt maar dat de standaarden die ze aanhangen op dit moment te complex zijn.
Ik denk dat je ESB's nodig hebt. Om de reden dat - indien applicatie landschappen straks zijn opgebouwd uit een veelheid aan inwisselbare services - je een "makelaar" achtige functie moet hebben om de vraag naar en het aanbod van services bij elkaar te brengen. Of je de ESB dan in-house of bij een provider neer moet zetten, vind ik een andere discussie."
3 vragen dus:
1. zijn ESB's nodig?
Ja. Althans: er is een message broker nodig die berichten rondstuurt, de aankomst van berichten bewaakt, etc. In hoeverre adapters, Business Rule Engines, etc daarvan deel moeten uitmaken, is een andere vraag.
2. moet je ze in huis halen?
Nee, dat hoeft niet, behalve wellicht in het geval van integratie van legacy-applicaties. (Hoewel ook in dat geval goede adapters al een heel stuk helpen.)
Voor de goede orde: op dit moment is het in huis halen van een ESB moeilijk te vermijden, maar in de toekomst zal, zeker bij gebruik van SaaS-oplossingen, de implementatie van een eigen ESB niet nodig zijn.
Bovendien kun je de functionaliteit van een ESB zelf ook als service inhuren (Amazon biedt dit al aan.)
3. zijn de standaarden te complex?
Ja, dat denk ik eigenlijk wel. Ik verwacht dat hierin nog veel verandering zal komen, en dat in veel gevallen een simpeler, meer REST-achtige benadering de overhand zal krijgen.
Hoe dan ook: ik denk dat Rik en ik het wel met elkaar eens zijn.
UIs van Enterprise Software
Khoi Vinh (een web designer) klaagt in de NYTimes over de gebrekkige kwaliteit van de User Interfaces van Enterprise Software. Hij wijt dat aan het feite dat ze niet echt blootstaan aan concurrentie.
vrijdag 26 oktober 2007
De nadelen van SaaS
Op SaaSblogs dit stuk over de nadelen van SaaS. Vanuit de klant en vanuit de leverancier.
Het interessantst is, lijkt mij, het veronderstelde risico dat als de leverancier kopje onder gaat, de klant zijn gegevens kwijt is.
Mij lijkt dat niet nodig. De klant moet een copie van zijn gegevens krijgen wanneer hij dat wil. Dat is op zichzelf niet voldoende, want hij moet ook nog iets aankunnen met die gegevens. Daarom moeten ze voldoen aan een beschrijving die de gegevens begrijpelijk maakt, en liefst ook portable naar een andere omgeving.
Dit is één van de punten waar SaaS een model-gedreven benadering (MDA, MDD, MDE, MDSD, of hoe je het ook noemt) nodig heeft.
Het interessantst is, lijkt mij, het veronderstelde risico dat als de leverancier kopje onder gaat, de klant zijn gegevens kwijt is.
Mij lijkt dat niet nodig. De klant moet een copie van zijn gegevens krijgen wanneer hij dat wil. Dat is op zichzelf niet voldoende, want hij moet ook nog iets aankunnen met die gegevens. Daarom moeten ze voldoen aan een beschrijving die de gegevens begrijpelijk maakt, en liefst ook portable naar een andere omgeving.
Dit is één van de punten waar SaaS een model-gedreven benadering (MDA, MDD, MDE, MDSD, of hoe je het ook noemt) nodig heeft.
donderdag 25 oktober 2007
Leuk
Dit is een leuk stuk over SOA van Pete Lacey. De conclusie:
No matter which definition works for you, though, SOA is misnamed. So I’ll leave you with some updates to your lexicon:
Network Oriented Computing (NOC): An approach to computing that makes business logic available over the network in a standardized and interoperable manner.
Service Oriented Architecture (SOA): A technical approach to NOC that has a non-uniform service interface as its principle abstraction. Today, SOAP/WS-* is the chief implementation approach.
Resource Oriented Architecture (ROA): A technical approach to NOC that has an addressable, stateful resource as its principle abstraction. Today, REST/HTTP is the chief implementation approach.
Business Service Architecture (BSA): An unnecessary term (also not an architecture) that tries to make the obvious something special. Aka, business analysis. Aka, requirements gathering.
=======
Zo is het maar net.
No matter which definition works for you, though, SOA is misnamed. So I’ll leave you with some updates to your lexicon:
Network Oriented Computing (NOC): An approach to computing that makes business logic available over the network in a standardized and interoperable manner.
Service Oriented Architecture (SOA): A technical approach to NOC that has a non-uniform service interface as its principle abstraction. Today, SOAP/WS-* is the chief implementation approach.
Resource Oriented Architecture (ROA): A technical approach to NOC that has an addressable, stateful resource as its principle abstraction. Today, REST/HTTP is the chief implementation approach.
Business Service Architecture (BSA): An unnecessary term (also not an architecture) that tries to make the obvious something special. Aka, business analysis. Aka, requirements gathering.
=======
Zo is het maar net.
woensdag 24 oktober 2007
Coupa en Amazon
Carlota Perez over de Web 2.0 bubble
Carlota Perez in de NYT. Interessant verhaal, bevat een toelichting op de huidige overspannen aankopen door Google, Yahoo c.s. van allerhande kleinere bedrijven.
woensdag 17 oktober 2007
ESB uit de muur
In deze posting voorspelde ik dat het mogelijk en zinvol is om ESB-achtige diensten te "huren" bij een externe provider. Voordeel: dan hoef je niet zelf een ESB te implementeren, met alle gevolgen en kosten van dien.
Ik kom er net achter dat Amazon deze dienst al aanbiedt, in de vorm van Amazon Simple Queue Service. Nou ja, nog geen complete ESB, maar een queue vergelijkbaar met de JMS-definitie, als ik het goed zie.
Maar ik vind het toch erg leuk.
Ik kom er net achter dat Amazon deze dienst al aanbiedt, in de vorm van Amazon Simple Queue Service. Nou ja, nog geen complete ESB, maar een queue vergelijkbaar met de JMS-definitie, als ik het goed zie.
Maar ik vind het toch erg leuk.
vrijdag 12 oktober 2007
ESB: wat moet je ermee?
Een paar weken geleden zei ik dat ik niet geloof dat de ESB's zoals we die nu kennen zo nodig moeten worden geimplementeerd door "gewone" bedrijven. Immers, als je SaaS gebruikt, heb je die ESB niet nodig. Bovendien zijn die ïmplementatie-trajecten complex en duur, en ik kwam dus tot de conclusie: niet aan beginnen. Uitzondering was wellicht de situatie waarin legacy-applicaties en services gecombineerd moeten worden.
Steve Vinoski is (zie hier, hier en hier) tot dezelfde conclusie gekomen. Hij is zijn geloof in de ESB verloren, zoals hij zelf zegt, en denkt dat ze beter niet gebruikt kunnen worden. Ook hij maakt een uitzondering voor legacy-integratie.
Zijn argumentatie is echter anders. Hij heeft bezwaren tegen de complexiteit van de SOAP/WS-* "standaard", en ziet daarin teken van de behoefte van veel IT-ers om met één taal te werken. Vinosky vindt dat onzin, en ziet meer in het gebruik van REST in combinatie met dynamische talen om problemen ad hoc op te lossen.
Ik ben niet zo voor een wildgroei van talen en taaltjes, niet omdat ik vind dat alles in één taal moet, maar omdat op den duur maintenance een probleem zal worden. Maar als MDA gebruikt wordt om het noodzakelijke te genereren, is dat bezwaar eigenlijk weg.
Vinoski wijst er voorts terecht op dat de zogenaamde standaarden (hij bedoelt WS-* etc) enorm ingewikkeld zijn, en dat men bij toepassing al heel snel door de bomen het bos niet meer ziet.
Inderdaad. Hoe dan ook, de conclusie is hetzelfde: de ESB en de daaraan verbonden protocollen gaan een twijfelachtige toekomst tegemoet.
PS: Interessant is trouwens ook de reactie van Dan Hatfield:
" Honestly, I see the ESB as primarily a political thing. It allows for a greater degree of control on delivered solutions.
In large companies, we don’t often do architecture - we do politecture…The politics drive the architecture.
Not the way it should be…but that’s the way it is."
Politecture.... Inderdaad. Maar dat is een ander onderwerp.
Steve Vinoski is (zie hier, hier en hier) tot dezelfde conclusie gekomen. Hij is zijn geloof in de ESB verloren, zoals hij zelf zegt, en denkt dat ze beter niet gebruikt kunnen worden. Ook hij maakt een uitzondering voor legacy-integratie.
Zijn argumentatie is echter anders. Hij heeft bezwaren tegen de complexiteit van de SOAP/WS-* "standaard", en ziet daarin teken van de behoefte van veel IT-ers om met één taal te werken. Vinosky vindt dat onzin, en ziet meer in het gebruik van REST in combinatie met dynamische talen om problemen ad hoc op te lossen.
Ik ben niet zo voor een wildgroei van talen en taaltjes, niet omdat ik vind dat alles in één taal moet, maar omdat op den duur maintenance een probleem zal worden. Maar als MDA gebruikt wordt om het noodzakelijke te genereren, is dat bezwaar eigenlijk weg.
Vinoski wijst er voorts terecht op dat de zogenaamde standaarden (hij bedoelt WS-* etc) enorm ingewikkeld zijn, en dat men bij toepassing al heel snel door de bomen het bos niet meer ziet.
Inderdaad. Hoe dan ook, de conclusie is hetzelfde: de ESB en de daaraan verbonden protocollen gaan een twijfelachtige toekomst tegemoet.
PS: Interessant is trouwens ook de reactie van Dan Hatfield:
" Honestly, I see the ESB as primarily a political thing. It allows for a greater degree of control on delivered solutions.
In large companies, we don’t often do architecture - we do politecture…The politics drive the architecture.
Not the way it should be…but that’s the way it is."
Politecture.... Inderdaad. Maar dat is een ander onderwerp.
Kunnen SAP, MS, c.s. de draai maken?
Phil Wainewright vraagt zich (hier en hier) af of software-verkopers die het nu moeten hebben van licenties (hij noemt in dat verband SAP, Microsoft, Adobe en Oracle0 de draai naar SaaS wel zullen kunnen maken. Zie ook dit interview met Steve Singh. Overigens heeft Nick Carr daarbij zijn twijfels: hij denkt dat Microsoft wel zal slagen, in ieder geval op korte termijn.
Ik heb me dat ook meermalen afgevraagd. Bedrijven als SAP kunnen technisch die draai natuurlijk uitstekend maken. Sterker: SAP heeft dat ook gedaan. En ook als het gaat om kennis van het domein (ERP bv), dan zijn ze beter dan wie ook.
SAP ByDesign (de SaaS-SAP) is waarschijnlijk een uitstekend product. SAP richt zich met ByDesign op het MKB, maar als het goed is, waarom zouden dan grotere bedrijven er niet mee aan de gang gaan? En als dat gebeurt, droogt de licentie-geldstroom op voor SAP.
Maar de geldstroom die een SaaS-oplossing brengt is anders gespreid in de tijd, en waarschijnlijk in totaal veel kleiner. En als het al lukt om licenties te blijven verkopen, dan zijn het er waarschijnlijk minder, en ook nog eens tegen een lagere prijs agv de concurrentie van SaaS en wellicht ook OSS. En die mindere geldstroom is een probleem voor grote bedrijven, omdat ze gewend zijn aan het "makkelijke geld". Hun hele bedrijfsvoering, salarisstructuur, etc is daarop ingericht.
En als ze dan ook nog eens beursgenoteerd zijn, is het extra moeilijk te investeren in de lange termijn ten koste van korte termijn winsten.
Ik denk dat de SaaS-revolutie (of wat het ook is) wel eens een soortgelijk effect kan hebben als de komt van kleinere computers voor de oude mainframe-producenten: ze verdwijnen.
Ik heb me dat ook meermalen afgevraagd. Bedrijven als SAP kunnen technisch die draai natuurlijk uitstekend maken. Sterker: SAP heeft dat ook gedaan. En ook als het gaat om kennis van het domein (ERP bv), dan zijn ze beter dan wie ook.
SAP ByDesign (de SaaS-SAP) is waarschijnlijk een uitstekend product. SAP richt zich met ByDesign op het MKB, maar als het goed is, waarom zouden dan grotere bedrijven er niet mee aan de gang gaan? En als dat gebeurt, droogt de licentie-geldstroom op voor SAP.
Maar de geldstroom die een SaaS-oplossing brengt is anders gespreid in de tijd, en waarschijnlijk in totaal veel kleiner. En als het al lukt om licenties te blijven verkopen, dan zijn het er waarschijnlijk minder, en ook nog eens tegen een lagere prijs agv de concurrentie van SaaS en wellicht ook OSS. En die mindere geldstroom is een probleem voor grote bedrijven, omdat ze gewend zijn aan het "makkelijke geld". Hun hele bedrijfsvoering, salarisstructuur, etc is daarop ingericht.
En als ze dan ook nog eens beursgenoteerd zijn, is het extra moeilijk te investeren in de lange termijn ten koste van korte termijn winsten.
Ik denk dat de SaaS-revolutie (of wat het ook is) wel eens een soortgelijk effect kan hebben als de komt van kleinere computers voor de oude mainframe-producenten: ze verdwijnen.
dinsdag 9 oktober 2007
Jackson over Software Engineering
Michael Jackson vindt (of vond in 1998) dat Software Engineering als discipline niet kan bestaan. Want de echt engineering-disciplines binnen de informatica zijn verder gespecialiseerd: database engineering, of compilerbouw.
En verder een aantal scherpe, en geestig verwoorde, observaties.
En verder een aantal scherpe, en geestig verwoorde, observaties.
vrijdag 5 oktober 2007
Waar begin je een domeinmodel?
Gisteravond een aantal oud-collega's gesproken, waaronder John S., die nog aan de wieg van VSP heeft gestaan. En met hem een interessante gedachtenwisseling, onder meer over de vraag: wat is een goed domein-model?
John is nogal een voorstander van zaken als use-cases, sequence-diagrams, etc. Zoals bekend: ik ben daar niet zo'n fan van. John wees mij erop dat dat ook te maken heeft met de manier waarop ik denk. Dat wil zeggen: vanuit de concepten die in een domein een rol spelen: wat zijn de concepten, hoe zijn ze aan elkaar gerelateerd, wat "doen" ze? En dan kom je uit op een class-model, eventueel aangevuld met statecharts. Inderdaad: daar ben ik heel blij mee.
John denkt veel meer vanuit het "programma": hoe wordt het programma (als je daarvan nog kunt spreken) uitgevoerd? Wat is de flow? En dan zijn bv sequence-diagrams, activity diagrams en event-traces erg boeiend.
Het heeft inderdaad te maken met de manier waarop je tegen een systeem aankijkt: vanuit de dynamiek, of "ontologisch".
John is nogal een voorstander van zaken als use-cases, sequence-diagrams, etc. Zoals bekend: ik ben daar niet zo'n fan van. John wees mij erop dat dat ook te maken heeft met de manier waarop ik denk. Dat wil zeggen: vanuit de concepten die in een domein een rol spelen: wat zijn de concepten, hoe zijn ze aan elkaar gerelateerd, wat "doen" ze? En dan kom je uit op een class-model, eventueel aangevuld met statecharts. Inderdaad: daar ben ik heel blij mee.
John denkt veel meer vanuit het "programma": hoe wordt het programma (als je daarvan nog kunt spreken) uitgevoerd? Wat is de flow? En dan zijn bv sequence-diagrams, activity diagrams en event-traces erg boeiend.
Het heeft inderdaad te maken met de manier waarop je tegen een systeem aankijkt: vanuit de dynamiek, of "ontologisch".
donderdag 4 oktober 2007
HumanWave en Cordys
Gisteren op het event van Cordys geweest. Hoogtepunt voor mij was het verhaal van Bart Aarsen over de realistaie van een SaaS-HRM systeem: HumanWave. Als ik het goed het begrepen is het deze week live gegaan.
Eigenlijk zijn dit soort toepassing van een "ESB", zeker van Cordys, logischer dan de implementatie bij "eindklanten". Het zou heel goed kunnen dat de onafhankelijkheid van Cordys, dwz: het feit dat men niet te maken heeft met een te integreren stack van bestaande software bij de "installed base" (zoals bij bv IBM en Oracle wel het geval is), bij zo'n SaaS-toepassing voor Cordys werkt.
Eigenlijk zijn dit soort toepassing van een "ESB", zeker van Cordys, logischer dan de implementatie bij "eindklanten". Het zou heel goed kunnen dat de onafhankelijkheid van Cordys, dwz: het feit dat men niet te maken heeft met een te integreren stack van bestaande software bij de "installed base" (zoals bij bv IBM en Oracle wel het geval is), bij zo'n SaaS-toepassing voor Cordys werkt.
maandag 1 oktober 2007
BPM en de architectureluur
Een vraag:
"Hoe "bijzonder" is de BPM laag en in hoeverre leent deze zich voor hergebruik, SaaS, etc. ? We nemen dan even aan dat de BPM laag vrij is van zaken die er niet thuishoren. Volgens de filosofie van service orientatie is de BPM laag toch de plek waar de applicatie wordt gevormd (op basis van componentent die we al hebben). Er van uitgaande dat we geen twee applicaties ontwikkelen die hetzelfde kunstje doen, zou je zeggen dat 1) herbruikbaarheid binnen de BPM laag minimaal is en 2) de BPM content bij uitstek content is die bedrijven bij zich willen houden - zowel qua ontwikkeling als qua beheer.
De rest van de applicatie architectuur en de onderdelen die jij noemt kunnen al snel als infrastructuur worden betiteld en als zodanig worden behandeld. Maar die BPM laag... hmmm... ik weet het niet."
Technsich gezien kan de BPM-laag zelf ook in de infrastructuur. Je ziet dat nu al gebeuren: ESB's hebben vaak nogal wat mogelijkheden om business-processen uti te voeren, althans voorzover het de executie van BPEL of zoiets betreft. Dat opent dus ook de mogelijkheid om dat bij een SaaS-provider te laten doen, en daarmee is het in zekere zin infrastructuur geworden.
Ik denk dat we het daarover wel eens zijn, maar dat is jouw punt niet, geloof ik.
Jouw punt is (denk ik): de BP-logica is uniek voor een bedrijf f zelfs voor een proces binnen een bedrijf, en leent zich dus niet voor hergebruik.
Ik vraag me af of dat waar is. Is het nou echt zo dat een fulfillment-proces zo vreselijk uniek is? Volgens mij zijn die processen in de meeste bedrijven juist tot op grote hoogte hetzelfde. En dat deel dat inderdaad hetzellfde is, kun je dus hergebruiken.
Maar er is nog iets, en dat heeft te maken met de achtergrond van BPM. De BPM-ers komen in het algemeen (voorzover ze een IT-achtergrond hebben) uit de data-oriented/4GL-hoek. Hun beeld is: je hebt een database, en daarbovenop draaien applicaties, die de business-processen uitvoeren. Het is dan ook duidelijk dat er geen goede plaats is voor de zogeheten business-rules., en dus komt er een ingewikkeld verhaal over business-rule-engines of zoiets bij.
Echter, een goed ontworpen SOA lijkt meer op een component-based systeem, en de design-aanpak voor een SOA lijkt dan ook veel meer op een object-oriented aanpak dan op een data-oriented aanpak.
In een OO/SOA-aanpak zijn er veel meer manieren om "gedrag" (dus business-rules, proces-logica en zo) te beschrijven dan de meeste BPM-ers zich realiseren. Als je en SOA goed ontwerpt, dan zit er veel minder in die BPM-laag dan wordt aangenomen in een "conventionele" BPM-aanpak.
Met andere woorden: ik vraag me af of die BPM-laag wel zo interessant is voor bedrijven om "bij zich te houden". Niet alleen omdat er veel generieks in zit, maar ook omdat ie goed beschouwd nogal dun is.
Ik denk wel dat bedrijven hun domeinmodellen "bij zich" moeten houden. Maar dat geldt dan niet alleen voor de processen, maar wel degelijk ook voor een groot deel de achterliggende business-logica. Niet zozeer omdat die domeinmodellen uniek zijn (dat zijn ze geodbeschouwd maar voor een klein deel), maar vooral omdat men lock-in wil voorkomen.
Als je je domeinmodel laat implementeren door SaaS.com, en je besteedt in feite ook het bouwen en het beheer van dat domeinmodel daaraan uit, dan zit je met handen en voeten aan SaaS.com vast. Terwijl juist dat model weergeeft hoe je tegen je gegevens aankijkt, wat je processen zijn, welke vrijheidsgraden je hebt, enzovoort. Gezien vanuit een IT-standpunt IS dat model je bedrijf. Dat besteed je niet uit.
"Hoe "bijzonder" is de BPM laag en in hoeverre leent deze zich voor hergebruik, SaaS, etc. ? We nemen dan even aan dat de BPM laag vrij is van zaken die er niet thuishoren. Volgens de filosofie van service orientatie is de BPM laag toch de plek waar de applicatie wordt gevormd (op basis van componentent die we al hebben). Er van uitgaande dat we geen twee applicaties ontwikkelen die hetzelfde kunstje doen, zou je zeggen dat 1) herbruikbaarheid binnen de BPM laag minimaal is en 2) de BPM content bij uitstek content is die bedrijven bij zich willen houden - zowel qua ontwikkeling als qua beheer.
De rest van de applicatie architectuur en de onderdelen die jij noemt kunnen al snel als infrastructuur worden betiteld en als zodanig worden behandeld. Maar die BPM laag... hmmm... ik weet het niet."
Technsich gezien kan de BPM-laag zelf ook in de infrastructuur. Je ziet dat nu al gebeuren: ESB's hebben vaak nogal wat mogelijkheden om business-processen uti te voeren, althans voorzover het de executie van BPEL of zoiets betreft. Dat opent dus ook de mogelijkheid om dat bij een SaaS-provider te laten doen, en daarmee is het in zekere zin infrastructuur geworden.
Ik denk dat we het daarover wel eens zijn, maar dat is jouw punt niet, geloof ik.
Jouw punt is (denk ik): de BP-logica is uniek voor een bedrijf f zelfs voor een proces binnen een bedrijf, en leent zich dus niet voor hergebruik.
Ik vraag me af of dat waar is. Is het nou echt zo dat een fulfillment-proces zo vreselijk uniek is? Volgens mij zijn die processen in de meeste bedrijven juist tot op grote hoogte hetzelfde. En dat deel dat inderdaad hetzellfde is, kun je dus hergebruiken.
Maar er is nog iets, en dat heeft te maken met de achtergrond van BPM. De BPM-ers komen in het algemeen (voorzover ze een IT-achtergrond hebben) uit de data-oriented/4GL-hoek. Hun beeld is: je hebt een database, en daarbovenop draaien applicaties, die de business-processen uitvoeren. Het is dan ook duidelijk dat er geen goede plaats is voor de zogeheten business-rules., en dus komt er een ingewikkeld verhaal over business-rule-engines of zoiets bij.
Echter, een goed ontworpen SOA lijkt meer op een component-based systeem, en de design-aanpak voor een SOA lijkt dan ook veel meer op een object-oriented aanpak dan op een data-oriented aanpak.
In een OO/SOA-aanpak zijn er veel meer manieren om "gedrag" (dus business-rules, proces-logica en zo) te beschrijven dan de meeste BPM-ers zich realiseren. Als je en SOA goed ontwerpt, dan zit er veel minder in die BPM-laag dan wordt aangenomen in een "conventionele" BPM-aanpak.
Met andere woorden: ik vraag me af of die BPM-laag wel zo interessant is voor bedrijven om "bij zich te houden". Niet alleen omdat er veel generieks in zit, maar ook omdat ie goed beschouwd nogal dun is.
Ik denk wel dat bedrijven hun domeinmodellen "bij zich" moeten houden. Maar dat geldt dan niet alleen voor de processen, maar wel degelijk ook voor een groot deel de achterliggende business-logica. Niet zozeer omdat die domeinmodellen uniek zijn (dat zijn ze geodbeschouwd maar voor een klein deel), maar vooral omdat men lock-in wil voorkomen.
Als je je domeinmodel laat implementeren door SaaS.com, en je besteedt in feite ook het bouwen en het beheer van dat domeinmodel daaraan uit, dan zit je met handen en voeten aan SaaS.com vast. Terwijl juist dat model weergeeft hoe je tegen je gegevens aankijkt, wat je processen zijn, welke vrijheidsgraden je hebt, enzovoort. Gezien vanuit een IT-standpunt IS dat model je bedrijf. Dat besteed je niet uit.
Abonneren op:
Posts (Atom)