Generieke oplossingen en overgeneralisatie

Een generieke oplossing, zoals één proces voor meerdere producten, is vaak sterk. Echter, wat logisch voelt en vanuit de business of technologie bijna hetzelfde lijkt kan ondoordacht samengevoegd leiden tot complexiteit, hoge kosten en slechte dienstverlening. Wat bepaalt het juiste niveau van generalisatie?

Een fiets, een schip, een vliegtuig, het zijn alle drie vervoermiddelen. Er zijn fietsfabrieken, scheepswerven en vliegtuighangars. In de fysieke wereld is het zonneklaar dat het opzetten van een 'generieke productielijn' voor deze zo verschillende producten een onzinnig idee is.

Maar in de informatietechnologie gaat het met regelmaat toch mis. Soms bijna amusant, ware het niet dat het vaak erg dure missers zijn. In de virtuele wereld is de inhoud onzichtbaar, blijkbaar is het dan gemakkelijker om belangwekkende aspecten over het hoofd te zien. Zo'n aspect duikt later alsnog op en blijkt dan een blocking issue te zijn, een issue waardoor de oplossing niet toepasbaar is. Een patiëntendossier van een aantal ordners in fysieke vorm op tafel maakt een andere indruk dan praten over een elektronische abstractie.
De technologische maakbaarheid komt snel centraal te staan, waarbij de context onvoldoende in beeld is. Er is niet veel te bedenken waar geen ICT-oplossing voor mogelijk is. Althans, theoretisch.

Microsoft besloot om met Windows 8 een grote stap te zetten. Eén generiek besturingssysteem, nog slechts een versie van Windows voor desktop, tablet, telefoon, TV settop box, gaming device etc. Al deze apparaten zijn immers computers. Potentieel viel er veel winst te behalen. Een technisch identieke code-basis en een consistente ervaring voor de gebruiker vormen een verleidelijk perspectief. Maar het bleek te moeilijk. Er ontstonden concessies aan de gebruikservaring, de eisen van de verschillende platformen liepen te zeer uiteen. Na een moeilijke periode heeft Microsoft voor een andere weg gekozen.

Achteraf is vaak gemakkelijk te zien waarom iets geen goed idee was. Interessant is om op zoek te gaan naar achteraf bijna onzichtbare afwegingen waar wel goed is gekozen.

Space-X heeft een voor de hand liggende generalisatie niet gedaan. Een die wel voor enorme problemen had kunnen zorgen. Space-X heeft gekozen voor twee systemen om een raket terug te laten keren. Er is een systeem om een raket verticaal te doen landen. Dat is bijzonder innovatief, zij zijn de eerste die dit kunststuk weten te beheersen. Daarnaast gebruiken ze ook de klassieke aanpak door alleen een capsule in zee te laten plonzen.
Het te accepteren risico is keuzebepalend. Voor bemenste vluchten wordt altijd voor de capsule gekozen. Onbemenste vluchten of onbemenste delen van raketten mogen verticaal landen.
Deze benadering minimaliseert de complexiteit, vergroot de praktische inzetbaarheid en maakt innovatie mogelijk.
De voordelen wegen op tegen de extra kosten die het in gebruik hebben van twee verschillende systemen met zich meebrengt.
Alternatief, had Space X alleen voor de capsule in zee gekozen dan was innovatie en ervaring opdoen met verticaal landen niet mogelijk. Zouden ze alleen voor verticaal landen hebben gekozen dan zou in een vroeg stadium een onhaalbaar en onverifieerbaar niveau van veiligheid praktische inzet onmogelijk maken.

Een gedachtenexperiment. De ultieme verleiding in dit verband zou een 'generieke lander' zijn, een die bemand en onbemand, voor de aarde, de maan en vooruit, ook Mars, kan worden ingezet. Een voorspelbare mislukking. In alle inzetsituaties gaat het om de landing van een raket, daaromheen zijn te veel aspecten te verschillend.

Valt een risico op overgeneralisatie vooraf te onderkennen? Zonder algemene geldigheid of uitputtendheid te claimen, een korte lijst van symptomen van mogelijke overgeneralisatie:

• te verschillend in toepassing - de oplossing wordt voor heel verschillende domeinen gemaakt
• geen relatie tussen domeinen - de oplossing bestrijkt domeinen die niet eerder een relatie hebben
• consessies - de generieke oplossing gaat gepaard met consessies aan de waarde van de producten
• enkelvoudig faalpunt - de oplossing is een enkelvoudig faalpunt (single point of failure) voor meerdere productieketens
• vervlechting - de oplossing verweeft meerdere productieketens die qua business en domeinen verschillend zijn en geen raakvlakken hebben.
• allesomvattend - er is één implementatie, de schaal van de oplossing is gelijk aan de omvang van de organisatie.
• complexe code - de code is erg complex waardoor deze moeilijk onderhoudbaar, testbaar en overdraagbaar is.
• uitzonderingen - er is specifieke code voor producten en uitzonderingen in de generieke oplossing.
• on-testbaar - verwevenheid maakt testen van een nieuwe release vrijwel ondoenlijk.

