donderdag 15 november 2007

SOA als kathedraal

Keith Harrison-Broninksi (ja, zo heet ie echt) maakt een leuke vergelijking tussen een SOA (althans de middleware van een SOA) en een kathedraal uit de middeleeuwen. En zijn punt is: de vergelijking gaat mank.

Natuurlijk. Maar daarna wordt het interessant, want zijn punt is eigenlijk: als we een SOA bouwen, en de bijbehorende middleware installeren, dan trekken we een wissel op de toekomst. Want dat gaat alleen werken met een zekere mate van kost-effectiviteit als men zich houdt aan de ontwerp-principes en -richtlijnen, en er adequate tooling is om dat alles te beheren. En dat gaat niet gebeuren. Die tooling is er niet, en voor wat betreft die ontwerp-principes: we weten neit hoe zo'n SOA zich zal moeten ontwikkelen, en dat is ook niet te voorspellen, omdat er per definitie allerlei nu nog onbekende partijen bij zijn betrokken, etc, etc.

Inderdaad. En ik voeg daar aan toe: we weten eigenlijk niet eens wat die ontwerp-principes dan wel zijn, laat staan dat we ze toepassen.

Ik weet niet of Keith H-B het met me eens is, maar ik trek hieruit de conclusie: het is (in het algemeen) onverstandig nu zwaar te investeren in een SOA of in een ESB, tenzij die investeringen op zeer korte termijn al worden terugverdiend. Als dat niet zo is, moet een aanpak worden gekozen waarbij wel zo goed mogelijk services worden ontworpen en geimplementeerd, en waarbij een zo eenvoudig mogelijke ESB wordt geïmplementeerd, als zoiets al nodig is.

Zowel in het design als in de tooling moet rekening gehouden worden met het feit dat de wereld er morgen wel eens fors anders uit kan zien.

Een goede aanpak is om te nu al te onderzoeken hoeveel eigenlijk via een SaaS-oplossing buiten de deur kan worden gelegd. Vaak zal dat nu al de beste en goedkoopste oplossing blijken, maar zelfs als dat niet zo is, is het toch verstandig om daarop te anticiperen. Het maakt een latere overgang naar SaaS makkelijker, en vooral: je blijft zo dicht bij de ontwikkerichting van de standaarden. Want die zullen uiteraard vooral door de SaaS-oplossingen worden bepaald, omdat daar interoperabiliteit het hoogste is.

Geen opmerkingen: