Goed stuk van Richard Veryard in CBDI Journal (link naar samenvatting). Veryard vestigt de aandacht op het feit dat toepassing van BPM en SOA zonder meer zeker niet de voordelen op het gebied van agility gaat opleveren die men er van verwacht.
Inderdaad. Zie ook SaaSaaS.
maandag 20 augustus 2007
vrijdag 17 augustus 2007
David Hay en de DNC
Ik heb inmiddels David Hay's Data Model Patterns in mijn vingers gekregen. Het is duidelijk dit dit een van de bouwstenen was voor de colors-aanpak van Peter Coad c.s. Ik was benieuwd of dit boek vol met data model patronen ook een equivalent van de DNC (de Domain Neutral Component) bevat.
En zowaar: daar is het Universal Data Model! Maar helaas, nadere bestudering leert hier dat het inderdaad een metamodel betreft, maar dan een in een andere abstractie-richting. Wat het UDM van Hay in feite doet is het begrippen-paar class-instance in een datamodel weergeven, attributen en attribuutwaarden als entiteiten weergeven, en relaties expliciet benoemen.
Dat is dus vergelijkbaar mer de MOF Layer 2 beschrijving van UML. Nuttig (en ook wel logisch gezien het gemis aan een dergelijk metamodel in data modeling), maar iets anders dan het color-metamodel. Toch wel raar dat Hay, als ie toch aan het metamodelleren was, die voor de hand liggende stap heeft gemist: het universele domein model.
Affijn, ik heb het boek nog niet helemaal doorgewerkt, dus misschien zie ik iets over het hoofd.
En zowaar: daar is het Universal Data Model! Maar helaas, nadere bestudering leert hier dat het inderdaad een metamodel betreft, maar dan een in een andere abstractie-richting. Wat het UDM van Hay in feite doet is het begrippen-paar class-instance in een datamodel weergeven, attributen en attribuutwaarden als entiteiten weergeven, en relaties expliciet benoemen.
Dat is dus vergelijkbaar mer de MOF Layer 2 beschrijving van UML. Nuttig (en ook wel logisch gezien het gemis aan een dergelijk metamodel in data modeling), maar iets anders dan het color-metamodel. Toch wel raar dat Hay, als ie toch aan het metamodelleren was, die voor de hand liggende stap heeft gemist: het universele domein model.
Affijn, ik heb het boek nog niet helemaal doorgewerkt, dus misschien zie ik iets over het hoofd.
donderdag 16 augustus 2007
Literate modeling
Een zijspoor van het onderzoek naar archetypes: literate modeling. Het is een techniek waarbij modellen worden "uitgelegd" voor "stakeholders" die ze anders niet begrijpen.
Arlow en Neustadt introduceren dit begrip in hun boek, en op codegeneration vat Jim Arlow de voordelen als volgt samen:
Duidelijk verhaal, prima verhaal. Ik geloof dat ik zelf iets dergelijks ook al doe. Dus dan is get goed. :)
De voordelen die Arlow noemt zijn er ook inderdaad, en het zijn echte voordelen.
Maar heb ik een twijfel.
De suggestie is dat dit soort modellen (het gaat om modellen voor de analyse) bedoeld zijn voor afstemming met "stakeholders", of zelfs dat die modellen eerst moeten zijn goedgekeurd door de "stakeholders".
Volgens mij is dat allebei niet waar. Het doel van modellen is het specificeren van een systeem, en de uiteindelijke toets voor de correctheid is of er een goed werkend systeem, met de juiste vrijheidsgraden, etc mee tot stand komt.
Of de "stakeholders" de modellen "herkennen" of begrijpen, is eigenlijk niet relevant. Natuurlijk, als de domeinanalist het domein probeert te begrijpen, is het handig om de modellen die hij heeft gemaakt af te stemmen, en in dat kader is literate modeling zeker nuttig.
Maar de uiteindelijk verantwoordelijke is de analist, en de mening van de "business" over die modellen op zichzelf is strikt genomen niet relevant.
Arlow en Neustadt introduceren dit begrip in hun boek, en op codegeneration vat Jim Arlow de voordelen als volgt samen:
- The UML model tends to be more correct. It’s amazing how often we have taken a "correct" UML model and discovered semantic errors in it when we came to explain it to ourselves by writing the narrative.
- You get an improvement in quality. This arises because the non-technical stakeholders gain the ability to assess and critique the model.
- You get better requirements traceability. High-level requirements often become lost in UML models. We call this the "trivialization of requirements" in our paper. The narrative must highlight key requirements and illustrate how the UML model realizes these.
- You increase the business benefit of your UML models by making these models accessible to a much wider audience.
Duidelijk verhaal, prima verhaal. Ik geloof dat ik zelf iets dergelijks ook al doe. Dus dan is get goed. :)
De voordelen die Arlow noemt zijn er ook inderdaad, en het zijn echte voordelen.
Maar heb ik een twijfel.
De suggestie is dat dit soort modellen (het gaat om modellen voor de analyse) bedoeld zijn voor afstemming met "stakeholders", of zelfs dat die modellen eerst moeten zijn goedgekeurd door de "stakeholders".
Volgens mij is dat allebei niet waar. Het doel van modellen is het specificeren van een systeem, en de uiteindelijke toets voor de correctheid is of er een goed werkend systeem, met de juiste vrijheidsgraden, etc mee tot stand komt.
Of de "stakeholders" de modellen "herkennen" of begrijpen, is eigenlijk niet relevant. Natuurlijk, als de domeinanalist het domein probeert te begrijpen, is het handig om de modellen die hij heeft gemaakt af te stemmen, en in dat kader is literate modeling zeker nuttig.
Maar de uiteindelijk verantwoordelijke is de analist, en de mening van de "business" over die modellen op zichzelf is strikt genomen niet relevant.
vrijdag 10 augustus 2007
Archetypes (vv)
Ruim twee weken geleden kondigde ik aan te gaan onderzoeken wat het nut is van archetypes, en die te gaan beoordelen op de volgende criteria:
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
En daar kwam later bij:
6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?
De onderzochte aanpakken zijn:
- de REA aanpak (Resources, Events, Agents), in de variant van Pavel Hruby c.s.
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak (pleomorphs) van (o.m.) Arlow en Neustadt.
Ik ben nog lang niet klaar, maar dit is de eerste inventarisatie.
Ad 1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
- REA: ja. Daar is de aanpak bij uitstek voor bedoeld. Het gehanteerde metamodel (REA, duality, conversion process, etc) is ook expliciet uit de abstractie van business-domeinen ontleend (mn uit accounting). De aanpak is compleet: elk business-domein wordt in principe volledig bestreken, zij het dat soms wat kunstgrepen nodig zijn. REA is ook alleen maar voor business-domeinen geschikt.
- colors: ja. De Domain Neutral Component (PPT, Role, Description, Moment/Interval) is een zeer abstract model, en eigenlijk een metamodel dat overal (niet alleen voor business-analyse) kan worden toegepast. Maar er zijn specialisaties mogelijk voor business-analyse, en Coad c.s. geven daarvan ook voorbeelden. De aanpak is compleet: elk business-domein wordt volledig bestreken.
- pleomorphs: ja. De aanpak biedt een set aan (samenhangende) analyse-patronen, die uitstekend geschikt zijn om een business-analyse te doen. Of elk business-domein compleet wordt afgedekt, betwijfel ik.
Ad 2. is de aanpak bruikbaar in een MDE-traject?
- REA: ja, mits verder uitgewerkt. Er zijn iig aanzetten voor MDA/MDE-achtige zaken, maar er zal wel nog het nodige meoten worden gedaan om eea te laten werken. Nadeel is wel dat de REA-aanpak niet uit de hoek van de software-ontwikkeling komt, waardoor de mapping van REA-concepten op bv componenten of classes nog wel eens lastig kan zijn (zie bijvoorbeeld het ontbreken van een Role).
- colors: ja, mits doorontwikkeld. Deze aanpak stamt van voor de MDA-hype, en dus zitten er geen expliciete aangrijpingspunten voor MDA of MDE in. Echter, de aanpak zit zo strak in elkaar als het gaat om de afleiding van modellen dat dit geen groot probleem zal zijn. (opvallend in dit verband is dat Coad c.s. de term "metamodel" niet gebruiken voor hun abstracte patronen, hoewel ze wel bij uitstek zo te gebruiken zijn).
- pleomorphs: ja. Is expliciet opgenomen, en er worden zelfs voorbeelden gegeven met ArcStyler als tool.
Ad 3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
- REA: waarschijnlijk wel. Echter, de mapping van analyse concepten naar services is nog niet triviaal, mede omdat een REA-model puur op het punt van bv object-orientatie (cohesie interfaces, etc) nog niet helemaal klaar is.
- colors: ja. Weliswaar zitten services etc. niet in de aanpak, maar dankzij de strak uitgewerkte interfaces, de keurig aansluitende domein-concepten en vooral de roles die al in het model als koppeling optreden, is een mapping op een SOA niet moeilijk.
- pleomorhs: waarschijnlijk wel. Deze aanpak resulteert in goede OO-modellen, waaruit services normaliter makkelijk af te leiden zijn.
Ad 4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
- REA: ja. Ik voorzie geen problemen.
- colors: ja.
- pleomorphs: ja, is er zelfs specifiek op gericht (compleet met voorwoord van de onvermijdelijke Richard Mark Soley, Ph.D.)
Ad 5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
- REA: zeer twijfelachtig. REA is goed in het adhv de business analyseren van die business, maar is niet gericht op software. Ik betwijfel of dit werkt, al zullen proeven dat moeten uitwijzen.
- colors: ja, uitstekend. De top-down benadering helpt ook bij zeer rommelig in elkaar zittende legacy-software. Colors is eigenlijk een soort patroon-taal, en dat is hier een groot voordeel.
- pleomorphs: ja. Het opzoeken van de patronen is goed mogelijk, maar ze moeten wel al zichtbaar zijn.
Ad 6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?
- REA: redelijk. REA gebruikt expliciet AO voor bepaalde vormen van gedrag (asymmetrische aspecten vooral). Om het echt in een MDE-aanpak te laten werken is nog wel wat werk nodig, maar het begin is er.
- colors: redelijk. Aspecten zitten er niet expliciet in, maar de aanpak (weer dankzij de roles) leent zich er goed voor. Om het in een MDE-aanpak te laten werken is nog wel werk nodig.
- pleomorphs: matig. Voorzover ik kan overzien is er geen rekening mee gehouden. Aan de andere kant; het zijn wel OO-modellen, dus het is er in te breien. Maar er zal meer werk voor nodig zijn dan bij colors.
Zo, dit is de eerste inventarisatie. Het is duidelijk: er is nog veel uit te zoeken. En er is ook nog veel meer te zeggen van deze aanpakken, de voor- en nadelen, enzovoort. Dat zal allemaal gebeuren.
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
En daar kwam later bij:
6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?
De onderzochte aanpakken zijn:
- de REA aanpak (Resources, Events, Agents), in de variant van Pavel Hruby c.s.
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak (pleomorphs) van (o.m.) Arlow en Neustadt.
Ik ben nog lang niet klaar, maar dit is de eerste inventarisatie.
Ad 1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
- REA: ja. Daar is de aanpak bij uitstek voor bedoeld. Het gehanteerde metamodel (REA, duality, conversion process, etc) is ook expliciet uit de abstractie van business-domeinen ontleend (mn uit accounting). De aanpak is compleet: elk business-domein wordt in principe volledig bestreken, zij het dat soms wat kunstgrepen nodig zijn. REA is ook alleen maar voor business-domeinen geschikt.
- colors: ja. De Domain Neutral Component (PPT, Role, Description, Moment/Interval) is een zeer abstract model, en eigenlijk een metamodel dat overal (niet alleen voor business-analyse) kan worden toegepast. Maar er zijn specialisaties mogelijk voor business-analyse, en Coad c.s. geven daarvan ook voorbeelden. De aanpak is compleet: elk business-domein wordt volledig bestreken.
- pleomorphs: ja. De aanpak biedt een set aan (samenhangende) analyse-patronen, die uitstekend geschikt zijn om een business-analyse te doen. Of elk business-domein compleet wordt afgedekt, betwijfel ik.
Ad 2. is de aanpak bruikbaar in een MDE-traject?
- REA: ja, mits verder uitgewerkt. Er zijn iig aanzetten voor MDA/MDE-achtige zaken, maar er zal wel nog het nodige meoten worden gedaan om eea te laten werken. Nadeel is wel dat de REA-aanpak niet uit de hoek van de software-ontwikkeling komt, waardoor de mapping van REA-concepten op bv componenten of classes nog wel eens lastig kan zijn (zie bijvoorbeeld het ontbreken van een Role).
- colors: ja, mits doorontwikkeld. Deze aanpak stamt van voor de MDA-hype, en dus zitten er geen expliciete aangrijpingspunten voor MDA of MDE in. Echter, de aanpak zit zo strak in elkaar als het gaat om de afleiding van modellen dat dit geen groot probleem zal zijn. (opvallend in dit verband is dat Coad c.s. de term "metamodel" niet gebruiken voor hun abstracte patronen, hoewel ze wel bij uitstek zo te gebruiken zijn).
- pleomorphs: ja. Is expliciet opgenomen, en er worden zelfs voorbeelden gegeven met ArcStyler als tool.
Ad 3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
- REA: waarschijnlijk wel. Echter, de mapping van analyse concepten naar services is nog niet triviaal, mede omdat een REA-model puur op het punt van bv object-orientatie (cohesie interfaces, etc) nog niet helemaal klaar is.
- colors: ja. Weliswaar zitten services etc. niet in de aanpak, maar dankzij de strak uitgewerkte interfaces, de keurig aansluitende domein-concepten en vooral de roles die al in het model als koppeling optreden, is een mapping op een SOA niet moeilijk.
- pleomorhs: waarschijnlijk wel. Deze aanpak resulteert in goede OO-modellen, waaruit services normaliter makkelijk af te leiden zijn.
Ad 4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
- REA: ja. Ik voorzie geen problemen.
- colors: ja.
- pleomorphs: ja, is er zelfs specifiek op gericht (compleet met voorwoord van de onvermijdelijke Richard Mark Soley, Ph.D.)
Ad 5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
- REA: zeer twijfelachtig. REA is goed in het adhv de business analyseren van die business, maar is niet gericht op software. Ik betwijfel of dit werkt, al zullen proeven dat moeten uitwijzen.
- colors: ja, uitstekend. De top-down benadering helpt ook bij zeer rommelig in elkaar zittende legacy-software. Colors is eigenlijk een soort patroon-taal, en dat is hier een groot voordeel.
- pleomorphs: ja. Het opzoeken van de patronen is goed mogelijk, maar ze moeten wel al zichtbaar zijn.
Ad 6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?
- REA: redelijk. REA gebruikt expliciet AO voor bepaalde vormen van gedrag (asymmetrische aspecten vooral). Om het echt in een MDE-aanpak te laten werken is nog wel wat werk nodig, maar het begin is er.
- colors: redelijk. Aspecten zitten er niet expliciet in, maar de aanpak (weer dankzij de roles) leent zich er goed voor. Om het in een MDE-aanpak te laten werken is nog wel werk nodig.
- pleomorphs: matig. Voorzover ik kan overzien is er geen rekening mee gehouden. Aan de andere kant; het zijn wel OO-modellen, dus het is er in te breien. Maar er zal meer werk voor nodig zijn dan bij colors.
Zo, dit is de eerste inventarisatie. Het is duidelijk: er is nog veel uit te zoeken. En er is ook nog veel meer te zeggen van deze aanpakken, de voor- en nadelen, enzovoort. Dat zal allemaal gebeuren.
De europese software-industrie
Gisteren schreef ik dit.
De stelling dat Europa achterblijft op het gebied van de software, komt vandaan bij Michiel van Genuchten. Ik denk dat hij in zijn constatering gelijk heeft, en ik vermoed dat een van de factoren daarbij de rigiditeit van de europese arbeidsmarkt is. Immers, ontwikkeling van software is (als hoofdactiviteit van een bedrijf) een riskante bezigheid, waarbij bovendien de arbeidskosten een zeer groot deel van de totale kosten uitmaken.
Het probleem met zo'n rigide arbeidsmarkt is dat het heel snel een "kop-ik-win, kruis-jij-verliest" markt wordt. Als het slecht gaat, blijft men schuilen onder de paraplu van de ontslagbescherming, gaat het beter, dan laat men zich wegkopen of gaat men freelancen. En de software-industrie is een erg volatiele bedrijfstak, met hoge toppen en diepe dalen.
Dat is een probleem voor alle bedrijven die aan software-ontwikkeling doen, maar in het bijzonder voor bedrijven die een software-rodukt ontwikkelen. Immers:
1. die ontwikkeling zelf is heel riskant. Het kan heel goed gaan, maar de kans is ook groot dat het heel slecht gaat. In het laatste geval is het moeilijk om tijdig werknemers te ontslaan, en dus is het riskanter om een produkte te ontwikkelen in Europa dan in de VS.
2. de investering bij software-ontwikkeling zit niet alleen in de ontwikkelde software zelf, maar ook (waarschijnlijk meer dan in de meeste andere takken, waar investeringen in machinerie e.d. een grotere rol spelen) in de kennis van de mensen. Die wil je graag houden, en hoge beloningen e.d. liggen dan voor de hand. Maar dan gaat die ontslagbescherming weer extra knellen....
De stelling dat Europa achterblijft op het gebied van de software, komt vandaan bij Michiel van Genuchten. Ik denk dat hij in zijn constatering gelijk heeft, en ik vermoed dat een van de factoren daarbij de rigiditeit van de europese arbeidsmarkt is. Immers, ontwikkeling van software is (als hoofdactiviteit van een bedrijf) een riskante bezigheid, waarbij bovendien de arbeidskosten een zeer groot deel van de totale kosten uitmaken.
Het probleem met zo'n rigide arbeidsmarkt is dat het heel snel een "kop-ik-win, kruis-jij-verliest" markt wordt. Als het slecht gaat, blijft men schuilen onder de paraplu van de ontslagbescherming, gaat het beter, dan laat men zich wegkopen of gaat men freelancen. En de software-industrie is een erg volatiele bedrijfstak, met hoge toppen en diepe dalen.
Dat is een probleem voor alle bedrijven die aan software-ontwikkeling doen, maar in het bijzonder voor bedrijven die een software-rodukt ontwikkelen. Immers:
1. die ontwikkeling zelf is heel riskant. Het kan heel goed gaan, maar de kans is ook groot dat het heel slecht gaat. In het laatste geval is het moeilijk om tijdig werknemers te ontslaan, en dus is het riskanter om een produkte te ontwikkelen in Europa dan in de VS.
2. de investering bij software-ontwikkeling zit niet alleen in de ontwikkelde software zelf, maar ook (waarschijnlijk meer dan in de meeste andere takken, waar investeringen in machinerie e.d. een grotere rol spelen) in de kennis van de mensen. Die wil je graag houden, en hoge beloningen e.d. liggen dan voor de hand. Maar dan gaat die ontslagbescherming weer extra knellen....
donderdag 9 augustus 2007
Comparative advantage
Ik vond dit artikel van Alejandro Cunat en Marc Melitz. Voornaamste strekking: het overige gelijkblijvend, hebben landen met een flexibele arbeidsmarkt een comparative advantage. Dat is geen verrassing natuurlijk, maar zij voegen er aan toe dat landen met een rigide arbeidsmarkt van die rigiditeit minder last hebben in weinig volatiele bedrijven en bedrijfstakken. En kapitaalintensivieit vermindert het voordeel van flexibiliteit ook.
Maw: landen met een rigide arbeidsmarkt hebben een comparative advantage in statische en kapitaalintensieve bedrijfstakken. (Voor de duidelijkheid: in absolute termen hebben ze waarschijnlijk nog steeds een nadeel tov flexibele landen.)
En dat verklaart wellicht waarom continentaal Europa zo zwak is op het gebied van software-ontwikkeling. Want dat is bij uitstek een volatiele bedrijfstak. Je kunt natuurlijk wel weer SW-ontwikkeling devolatiliseren door het onder te brengen bij Grote Automatiseringsafdeingen, en bij detacheringshuizen. En dat is ook precies wat er (vooral) Europa is gebeurd. Maar dat brengt weer zijn eigen problemen met zich mede.
Maw: landen met een rigide arbeidsmarkt hebben een comparative advantage in statische en kapitaalintensieve bedrijfstakken. (Voor de duidelijkheid: in absolute termen hebben ze waarschijnlijk nog steeds een nadeel tov flexibele landen.)
En dat verklaart wellicht waarom continentaal Europa zo zwak is op het gebied van software-ontwikkeling. Want dat is bij uitstek een volatiele bedrijfstak. Je kunt natuurlijk wel weer SW-ontwikkeling devolatiliseren door het onder te brengen bij Grote Automatiseringsafdeingen, en bij detacheringshuizen. En dat is ook precies wat er (vooral) Europa is gebeurd. Maar dat brengt weer zijn eigen problemen met zich mede.
maandag 6 augustus 2007
Aspecten en archetypes
Het onderzoek naar Archetype-benaderingen vordert (zie ook hier). Wat wel duidelijk is: een koppeling van archetypes met aspecten (in de zin van Aspect-orientatie) is nodig. Immers: archetypes moeten aan elkaar gekoppeld kunnen worden. Als dat binnen hetzelfde "domein" is, is dat niet erg, al krijg je al snel een explosie van de mogelijke analyse-patronen.
Maar als de archetypes niet in hetzelfde domein liggen (en dat is bij asymmetriche aspecten al snel het geval: wie zit er te wachten op logging als je een business-model aan het bestuderen bent? Toch is logging nodig) dan is AO een geld middel.
Ik zal de aanpakken dus ook op dit aspect (grijns) beoordelen.
Maar als de archetypes niet in hetzelfde domein liggen (en dat is bij asymmetriche aspecten al snel het geval: wie zit er te wachten op logging als je een business-model aan het bestuderen bent? Toch is logging nodig) dan is AO een geld middel.
Ik zal de aanpakken dus ook op dit aspect (grijns) beoordelen.
vrijdag 3 augustus 2007
SaaSaaS (2)
SaaS is dus heel mooi, maar er zijn een aantal problemen en obstakels. Ik heb hiervoor een aantal genoemd (zie hier):
- er zijn standaards nodig, zowel op technisch als op "semantisch" (dwz: vwb het probleemdomein) gebied
- er is een manier van beschrijven van systemen nodig die het uitbesteden van systeemontwikkeling en -beheer, bv via outsourcing of offshoring makkelijker maakt
- de wijze van specificeren moet ervoor zorgen dat de problemen voortvloeiende uit "glue code" zoveel mogelijk worden vermeden
- er moet een manier zijn om bestaande software (legacy) in de SaaS-opzet te betrekken.
Is dat mogelijk? Ja, ik denk het wel.
We zijn al een heel stuk verder als we een (abstracte) taal hebben, die het mogelijk maakt een probleem domein (bijvoorbeeld een business-domein) te beschrijven to the point en zonder redundantie. Voorts moeten we in staat zijn een beschrijving in die taal te gebruiken voor een implementatie, zonder dat nadere informatie nodig is. Je kunt een specificatie dan gebruiken voor een automatische implementatie, maar ook voor de specificatie van een extern (bv via outsourcing) te realiseren systeem. De taal moet dus onafhankelijk zijn van de wijze van implementatie, maar ook van het platform van implementatie. Zo wordt lock-in vermeden. En de taal moet geschikt zijn om bestaande legacy-software in te beschrijven, alsmede "semantische" standaarden bevatten of in ieder geval mogelijk maken.
Zo, dat is nogal wat. Maar het kan wel. We zijn er in ieder geval vlak bij.
Voor de domeinbeschrijving is het mogelijk om met OO en UML een heel eind te komen. Inderdaad, UML is niet helemaal niet compleet: de beschrijving van gedrag is moeilijk, en UML bevat ook veel overbodige onzin (use cases!), maar die hoef je natuurlijk niet te gebruiken. Maar de basis is er, en met goed gekozen aanvullingen is OO-UML bruikbaar.
Die aanvullingen liggen op de volgende gebieden:
- beschrijving gedrag. UML is hiervoor onvoldoende. Er is een Action Language (een soort pseudo-code) nodig om gedragsbeschrijvingen bruikbaar te maken. Een subset van een gewone programmeertaal (bv Java of Ruby) is afdoende.
- een standaard voor het koppelen van de domeinmodellen. Een aspect van een domein wordt apart beschreven (later daarover meer), maar om een domein compleet te beschrijven is in feite een soort "meta-taal" nodig die beschrijft hoe modellen met elkaar samen (kunnen) hangen. Aspect-orientatie, MDSM, MDE en ook technieken als UML with color bieden bieden hiervoor mogelijkheden.
- een standaard semantiek die de gebruikte concepten beschrijft op een dusdanige wijze dat ze over de (deel)domeinen hetzelfde zijn. Voor SaaS is dat utieraard cruciaal. Hiervoor zijn verscheidene aanzetten, waarvan sommige varen onder de prachtige vlag van de "web ontology". Schitterend buzzword. Het is verstandig om een schuin oog op deze ontwikkelingen gericht te houden, maar het is niet nodig om erop te wachten. In de prakiek zijn allen OO-standaardmodellen voor business-domeinen ongeveer hetzelfde, en iig makkelijk naar elkaar te transformeren.
- eventueel kunnen naast UML DSLs gebruikt worden voor specfieke deelterreinen, zolang de koppeling met UML maar te maken is. Een voorbeeld hiervan is BPMN voor het modelleren van processen.
Wat wel van belang is; als uitbreidingen worden gemaakt, dan is het wijs om daarbij binnen de grenzen van de MOF te blijven. Dan is de koppeling naar MDE en MDA betrekkelijk makkelijk te maken. En er moet voor gezorgd worden dat de gebruikte modelleertalen en -technieken open zijn, zodat de resulterende artefacten (de modellen dus) hun waarde behouden, en niet geboden zijn aan een of andere esoterische aanpak, die niemand meer snapt na het vertrek van de goeroe van dienst.
Datzelfde (vermijding van lock-in) is nog belangrijker als het gaat om de verwerking van die modellen. Dat kan grofweg op twee manieren; handmatig, of geautomatiseerd via de MDA/MDE-route. Of een combinatie.
Eigenlijk maakt het niet zoveel uit of hoe het gebeurt. Want in beide gevallen moet de specificatie precies en volledig zijn. Bij een automatsiche realisatie is dat evident, maar bij een handmatige is het ook essentieel, omdat die steeds meer elders (in India of waar dan ook) plaatsvindt. De dagen van de halfzachte analyse, waarbij een groot deel van de specificatie in de bouwfase werd gemaakt (met alle problemen van dien) zijn over. Dat stelt duidelijk andere eisen aan de wijze van specificeren en analyseren dan we gewend zijn.
Bij een automatische realisatie is het cruciaal dat de modellen NIET op het MDA-traject zijn toegesneden. Zijn ze dat wel, dan zijn ze in feite tool-afhankelijk geworden, waarmee toch lock-in het resultaat zou zijn. En dat mag niet. Het MDA/MDE-proces dient dus zo te zijn opgezet, dat de platform- en toolonafhankelijkheid van de domeinmodellen verzekerd is, terwijl ze wel compleet zijn. (Dit sluit in de praktijk en aantal MDA-tools uit, omdat daar de PSM gebruikt wordt zowel voor platformspecifieke zaken als voor detaillering van het business-domein. Dat is belachelijk, en die tools dienen vermeden te worden.)
In de praktijk zal de realisatie in een aantal transformatie-stappen plaatsvinden, volgens het DAI-principe (Domein, Architectuur, Implementatie). De MDSD-aanpak voldoet min of meer hieraan, en er zijn inmiddels ook verscheidene tools die een voldoende flexibele M2M transformatie bieden (Borland, OAW, MIA, ArcStyler nb lijken alle bruikbaar). Een van de lastige dingen is ongetwijfeld het noodzakelijke "weaven" van deel-modellen. In de meeste MDA-aanpakken zit dat (nog) niet verwerkt, maar het is wel nodig. Gelukkig biedt hier Aspect-Orientatie (AOP, AOSD) oplossingen, en AOSD moet ook in de MDE-techniek geintegreerd worden. (MDSD doet dat trouwens ook.)
De werkwijze en inrichting van het transformatieproces moet natuurlijk flexibel maar ook open zijn, dit laatste om portabiliteit van het ene naar het andere tool mogelijk te maken. Als een transformatieproces een balck box is, is dat natuurlijk heel lastig, maar als duidelijk is hoe het werkt, is een overzetting naar een ander tool wel haalbaar. Sterker: als de trnasformaties zijn beschreven in de QVT-standaard (als dat inderdaad de standaard wordt), zijn ze waarschijnlijk herbruikbaar.
Het doel is hier: zoveel mogelijk abstractie van de concrete tooling. De MDA-standaard zou dit mogelijk moeten maken, maar het zal nog wl even duren eer die MDA-transformaties echt een "commodity" zijn geworden, en de tooling er niet meer toe doet.
We zijn eruit: dit is de oplossing. :)
De volgende keer over de IT-organisatie, SaaS en SaaSaaS. En ik zal ook een aantal thema's die hierboven zijn aangeroerd, uitdiepen.
Bijvoorbeeld:
- hoe moet je domeinmodelleren om dit alles mogelijk te maken?
- wat zijn de mogelijkheden en onmogelijkheden van UML?
- wat moeten we met DSLs?
- past legacy hier wel in, en zo ja, hoe dan?
Dat komt dus nog.
- er zijn standaards nodig, zowel op technisch als op "semantisch" (dwz: vwb het probleemdomein) gebied
- er is een manier van beschrijven van systemen nodig die het uitbesteden van systeemontwikkeling en -beheer, bv via outsourcing of offshoring makkelijker maakt
- de wijze van specificeren moet ervoor zorgen dat de problemen voortvloeiende uit "glue code" zoveel mogelijk worden vermeden
- er moet een manier zijn om bestaande software (legacy) in de SaaS-opzet te betrekken.
Is dat mogelijk? Ja, ik denk het wel.
We zijn al een heel stuk verder als we een (abstracte) taal hebben, die het mogelijk maakt een probleem domein (bijvoorbeeld een business-domein) te beschrijven to the point en zonder redundantie. Voorts moeten we in staat zijn een beschrijving in die taal te gebruiken voor een implementatie, zonder dat nadere informatie nodig is. Je kunt een specificatie dan gebruiken voor een automatische implementatie, maar ook voor de specificatie van een extern (bv via outsourcing) te realiseren systeem. De taal moet dus onafhankelijk zijn van de wijze van implementatie, maar ook van het platform van implementatie. Zo wordt lock-in vermeden. En de taal moet geschikt zijn om bestaande legacy-software in te beschrijven, alsmede "semantische" standaarden bevatten of in ieder geval mogelijk maken.
Zo, dat is nogal wat. Maar het kan wel. We zijn er in ieder geval vlak bij.
Voor de domeinbeschrijving is het mogelijk om met OO en UML een heel eind te komen. Inderdaad, UML is niet helemaal niet compleet: de beschrijving van gedrag is moeilijk, en UML bevat ook veel overbodige onzin (use cases!), maar die hoef je natuurlijk niet te gebruiken. Maar de basis is er, en met goed gekozen aanvullingen is OO-UML bruikbaar.
Die aanvullingen liggen op de volgende gebieden:
- beschrijving gedrag. UML is hiervoor onvoldoende. Er is een Action Language (een soort pseudo-code) nodig om gedragsbeschrijvingen bruikbaar te maken. Een subset van een gewone programmeertaal (bv Java of Ruby) is afdoende.
- een standaard voor het koppelen van de domeinmodellen. Een aspect van een domein wordt apart beschreven (later daarover meer), maar om een domein compleet te beschrijven is in feite een soort "meta-taal" nodig die beschrijft hoe modellen met elkaar samen (kunnen) hangen. Aspect-orientatie, MDSM, MDE en ook technieken als UML with color bieden bieden hiervoor mogelijkheden.
- een standaard semantiek die de gebruikte concepten beschrijft op een dusdanige wijze dat ze over de (deel)domeinen hetzelfde zijn. Voor SaaS is dat utieraard cruciaal. Hiervoor zijn verscheidene aanzetten, waarvan sommige varen onder de prachtige vlag van de "web ontology". Schitterend buzzword. Het is verstandig om een schuin oog op deze ontwikkelingen gericht te houden, maar het is niet nodig om erop te wachten. In de prakiek zijn allen OO-standaardmodellen voor business-domeinen ongeveer hetzelfde, en iig makkelijk naar elkaar te transformeren.
- eventueel kunnen naast UML DSLs gebruikt worden voor specfieke deelterreinen, zolang de koppeling met UML maar te maken is. Een voorbeeld hiervan is BPMN voor het modelleren van processen.
Wat wel van belang is; als uitbreidingen worden gemaakt, dan is het wijs om daarbij binnen de grenzen van de MOF te blijven. Dan is de koppeling naar MDE en MDA betrekkelijk makkelijk te maken. En er moet voor gezorgd worden dat de gebruikte modelleertalen en -technieken open zijn, zodat de resulterende artefacten (de modellen dus) hun waarde behouden, en niet geboden zijn aan een of andere esoterische aanpak, die niemand meer snapt na het vertrek van de goeroe van dienst.
Datzelfde (vermijding van lock-in) is nog belangrijker als het gaat om de verwerking van die modellen. Dat kan grofweg op twee manieren; handmatig, of geautomatiseerd via de MDA/MDE-route. Of een combinatie.
Eigenlijk maakt het niet zoveel uit of hoe het gebeurt. Want in beide gevallen moet de specificatie precies en volledig zijn. Bij een automatsiche realisatie is dat evident, maar bij een handmatige is het ook essentieel, omdat die steeds meer elders (in India of waar dan ook) plaatsvindt. De dagen van de halfzachte analyse, waarbij een groot deel van de specificatie in de bouwfase werd gemaakt (met alle problemen van dien) zijn over. Dat stelt duidelijk andere eisen aan de wijze van specificeren en analyseren dan we gewend zijn.
Bij een automatische realisatie is het cruciaal dat de modellen NIET op het MDA-traject zijn toegesneden. Zijn ze dat wel, dan zijn ze in feite tool-afhankelijk geworden, waarmee toch lock-in het resultaat zou zijn. En dat mag niet. Het MDA/MDE-proces dient dus zo te zijn opgezet, dat de platform- en toolonafhankelijkheid van de domeinmodellen verzekerd is, terwijl ze wel compleet zijn. (Dit sluit in de praktijk en aantal MDA-tools uit, omdat daar de PSM gebruikt wordt zowel voor platformspecifieke zaken als voor detaillering van het business-domein. Dat is belachelijk, en die tools dienen vermeden te worden.)
In de praktijk zal de realisatie in een aantal transformatie-stappen plaatsvinden, volgens het DAI-principe (Domein, Architectuur, Implementatie). De MDSD-aanpak voldoet min of meer hieraan, en er zijn inmiddels ook verscheidene tools die een voldoende flexibele M2M transformatie bieden (Borland, OAW, MIA, ArcStyler nb lijken alle bruikbaar). Een van de lastige dingen is ongetwijfeld het noodzakelijke "weaven" van deel-modellen. In de meeste MDA-aanpakken zit dat (nog) niet verwerkt, maar het is wel nodig. Gelukkig biedt hier Aspect-Orientatie (AOP, AOSD) oplossingen, en AOSD moet ook in de MDE-techniek geintegreerd worden. (MDSD doet dat trouwens ook.)
De werkwijze en inrichting van het transformatieproces moet natuurlijk flexibel maar ook open zijn, dit laatste om portabiliteit van het ene naar het andere tool mogelijk te maken. Als een transformatieproces een balck box is, is dat natuurlijk heel lastig, maar als duidelijk is hoe het werkt, is een overzetting naar een ander tool wel haalbaar. Sterker: als de trnasformaties zijn beschreven in de QVT-standaard (als dat inderdaad de standaard wordt), zijn ze waarschijnlijk herbruikbaar.
Het doel is hier: zoveel mogelijk abstractie van de concrete tooling. De MDA-standaard zou dit mogelijk moeten maken, maar het zal nog wl even duren eer die MDA-transformaties echt een "commodity" zijn geworden, en de tooling er niet meer toe doet.
We zijn eruit: dit is de oplossing. :)
De volgende keer over de IT-organisatie, SaaS en SaaSaaS. En ik zal ook een aantal thema's die hierboven zijn aangeroerd, uitdiepen.
Bijvoorbeeld:
- hoe moet je domeinmodelleren om dit alles mogelijk te maken?
- wat zijn de mogelijkheden en onmogelijkheden van UML?
- wat moeten we met DSLs?
- past legacy hier wel in, en zo ja, hoe dan?
Dat komt dus nog.
donderdag 2 augustus 2007
Voelter's blog
SaaS en SOA, hypes die voorbijgaan?
Will SOA still be ‘SOA’ five years from now?
Nee, zegt Joe McKendrick. SOA zal alomtegenwoordig zijn, net als GUIs dat al zijn, en Webservices bezig zijn het te worden.
Hij heeft daarin gelijk, maar er is nog een andere reden waarom SOA snel weer hype-af zal zijn. De SOA hype is een interne IT-hype, eigenlijk alleen interessant voor software-architecten, developers, etc. SOA is een architectuur die "services" mogelijk maakt (en zelfs dat is niet helemaal waar: het is mogelijk services te leveren of zelfs te consumeren zonder een echte SOA). Maar een SOA brengt helemaal neit noodzakelijk gebruik of beschikbaarstelling van services as vanzelf met zich mee, laat staan dat dat zal leiden tot de business-voordelen die klanten wordt beloofd.
SOA is eigenlijk het zoveelste voorbeeld waarbij een technische vernieuwing zonder meer als een business-voordeel wordt verkocht. De pretentie wordt natuurlijk niet waargemaakt, en vervolgens zijn we verbaasd als men cynisch wordt over de prachtige vergezichten die door de IT steeds worden geschilderd.
SaaS is een echte belofte, voor de business, en vooral voor de organisatie (en daarmee de kosten) van de IT. Om SaaS waar te kunnen maken, is er een SOA nodig. Dat is alles.
Link naar Phil Wainewright
Ik heb de blog van Phil Wainewright als link toegevoegd aan de link-lijst.
woensdag 1 augustus 2007
Is Web 2.0 eng?
William Davies heeft een aardig verhaal op The Register, over Web 2.0. Hij vergelijkt het met de "koude benadering" door o.m. Gary Becker van het niet-economische leven. Davies vindt het blijkbaar heel verkeerd dat Becker c.s. allerlei rationele (dwz; gedreven door eigenbelang) motieven onderzoeken in (ook) het sociale gedrag van mensen. Ik snap Davies niet zo: volgens mij heeft Becker gewoon gelijk.
Maar goed, Davies' waarnemingen over Web 2.0 snijden wel enigszins hout. Je ziet inderdaad niet alleen een technologisering van het sociale leven, maar ook een economisering. Alleen: ik denk dat dat niet erg is, omdat die economisering niet verder zal gaan dan hij eigenlijk toch al ging. Web 2.0 maakt het alleen expliciet en zichtbaar.
Maar goed, Davies' waarnemingen over Web 2.0 snijden wel enigszins hout. Je ziet inderdaad niet alleen een technologisering van het sociale leven, maar ook een economisering. Alleen: ik denk dat dat niet erg is, omdat die economisering niet verder zal gaan dan hij eigenlijk toch al ging. Web 2.0 maakt het alleen expliciet en zichtbaar.
Abonneren op:
Posts (Atom)