Vanuit de "less is more" gedachte zou je kunnen denken dat, bij voldoende geschiktheid, minder dienstaanbieders de voorkeur verdienen boven meer dienstaanbieders. Wanneer je bijvoorbeeld kunt kiezen tussen de aanschaf van 1 grote softwareapplicatie of de aanschaf van meerdere kleinere applicaties (die onderling op elkaar afgestemd moeten worden) dat een "all-in-one" variant logischerwijs de voorkeur verdient.
De praktijk is helaas wat minder eenvoudig. Bepalen wat het optimale aantal componenten is om bepaalde diensten te verkrijgen is lastiger dan je misschien zou denken. Roger Sessions, iemand op wie ik later terugkom, heeft speciaal hiervoor de "Simple Iterative Partitions" methode ontwikkeld. Bedoeld om zo objectief mogelijk vast te stellen welk aantal componenten gaat leiden tot een minimale hoeveelheid complexiteit. En dat is niet per definitie de situatie waarin het aantal componenten zo klein mogelijk is. Oftewel: less is helaas niet altijd more.
Los van het aantal componenten waar je op uitkomt, is het altijd nuttig om in termen van diensten te blijven denken. Ook wanneer een all-in-one component meerdere diensten levert. Juist dan is het raadzaam om niet alleen te beoordelen of aanwezige diensten met elkaar overweg kunnen (dat zit meestal wel goed), maar juist ook of er een goede samenwerking met externe diensten mogelijk is. Want de "all" in "all-in-one" bestaat haast niet meer. En de kans is groot dat je in de toekomst een of meer aanwezige diensten door een andere dienstenaanbieder wil laten verzorgen.
Het bepalen van het juiste aantal componenten voor het leveren van diensten is niet alleen bij softwarekeuzes maar ook op andere terreinen van toepassing. Bijvoorbeeld als het gaat om het bepalen van het aantal gewenste schakels bij ketensamenwerking. Of bij (de)centralisatievraagstukken. Eigenlijk in alle situaties waarin je moet bepalen wat de ideale schaalgrootte van samenwerkende onderdelen moet zijn om de benodigde diensten zo goed mogelijk te kunnen gaan leveren.
Dus is less more? Ja. Als gewenste diensten voldoende of zelfs beter kunnen worden geleverd door minder componenten te gebruiken dan is less zeker more. Maar andersom kan ook gelden dat wanneer er te veel diensten in een te klein aantal componenten zijn geperst, dat more more is.
