De Stem der Rede zei:
"Ironick zegt: "It is services thinking, as conventionally understood, that led to the mess in which we find ourselves: fragmentation caused by entity-specific (service) interfaces".
Een mooie volzin, maar ik denk dat maar weinigen snappen wat hier wordt bedoeld. Dat het in de de IT moet gaan over "services", dat snappen we. Dat deze services WOA compliant in plaats van SOA compliant moeten zijn, dat kunnen software architecten - behalve elkaar - maar moeilijk uitleggen."
En vervolgens wordt mij om een uitleg gevraagd.
Het probleem zit m hier in het begrip "services". Moet het in de IT om de "services" gaan? Sja, dat hangt af wat er mee bedoeld wordt. In SOA in ieder geval wel: daar zijn de services doorgaans het uitgangspunt voor het ontwerp.
Je wordt verondersteld na te denken over welke services er zouden moeten zijn, en als je die eenmaal hebt bedacht, ze volgens de regelen der kunst(autonomie, stateless, etc, etc) te ontwerpen. Maar hoe bedenk je eigenlijk die services? Dat blijft schimmig. De beste manier is om dat te doen vanuit een objectmodel, waarbij de interfaces tussen de objecten worden getransformeerd naar services. Dit kan, en het werkt, alleen doet bijna niemand het.
In plaats daarvan zit men services uit de duim te zuigen, of ze te ontwerpen op basis van wat op dat moment nodig lijkt vanuit een of ander proces, of (nog erger) op basis van wat een bestaande legacy-component biedt. Het gevolg zijn services die ontworpen zijn vanuit de huidige behoefte of zelfs de behoefte (en de architectuur) van het verleden. De kans dat dit in de toekomst andersoortig gebruik vergemakkelijkt (de belofte van SOA tenslotte) is nihil.
Als dit klinkt als een slecht verhaal: dat kan kloppen, want het is een slecht verhaal.
Bij de WOA (of de ROA, dat is wat mij betreft hetzelfde) ontwerp je vanuit resources, zeg maar de gegevensstructuur. Ook als er geen expliciet object- of datamodel wordt gemaakt, moet je als je RESTful werkt een resource-structuur hebben. En het aardige is dat je daarbij weliswaar heel veel fout kunt doen, maar dat er vrijwel altijd toch een bruikbare structuur ontstaat, waarop de resource-oriented services makkelijk te ontwerpen zijn.
En die resource-oriented services zijn veel makkelijker te gebruiken op een manier die niet is voorzien, juist omdat ze zo simpel zijn: een resource kan op een aantal manieren informatie ter beschikking stellen, je kunt nieuwe informatie erin stoppen, je kunt een nieuwe resource van een bepaald type maken en vullen, en je kunt een resource verwijderen. Dat is het wel zo'n beetje.
Makkelijk te begrijpen, en makkelijk te hergebruiken, aangenomen dat de resource-definitie en -structuur ergens op slaat.
Korte samenvatting: de SOA route vereist teveel kennis en strategie van de IT-experts. Als je een goed model maakt en dat model op de geode manier vertaald in services, gaat het goed. Maar dat doet men dus niet.
De WOA-route is veel meer fool-proof. Daar moet men echt heel erg zijn best doen om er helemaal onbruikbare services uit te laten rollen.
Er zijn nog een paar andere voordelen van WOA/ROA, maar het door Ironick genoemde argument komt op het bovenstaande neer.
maandag 19 januari 2009
vrijdag 16 januari 2009
SOA is dood, deel 3
De Stem der Rede zegt:
"Het denken in eilanden/domeinen in plaats van enterprise wide is overigens een idee dat ook door de WS-* adepten worden aangehangen. Er lopen dus twee discussies door elkaar: 1) het moet domein gewijs in plaats van enterprise wide; 2) het moet RESTful in plaats van WS-*."
Ja, dat is zo. Maar die twee discussies hangen wel nauw met elkaar samen, in ieder geval volgens de restafari's.
Stel: je wilt "eilandgewijs" ontwikkelen, en je doet dat volgens WS-*. Hoe moeten die interfaces van die eilanden er dan uitzien? Hier zijn 2 mogelijke antwoorden op:
1. je gaat uit van het nu voorziene gebruik van het eiland, en op basis daarvan maak je een interface. Zoals bekend zal je dan niet een interface krijgen wat voor andere doeleinden bruikbaar is dan het oorspronkelijk voorziene doel. Dit zal de bruikbaarheid dus nadelig beïnvloeden.
2. je maakt een of ander model, waarmee je de betekenis voor het te ontwikkelen eiland voor de omgeving beschrijft. Met andere woorden: je brengt de omgeving van het eiland, en daarmee ook de plaatsen voor de zinvolle bruggen, in kaart. Dit is een veel beter idee, maar het nadeel is wel dat je niet alleen het eiland, maar ook de omgeving aan het ontwerpen bent. Dit tendeert dus al snel naar een enterprise-wide ontwerp, zeker als het in het detail moet wat nodig is voor het ontwerpen van WS-* interfaces.
Maakt de introductie van REST dit veel beter? Ja, om een paar redenen.
a. REST dwingt je (min of meer) om een resource-structuur te ontwerpen. Zelfs als je geen idee hebt van de omgeving, krijg je zo toch een ieder geval voor de basale handelingen herbruikbaar interface, ook als dat hergebruik niet plaatsvindt op de voorziene manier.
Anders gezegd: WS-* tendeert naar een functioneel interface, en moet dus ontworpen worden vanuit het nu bekende of voorziene gebruik. REST tendeert naar een interface ontworpen vanuit de resource-structuur (dat komt in de praktijk neer op de logische datastructuur), en dat is veel meer onafhankelijk van het nu bekende of voorziene gebruik.
Natuurlijk is het mogelijk die resource-gerichte aanpak ook in WS-* te gebruiken, maar dan komt het tweede voordeel van REST:
b. REST-interfaces maken gebruik van URI's en de bekende HTTP-methods. Dat is makkelijker te gebruiken dan WS-* interfaces.
Ook dit voordeel is natuurlijk te bereiken in WS-*, alleen: dan heb je REST nagebouwd in WS-*. Waarom zou je dat doen? Dan kun je beter gelijk REST gebruiken, want de voordelen van WS-* boven REST gebruik je toch niet meer.
Dus: WS-* is eigenlijk alleen goed te doen als je een enterprise wide aanpak gebruikt. Als je dat niet doet, zal de herbruikbaarheid zwaar lijden. Bij REST is dat niet nodig. RESTful eilandautomatisering leidt nog steeds tot behoorlijk herbruikbare ontwerpen.
"Het denken in eilanden/domeinen in plaats van enterprise wide is overigens een idee dat ook door de WS-* adepten worden aangehangen. Er lopen dus twee discussies door elkaar: 1) het moet domein gewijs in plaats van enterprise wide; 2) het moet RESTful in plaats van WS-*."
Ja, dat is zo. Maar die twee discussies hangen wel nauw met elkaar samen, in ieder geval volgens de restafari's.
Stel: je wilt "eilandgewijs" ontwikkelen, en je doet dat volgens WS-*. Hoe moeten die interfaces van die eilanden er dan uitzien? Hier zijn 2 mogelijke antwoorden op:
1. je gaat uit van het nu voorziene gebruik van het eiland, en op basis daarvan maak je een interface. Zoals bekend zal je dan niet een interface krijgen wat voor andere doeleinden bruikbaar is dan het oorspronkelijk voorziene doel. Dit zal de bruikbaarheid dus nadelig beïnvloeden.
2. je maakt een of ander model, waarmee je de betekenis voor het te ontwikkelen eiland voor de omgeving beschrijft. Met andere woorden: je brengt de omgeving van het eiland, en daarmee ook de plaatsen voor de zinvolle bruggen, in kaart. Dit is een veel beter idee, maar het nadeel is wel dat je niet alleen het eiland, maar ook de omgeving aan het ontwerpen bent. Dit tendeert dus al snel naar een enterprise-wide ontwerp, zeker als het in het detail moet wat nodig is voor het ontwerpen van WS-* interfaces.
Maakt de introductie van REST dit veel beter? Ja, om een paar redenen.
a. REST dwingt je (min of meer) om een resource-structuur te ontwerpen. Zelfs als je geen idee hebt van de omgeving, krijg je zo toch een ieder geval voor de basale handelingen herbruikbaar interface, ook als dat hergebruik niet plaatsvindt op de voorziene manier.
Anders gezegd: WS-* tendeert naar een functioneel interface, en moet dus ontworpen worden vanuit het nu bekende of voorziene gebruik. REST tendeert naar een interface ontworpen vanuit de resource-structuur (dat komt in de praktijk neer op de logische datastructuur), en dat is veel meer onafhankelijk van het nu bekende of voorziene gebruik.
Natuurlijk is het mogelijk die resource-gerichte aanpak ook in WS-* te gebruiken, maar dan komt het tweede voordeel van REST:
b. REST-interfaces maken gebruik van URI's en de bekende HTTP-methods. Dat is makkelijker te gebruiken dan WS-* interfaces.
Ook dit voordeel is natuurlijk te bereiken in WS-*, alleen: dan heb je REST nagebouwd in WS-*. Waarom zou je dat doen? Dan kun je beter gelijk REST gebruiken, want de voordelen van WS-* boven REST gebruik je toch niet meer.
Dus: WS-* is eigenlijk alleen goed te doen als je een enterprise wide aanpak gebruikt. Als je dat niet doet, zal de herbruikbaarheid zwaar lijden. Bij REST is dat niet nodig. RESTful eilandautomatisering leidt nog steeds tot behoorlijk herbruikbare ontwerpen.
zaterdag 10 januari 2009
SOA is dood, deel 2
Stefan Tilkov geeft zijn mening.
Samenvatting: SOA bevatte veel goede ideeën, maar het idee dat het allemaal in enterprisewide moest is verkeerd. Hij wil SOA als eilandautomatisering, maar dan wel met bruggen: stukje bij beetje, met standaardinterfaces. RESTful dus.
En ik ben het met hem eens, maar dat zal geen verrassing zijn.
Samenvatting: SOA bevatte veel goede ideeën, maar het idee dat het allemaal in enterprisewide moest is verkeerd. Hij wil SOA als eilandautomatisering, maar dan wel met bruggen: stukje bij beetje, met standaardinterfaces. RESTful dus.
En ik ben het met hem eens, maar dat zal geen verrassing zijn.
donderdag 8 januari 2009
SOA is dood
per 1 januari j.l., volgens Anne Thomas Manes. Ik ben het er wel zo'n beetje mee eens, maar die slotconclusie: het gaat om "services" is mij veel te vaag. Daar schieten we niks mee op.
En ik vind haar ook te mild over de claims dat SOA vooral door de organisatie moet worden gedragen, etc. Dat is niet de oplossing, dat is juist het probleem. Organisaties moeten geen IT-architecturen dragen. Als dat nodig is, deugen die architecturen niet.
Aanvulling (via InfoQ): Ironick verwoordt vrij precies hoe het echt zit. SOA wordt ingehaald door het Web, of de WOA, zo u wilt.
En ik vind haar ook te mild over de claims dat SOA vooral door de organisatie moet worden gedragen, etc. Dat is niet de oplossing, dat is juist het probleem. Organisaties moeten geen IT-architecturen dragen. Als dat nodig is, deugen die architecturen niet.
Aanvulling (via InfoQ): Ironick verwoordt vrij precies hoe het echt zit. SOA wordt ingehaald door het Web, of de WOA, zo u wilt.
maandag 29 december 2008
Links als objecten
En dan dit pleidooi (via Tim O'Reilly) voor links als first class object. Van Ian Bicking.
Doet denken aan de "smart pointers" indertijd om de persistency laag in OO min of meer transparant te maken.
Doet denken aan de "smart pointers" indertijd om de persistency laag in OO min of meer transparant te maken.
vrijdag 19 december 2008
REST en linking
vrijdag 12 december 2008
Een kritische noot
Een zekere Jeffrey Lindsay van een onderzoeksbedrijf Bernstein heeft een rapport geschreven waarin hij een paar kritische noten over SaaS en cloud computing maakt. Ik heb het rapport zelf niet gelezen, wel de samenvatting van Larry Dignan op ZDnet.
Kritiek is natuurlijk altijd welkom, maar dit is toch wel een beetje een raar verhaal. Als ik het goed begrijp, komt zijn kritiek op het volgende neer:
1. bedrijven doen het (cloud computing) nog niet of nauwelijks, want eigen machinerie is sneller, ze hebben geen zin om applicaties en documenten om te zetten, enz.
2. de leveranciers verdienen er ook weinig geld aan, zie Amazon dat (nog) niet erg veel geld genereert uit AWS. (Lindsay vermoedt dat Amazon het ook niet doet voor de revenuen, maar voor het imago, waardoor ze betere developers kunnen aantrekken, etc).
En de conclusie is dat het allemaal wel meevalt, en dat cloud computing wel gebruikt zal worden, maar beperkt en in een hybride model. Hij zeg bv dat Google Apps niet meer dan 10% van de MS office licenties af zal snoepen. (Dat is natuurlijk flauw, want naast Google Apps zijn er meer leveranciers van cloud-offices: ZoHo bijvoorbeeld, en ook MS zelf.)
Ik vind het een vreemd verhaal, want het lijkt alsof Lindsay de clou niet heeft begrepen. Inderdaad, cloud leveranciers verdienen niet ontzettend veel geld. En dat is niet alleen een aanloopverschijnsel, dat blijft zo. Gezien vanuit IT-leveranciers is dat natuurlijk raar, want waarom zou je er dan aan beginnen? Maar gezien vanuit de klanten betekent het dat de prijzen laag zijn en blijven, en dat cloud computing dus veel goedkoper is dan "eigen IT". En ja, het zal hier en daar wat minder makkelijk zzijn, en je moet documenten converteren, maar als je het niet doet, verlies je van de concurrent die wel overstapt op de cloud. Want het kostenvoordeel is gigantisch.
Dus op korte termijn zal hij wel gelijk hebben: bijna niemand stapt in één keer over, en vrijwel iedereen blijft voorlopig gedeeltelijk "eigen IT" gebruiken. Maar op wat langere termijn is de impact (waarschijnlijk, want ik heb d wijsheid ook niet in pacht) zeer groot. Niet alleen voor het goedkoper maken van bestaande produkten en diensten, maar vooral ook doordat hierdoor nieuwe produkten en diensten mogelijk worden, en ongetwijfeld, zoals dat gaat oude verdringen.
En wat betreft Amazon: ik ben ervan overtuigd dat AWS niet zomaar een aardigheidje is. Drie redenen:
1. Amazon kan hierdoor de voor het "oude bedrijf" benodigde capaciteit extra benutten en dus goedkoper maken.
2. Amazon leverde in feite voor derde partijen (tweede hands verkopers e.d.) eigenlijk al een click-in business model: niet alleen de catalogus, ook de betaalservice, soms delivery, enzovoort. AWS is een logische uitbreiding daarop.
3. Amazon zit voor wat betreft het "oude bedrijf" in de levering van content: boeken, muziek, enzovoort. Amazon ziet dat dat digitaliseert en via het net zal gaan. Vandaar de verkoop van MP3s, vandaar de Kindle. Maar daarvoor is een Web-infrastructuur nodig, en die is Amazon dan ook aan het opbouwen. Als je die ook door derden laat gebruiken, heb je AWS.
Allemaal logisch dus.
Kritiek is natuurlijk altijd welkom, maar dit is toch wel een beetje een raar verhaal. Als ik het goed begrijp, komt zijn kritiek op het volgende neer:
1. bedrijven doen het (cloud computing) nog niet of nauwelijks, want eigen machinerie is sneller, ze hebben geen zin om applicaties en documenten om te zetten, enz.
2. de leveranciers verdienen er ook weinig geld aan, zie Amazon dat (nog) niet erg veel geld genereert uit AWS. (Lindsay vermoedt dat Amazon het ook niet doet voor de revenuen, maar voor het imago, waardoor ze betere developers kunnen aantrekken, etc).
En de conclusie is dat het allemaal wel meevalt, en dat cloud computing wel gebruikt zal worden, maar beperkt en in een hybride model. Hij zeg bv dat Google Apps niet meer dan 10% van de MS office licenties af zal snoepen. (Dat is natuurlijk flauw, want naast Google Apps zijn er meer leveranciers van cloud-offices: ZoHo bijvoorbeeld, en ook MS zelf.)
Ik vind het een vreemd verhaal, want het lijkt alsof Lindsay de clou niet heeft begrepen. Inderdaad, cloud leveranciers verdienen niet ontzettend veel geld. En dat is niet alleen een aanloopverschijnsel, dat blijft zo. Gezien vanuit IT-leveranciers is dat natuurlijk raar, want waarom zou je er dan aan beginnen? Maar gezien vanuit de klanten betekent het dat de prijzen laag zijn en blijven, en dat cloud computing dus veel goedkoper is dan "eigen IT". En ja, het zal hier en daar wat minder makkelijk zzijn, en je moet documenten converteren, maar als je het niet doet, verlies je van de concurrent die wel overstapt op de cloud. Want het kostenvoordeel is gigantisch.
Dus op korte termijn zal hij wel gelijk hebben: bijna niemand stapt in één keer over, en vrijwel iedereen blijft voorlopig gedeeltelijk "eigen IT" gebruiken. Maar op wat langere termijn is de impact (waarschijnlijk, want ik heb d wijsheid ook niet in pacht) zeer groot. Niet alleen voor het goedkoper maken van bestaande produkten en diensten, maar vooral ook doordat hierdoor nieuwe produkten en diensten mogelijk worden, en ongetwijfeld, zoals dat gaat oude verdringen.
En wat betreft Amazon: ik ben ervan overtuigd dat AWS niet zomaar een aardigheidje is. Drie redenen:
1. Amazon kan hierdoor de voor het "oude bedrijf" benodigde capaciteit extra benutten en dus goedkoper maken.
2. Amazon leverde in feite voor derde partijen (tweede hands verkopers e.d.) eigenlijk al een click-in business model: niet alleen de catalogus, ook de betaalservice, soms delivery, enzovoort. AWS is een logische uitbreiding daarop.
3. Amazon zit voor wat betreft het "oude bedrijf" in de levering van content: boeken, muziek, enzovoort. Amazon ziet dat dat digitaliseert en via het net zal gaan. Vandaar de verkoop van MP3s, vandaar de Kindle. Maar daarvoor is een Web-infrastructuur nodig, en die is Amazon dan ook aan het opbouwen. Als je die ook door derden laat gebruiken, heb je AWS.
Allemaal logisch dus.
maandag 8 december 2008
Leonard Richardson over RESTful
donderdag 4 december 2008
Java en persistence frameworks
Ibrahim Levent schrijft over de problemen met Java persistence frameworks. Wel aardig, al ben ik het niet altijd met hem eens. Hij lijkt de geschiedenis van deze tools niet goed te kennen (hij denkt dat het allemaal is begonnen met EOF), en er zijn nog wat dingen waarmee ik het niet eens ben (bv punt 14, over die OIDs).Commentaar is ook aardig, ookop de Serverside.
vrijdag 28 november 2008
Creatieve vernietiging
Voorpublicatie:
De Oostenrijks-Amerikaanse econoom Joseph Schumpeter heeft het begrip "creative destruction" geïntroduceerd. Dat hield in dat in een goed functionerende markteconomie steeds aan kapitaalvernietiging wordt gedaan, doordat bestaande bedrijven ter ziele gaan. Maar ze worden vervangen door nieuwe bedrijven die beter, sneller, efficiënter, goedkoper kunnen werken. Voor de bedrijven die verdwijnen is dat natuurlijk rampzalig, maar voor de samenleving als geheel is het juist goed: er treedt innovatie op, de productiviteit stijgt, en de welvaart neemt toe.
De neiging om bestaande bedrijven overeind te houden is dan ook weliswaar begrijpelijk, en voor de direct betrokkenen (eigenaars, werknemers, leveranciers) voordelig, maar op de wat langere duur desastreus. Immers, middelen die gestoken hadden kunnen worden in nieuwe welvaartsverhogende technieken en bedrijven, vloeien nu naar oude bedrijven die op den duur toch het loodje zullen leggen, en hoe dan ook minder produktief zijn dan de nieuwe bedrijven zouden zijn geweest.
Ik moet wel eens aan die "creative destruction" denken als ik deelneem aan de discussies over Service Oriented Architectures (SOA) en legacy integratie. Vaak wordt gezegd dat het mogelijk is om de investeringen in bestaande IT-systemen (de zogenaamde "legacy") te behouden, en toch die systemen op een flexibele wijze en via het web te kunnen gebruiken. Om dat te kunnen bereiken moet men dan een SOA inrichten, en daarbij een Enterprise Service Bus inrichten.
In de praktijk komt hier meestal weinig van terecht. Die SOA en ESB blijken erg ingewikkeld, en bovendien duur. En de voordelen van die "ontsluiting" van de legacy vallen vaak ook tegen, omdat die legacy zich helemaal niet goed als service laat ontsluiten, tenzij nog grotere investeringen worden gedaan.
En nu komen SaaS en cloud computing (ik zal het hierna op één hoop gooien onder de term "SaaS") om de hoek kijken. SaaS zet het business-model zoals dat tot nog toe in de IT opgeld deed op zijn kop. Je betaalt niet meer van te voren (voor een licentie of voor de bouw van maatwerk), maar voor het gebruik: per transactie, per gebruiker per maand, per opgeslagen MB. Standaardfunctionaliteit, afgerekend op gebruik. “Functionaliteit uit de muur”, zogezegd.
De voordelen zijn gigantisch: minder risico (want geen voorinvesteringen), meer mogelijkheden om van systeem of leverancier te veranderen, en vooral: lagere kosten.
Om deze voordelen te boeken moet je wel wat gangbare ideeën over IT overboord zetten. De kracht van SaaS zit in de standaardisatie. Je gaat dezelfde functionaliteit gebruiken als de buurman of concurrent die hetzelfde SaaS-systeem gebruikt. Voor gebruikers die nog leven met de illusie dat hun IT-systeem uniek is en een “strategisch voordeel” oplevert, is dat een forse stap. Aanpassen en customizen van SaaS kan meestal wel, maar is onverstandig. Het is toch weer een voorinvestering.
Ik hoor wel eens de tegenwerping: “Dan ben ik de greep op mijn IT kwijt!” Ja, dat is zo. Als je een blok aan je been kwijt bent, ben je de greep op dat blok kwijt.
Het is wel verstandig om te zorgen dat je niet met huid en haar aan de SaaS-leverancier bent overgeleverd. Dat kan door het maken van een model (een goed object- of datamodel is meestal voldoende) van de informatie die “uitbesteed” wordt. Dat model wordt geprojecteerd op het model van de leverancier, en door zo te werken is het mogelijk om betrekkelijk makkelijk gegevens te converteren, te up- en te downloaden, en dus ook van leverancier te wisselen.
En wat je vooral ook niet moet gaan proberen is de “integratie” van legacy “integreren” met SaaS. Natuurlijk, dat kan wel eens nodig zijn, maar je steeds moet heel goed kijken naar de alternatieven: gewoon niet integreren en los naast elkaar laten staan, of het legacy-systeem zelf ook vervangen door een SaaS-toepassing.
Want SaaS zal, denk ik, leiden tot de “creative destruction” van veel van de bestaande IT-systemen. Ze zullen worden vervangen door het gebruik van SaaS, wat veel goedkoper is, geen risico vormt, nauwelijks investeringen vergt, en de bedrijven niet meer vastklinkt aan enorme IT-systemen en de bijbehorende staf. Dat zal niet in één klap gaan. Sommige systemen zijn nog niet te vervangen, en sommige systemen misschien wel nooit.
Maar je moet wel bereid zijn om die “creative destruction” te laten gebeuren, en niet water in de wijn te doen door bestaande systemen nodeloos en tegen hoge kosten te integreren, en daarmee hun leven te verlengen. Want de concurrent die de radicale keuze maakt, heeft een groot kostenvoordeel, en dat zal op de markt te merken zijn.
De Oostenrijks-Amerikaanse econoom Joseph Schumpeter heeft het begrip "creative destruction" geïntroduceerd. Dat hield in dat in een goed functionerende markteconomie steeds aan kapitaalvernietiging wordt gedaan, doordat bestaande bedrijven ter ziele gaan. Maar ze worden vervangen door nieuwe bedrijven die beter, sneller, efficiënter, goedkoper kunnen werken. Voor de bedrijven die verdwijnen is dat natuurlijk rampzalig, maar voor de samenleving als geheel is het juist goed: er treedt innovatie op, de productiviteit stijgt, en de welvaart neemt toe.
De neiging om bestaande bedrijven overeind te houden is dan ook weliswaar begrijpelijk, en voor de direct betrokkenen (eigenaars, werknemers, leveranciers) voordelig, maar op de wat langere duur desastreus. Immers, middelen die gestoken hadden kunnen worden in nieuwe welvaartsverhogende technieken en bedrijven, vloeien nu naar oude bedrijven die op den duur toch het loodje zullen leggen, en hoe dan ook minder produktief zijn dan de nieuwe bedrijven zouden zijn geweest.
Ik moet wel eens aan die "creative destruction" denken als ik deelneem aan de discussies over Service Oriented Architectures (SOA) en legacy integratie. Vaak wordt gezegd dat het mogelijk is om de investeringen in bestaande IT-systemen (de zogenaamde "legacy") te behouden, en toch die systemen op een flexibele wijze en via het web te kunnen gebruiken. Om dat te kunnen bereiken moet men dan een SOA inrichten, en daarbij een Enterprise Service Bus inrichten.
In de praktijk komt hier meestal weinig van terecht. Die SOA en ESB blijken erg ingewikkeld, en bovendien duur. En de voordelen van die "ontsluiting" van de legacy vallen vaak ook tegen, omdat die legacy zich helemaal niet goed als service laat ontsluiten, tenzij nog grotere investeringen worden gedaan.
En nu komen SaaS en cloud computing (ik zal het hierna op één hoop gooien onder de term "SaaS") om de hoek kijken. SaaS zet het business-model zoals dat tot nog toe in de IT opgeld deed op zijn kop. Je betaalt niet meer van te voren (voor een licentie of voor de bouw van maatwerk), maar voor het gebruik: per transactie, per gebruiker per maand, per opgeslagen MB. Standaardfunctionaliteit, afgerekend op gebruik. “Functionaliteit uit de muur”, zogezegd.
De voordelen zijn gigantisch: minder risico (want geen voorinvesteringen), meer mogelijkheden om van systeem of leverancier te veranderen, en vooral: lagere kosten.
Om deze voordelen te boeken moet je wel wat gangbare ideeën over IT overboord zetten. De kracht van SaaS zit in de standaardisatie. Je gaat dezelfde functionaliteit gebruiken als de buurman of concurrent die hetzelfde SaaS-systeem gebruikt. Voor gebruikers die nog leven met de illusie dat hun IT-systeem uniek is en een “strategisch voordeel” oplevert, is dat een forse stap. Aanpassen en customizen van SaaS kan meestal wel, maar is onverstandig. Het is toch weer een voorinvestering.
Ik hoor wel eens de tegenwerping: “Dan ben ik de greep op mijn IT kwijt!” Ja, dat is zo. Als je een blok aan je been kwijt bent, ben je de greep op dat blok kwijt.
Het is wel verstandig om te zorgen dat je niet met huid en haar aan de SaaS-leverancier bent overgeleverd. Dat kan door het maken van een model (een goed object- of datamodel is meestal voldoende) van de informatie die “uitbesteed” wordt. Dat model wordt geprojecteerd op het model van de leverancier, en door zo te werken is het mogelijk om betrekkelijk makkelijk gegevens te converteren, te up- en te downloaden, en dus ook van leverancier te wisselen.
En wat je vooral ook niet moet gaan proberen is de “integratie” van legacy “integreren” met SaaS. Natuurlijk, dat kan wel eens nodig zijn, maar je steeds moet heel goed kijken naar de alternatieven: gewoon niet integreren en los naast elkaar laten staan, of het legacy-systeem zelf ook vervangen door een SaaS-toepassing.
Want SaaS zal, denk ik, leiden tot de “creative destruction” van veel van de bestaande IT-systemen. Ze zullen worden vervangen door het gebruik van SaaS, wat veel goedkoper is, geen risico vormt, nauwelijks investeringen vergt, en de bedrijven niet meer vastklinkt aan enorme IT-systemen en de bijbehorende staf. Dat zal niet in één klap gaan. Sommige systemen zijn nog niet te vervangen, en sommige systemen misschien wel nooit.
Maar je moet wel bereid zijn om die “creative destruction” te laten gebeuren, en niet water in de wijn te doen door bestaande systemen nodeloos en tegen hoge kosten te integreren, en daarmee hun leven te verlengen. Want de concurrent die de radicale keuze maakt, heeft een groot kostenvoordeel, en dat zal op de markt te merken zijn.
vrijdag 21 november 2008
SOA humor van Gartner
Lachen met Gartner. In ieder geval Frank Kenney heeft blijkbaar ook zijn vraagtekens bij de gangbare SOA.
Abonneren op:
Posts (Atom)