Willem reageert op de vorige post terecht:
“Dus als tool vast handig, maar we zijn niet meer op zoek naar losse tools.”
Dus daar zijn jullie het al over eens? Voor mij is dat nog steeds de vraag:
Een aantal losse tools die heel goed zijn in waar ze voor gebouwd zijn en ook niet meer dan dat heeft ook zo z’n voordelen! Als al die losse tools dan vervolgens maar goed met elkaar kunnen “babbelen”.
De kern zit hem zeker in het “babbelen”!
Maar eerst even de spagaat toelichten: Aan de ene kant is gebleken dat grote monsterapplicaties die alles willen kunnen, niet werken. Na verloop van tijd worden ze te complex om snel te kunnen aanpassen aan veranderende processen. Aan de andere kant: als je voor elk stukje functionaliteit een tool in huis haalt, dan is door de wildgroei het totaal niet meer te beheersen. Daarnaast hebben leveranciers van tools de neiging om de functionaliteit uit te breiden, per stuk te portaliseren en voor je het weet zit je met een heel portal-landschap van applicaties die min of meer hetzelfde kunnen.
Nu het babbelen: oudere tools kunnen vaak wel babbelen met elkaar door bijvoorbeeld database connecties of interfaces tussen 2 tools te bouwen. Nadeel: per combinatie van tool is dit vaak custom werk.
Wat nu als de manier van het babbelen bij voorbaat is gedefinieerd? Dan is er per tool maar 1 interface te bouwen. Tussen de tool en de babbelstandaard en niet tussen elke mogelijke combinatie van tools.
Dit is er natuurlijk al lang, zie SOA en webservices.
Dan zouden tools zich kunnen beperken tot één ding waar ze goed in zijn, en dat als een service aanbieden. Van leveranciers vraag je dan geen los te distribueren applicatie, maar een webservice die gepubliceerd wordt voor je andere webservices.
Zoals Google gaat doen door zijn API nog meer open te stellen waardoor straks websites webservices kunnen koppelen aan Google tools. De specifieke functionaliteit van een tool wordt hiermee gehangen in een groter geheel (van Google).