Generalisatie is bijzonder krachtig - mits goed toegepast. Het kan kostenefficiënt zijn en biedt mogelijk functionaliteit die niet op een andere wijze haalbaar is.

Generalisatie is op een aantal manieren in te vullen:

• Uniek generiek. Eén proces, één instance, waar meerdere producten uit voortkomen.
• Parallellisering. Het meervoudig inrichten van hetzelfde proces, meerdere instances, parallel, waarbij iedere instantie één product voortbrengt. Bijvoorbeeld meerdere klanten van een SaaS aanbieder.
• Generieke basis. Het ontwerpen van een generieke oplossing, een 'romp', die vervolgens met maatwerk wordt aangepast voor de specifieke producten. Bijvoorbeeld verschillende distributies van Linux OS.
• Framework. Er is een generiek 'skelet' waarin specifieke onderdelen ingeplugd worden.

Wanneer kies je voor de generieke oplossing, welke afwegingen zijn te maken? Daarvoor is een aantal handreikingen te geven.

Beschouw de business-waarde en de technologie
Minimaal op een van beide aspecten, business of technologie, moet een aanzienlijk voordeel te behalen zijn. Op het andere aspect mag geen nadeel van betekenis ontstaan.
Een valkuil is de neiging tot samenvoeging van producten of processen omdat deze tot dezelfde categorie behoren. Dat is onvoldoende reden. Een categorisering is (deels) een arbitraire keuze en heeft in zichzelf geen waarde. Een voorbeeld: fietsen en bestek behoren tot dezelfde categorie. Het is namelijk allebei metaal.

Is er een aantoonbaar voordeel in het heden?
Een generieke oplossing is vrijwel altijd duurder in de ontwikkeling dan één specifieke oplossing. Twee specifieke oplossingen kunnen duurder uitvallen dan één generieke oplossing. Eén generieke oplossing kan ook extreem veel duurder zijn dan twee specifieke oplossingen.
Er moet een aantoonbaar voordeel zijn, in het hier en nu, om te beslissen tot een generieke oplossing. Is dat er niet, dan is het waarschijnlijk verstandig om eerst ervaring op te doen met een specifieke oplossing.

Is er een duidelijk en getoetst beeld van de producten?
Er moet een uitgewerkt beeld zijn van de producten en dat moet getoetst zijn in de praktijk voordat een generieke oplossing is te overwegen.
Microsoft had geen ervaring met smartphones en vervlocht deze nieuwe nog onbekende wereld met de doorontwikkeling van een bestaand product (Windows). Vervlechting reduceert keuzevrijheid, tijdens de ontwerpfase van een nieuw product is dat onacceptabel.

Beschouw de doorontwikkeling
Is de generieke oplossing toekomstbestendig voor de ontwikkelingen die te verwachten zijn voor alle producten die er op gebaseerd worden? Mogelijk is het nu een prima aanpak, maar blokkeert het verdere ontwikkeling.

Beschouw de maximale impact van verstoringen
Een generieke oplossing raakt mogelijk bij een verstoring alle producten en klantgroepen. De impact van een verstoring wordt groter, is dat te behappen?

Beschouw het generatie-probleem
Een generieke oplossing vervangen kan een grote uitdaging worden. Generieke oplossingen verworden tot ware dinosaurussen. Wat is de plaats van de oplossing binnen het organisatorische weefsel en in de markt? Past het?
Over een periode van jaren raakt de oplossing steeds sterker vervlochten in het ICT-landschap en in de organisatie. Wanneer de oorspronkelijk betrokken medewerkers de organisatie verlaten dan gaat kennis verloren.
Vanuit business oogpunt zijn de kosten en het risico bij vervanging onacceptabel, vanuit ICT-oogpunt is doorgaan op de oude weg geen optie.

Beschouw het risico op verstikking
Als de schaal van de oplossing gelijk is aan de omvang van de organisatie dan wordt de oplossing een allesbepalende factor. Leren wordt moeilijk en de wendbaarheid neemt af.

Beschouw ontvlechting
Ontvlechting is nodig wanneer de processen te ver uiteen gaan lopen of wanneer producten komen te vervallen.
Zijn er afslagen gemaakt om functies uit te voeren voor specifieke processen dan is het wenselijk om de dode functionaliteit te verwijderen. Post-mortem kan het lastig zijn om een zakelijke rechtvaardiging en budget daarvoor te vinden.

Beschouw de exploitatiekosten en de toerekening
Het toerekenen van de kosten van een generieke oplossing naar specifieke producten kan lastig zijn. Proces A stelt bijvoorbeeld hogere eisen aan beveiliging, beschikbaarheid of responsetijd dan proces B. Proces B lift daar dan op mee.
Die extra eisen brengen ook kosten met zich mee. Heeft een afnemer, binnen een organisatie, inzicht in de kosten dan geeft de verdeling aanleiding tot discussie. Ook een financier, bijvoorbeeld een subsidieverstrekker, kan eigen financiële kaders stellen over de declareerbare kosten.
Als één product het overgrote deel van de kosten dekt dan komt de continuïteit in het geding als dat product wegvalt.
Product B heeft een zwakkere positie in de markt als het voordeel van de generieke oplossing niet opweegt tegen de extra kosten die uit hogere eisen voortvloeien.
Beschouw de financiële aspecten en de verschillende scenario's die zich kunnen voordoen.

De keuze voor een generieke oplossing wordt soms lichtzinnig gemaakt. Uit de praktijk een aantal redeneringen en omstandigheden die aanleiding zijn om heel goed op te letten:

• Intellectuele uitdaging. Architecten houden van abstract, conceptueel denken. Dat uit zich in een voorliefde voor de 'schoonheid' van een concept.
• Techno-optimisme. Vandaag is technisch heel veel mogelijk. Of de complexiteit te behappen is is de vraag. Is het organiseerbaar, zijn er voldoende kwalitatief goede ontwikkelaars te vinden?
• 'Pet projects'. Er komt een extra behoefte. Die wordt toegevoegd aan een al lopend programma. Maar past het er wel in? Of wordt het programma gebruikt om een probleem weg te moffelen?
• Onderschatting. Het gelijkstellen van de inspanning voor een generieke oplossing aan die van een specifieke oplossing. De inspanning voor een specifieke oplossing schaalt lineair met de omvang, een generieke oplossing kan een exponentieel karakter hebben.
• Standaardisatie. Uniformering als dogma, zonder dat het te behalen voordeel onderbouwd wordt. Er ontstaat een lock in en door terugval naar een grootste gemene deler komt de waarde voor de business onder druk. Denk aan rationalisatie van het applicatielandschap of de standaardisering op een type device, wat voor de buitendienst of de spreekkamer een slecht idee blijkt.
• Soll-denken. Een architectuuraanpak die sterk gericht is op een wenselijke eind-situatie. De ontwikkelstappen uit het verleden, de stappen op weg naar de realisatie en voorbij het eindbeeld blijven buiten beeld. De generieke oplossing is wellicht te complex in de ontwikkelfase en niet flexibel genoeg voor de onvoorspelbare werkelijkheid eenmaal onderweg.
• Focus op technologie. Te optimistisch, ongefundeerd wensdenken over de veel bredere inzetbaarheid in de toekomst. Zonder te toetsen of er iemand voor zou willen betalen.
• Focus op kostenbesparing. Eigenlijk is een nieuwe oplossing niet betaalbaar. Maar door breed in te zetten met een generieke oplossing, is een budgettaire onderbouwing te maken.
• Over-abstractDe neiging om voor een vraag een oplossing op een metaniveau te bedenken dat veel te hoog boven de werkelijkheid ligt. Modelmatig uit zich dit in 'meta-meta' denken. Procesmatig door in plaats van een concrete implementatie een script of macro-omgeving te willen bouwen. Waarbinnen dan de gevraagde oplossing zou zijn te modelleren of te programmeren.
  Toegegeven, dit is om te beginnen ontzettend leuk, vaak zijn het de analytisch sterke geesten die hiermee komen. Risico's zijn er in de controleerbaarheid van het traject en de beheersbaarheid in de exploitatie. Hoeveel verlichte geesten zijn er überhaupt in de organisatie?

Moderne architectuurprincipes dragen eraan bij dat overgeneralisatie beter valt te vermijden. Concepten als het modulair bouwen van services, separation of concerns, ontkoppelen door API's en het managen van de informatiestromen bieden krachtig gereedschap. Gebruik van de cloud kan ook helpen, door veel van de inspanning in het fundament niet meer zelf te doen.
Maar ook daarmee blijft het nodig om zorgvuldige afwegingen te maken. Wanneer moet een service generiek zijn en hoe is een specifieke service daarop aan te sluiten? Hoe definieer je API's ten opzichte van de business? Hoe maak je een landschap consistent en houd je het inzichtelijk zonder in de valkuil van geforceerde uniformiteit te trappen - die immers ten koste gaat van de business value en zich onvermijdelijk tegen je keert.

Lastig in de praktijk is dat vaak de ICT discipline als enige dit overzicht kan vormen en aansluiting moet vinden met andere actoren in de organisatie. Dat vereist voortdurende aandachte en btrokkenheid.