Prof. Jan Bosch
Onlangs nam ik deel aan een discussie in de automobielsector. Op een gegeven moment ging het gesprek over platforms. Na een tijdje realiseerde ik me dat er verschillende definities van platform door elkaar liepen. Omdat ik al sinds de jaren 90 met platformen werk, is het voor mij erg interessant om te zien hoe het begrip platform is geëvolueerd. Hier bespreek ik drie soorten: platformen voor hergebruik, voor DevOps en voor ecosystemen.
Aanvankelijk was de primaire rol van platformen het delen van basisfunctionaliteit tussen verschillende producten in een productlijn of portfolio, dat wil zeggen een platform voor hergebruik. De gedachtengang was dat als we konden voorkomen dat elk productteam steeds opnieuw dezelfde functionaliteit zou bouwen, dit zou zorgen voor een hogere R&D efficiëntie omdat de productteams konden werken aan de productspecifieke, differentiërende functionaliteit terwijl het platformteam alle productteams zou bedienen.
Ik heb bijna 25 jaar gewerkt aan softwareproductlijnen en het is me duidelijk dat deze eenvoudige redenering kan werken, maar dat er veel manieren zijn om de voordelen die platformen kunnen bieden te verknoeien. Vooral de coördinatiekosten tussen platform- en productteams en het verschil in prioriteiten tussen hen kunnen zoveel inefficiënties veroorzaken dat de voordelen van hergebruik van functionaliteit gemakkelijk teniet kunnen worden gedaan.
Mijn belangrijkste les over platformen voor hergebruik is dat de focus niet moet liggen op (vermeende) efficiëntie, maar op snelheid. Productteams moeten zich richten op het maximaliseren van snelheid en als een platform kan helpen om sneller te gaan, gebruik dan zeker een platform, maar als het platform productteams vertraagt, moet het worden gedropt als een hete aardappel. Door het gebruik van het platform optioneel te maken voor productteams, worden ook voor het platformteam de juiste prioriteiten gesteld.
De laatste jaren is de betekenis en het gebruik van platformen veranderd door de toenemende toepassing van continue inzet van software voor producten in het veld. Toen productsoftware misschien één of twee keer per jaar werd uitgebracht, was het goed mogelijk om een aanzienlijke hoeveelheid handmatige inspanning te besteden aan het aanpassen van de nieuwste versie van de platformsoftware voor een specifiek product en deze te integreren met de nieuwste versie van de productspecifieke software. Wanneer de releasefrequentie echter omhoog gaat, wordt de benodigde hoeveelheid handmatige inspanning onhaalbaar. Dit leidt tot platforms voor DevOps. Hier is het platform de superset van de functionaliteit in alle producten en wordt de software voor elk product automatisch afgeleid door configuratie van de platformsoftware.
Als het gaat om platformen voor DevOps, is de grootste uitdaging waar ik bedrijven mee heb zien worstelen de overgang van maatwerk naar configuratie van software. Vooral in de auto-industrie hebben OEM’s de neiging om allerlei aanpassingen te eisen die, om eerlijk te zijn, vaak weinig bedrijfswaarde toevoegen. Als het echt niet mogelijk is om maatwerk in alle contexten te vermijden, moet het de ambitie zijn om een interface te definiëren tussen het platform en de aanpassingssoftware die hen strikt scheidt. Hierdoor kan de platformsoftware onafhankelijk evolueren in producten die op het terrein worden ingezet.
'Many aspire to have an ecosystem platform but few have realized one'
Het derde type, dat velen nastreven maar weinigen hebben gerealiseerd, is een ecosysteemplatform dat klanten, partners en derden kunnen uitbreiden via een set API’s. Voor hun eigen doeleinden, om verticals te bedienen die niet worden bediend door de aanbieder van het platform of om oplossingen te bieden die niet worden gedekt door het platform voor een breed publiek. Elk bedrijf waarmee ik in contact kom heeft de ambitie om de iPhone van hun branche te leveren, maar het operationaliseren van deze ambitie is in de meeste gevallen een zware strijd.
De typische spanning bij bedrijven die een ecosysteemplatform willen aanbieden, is die tussen dat ontluikende platform en de bestaande productbusiness. Een software ecosysteem heeft schaal nodig, wat betekent dat dezelfde ‘apps’ ingezet kunnen worden in een zo breed mogelijke installed base. Dit vereist dat elk product in het portfolio de standaard ecosysteem-API’s levert, wat de autonomie van productteams beperkt. Bovendien is de heersende product mindset gericht op het opnemen van zoveel mogelijk nuttige functionaliteit in het product, terwijl een platform mindset vereist dat we bepaalde domeinen van functionaliteit aan het ecosysteem geven om ervoor te zorgen dat partners en derde partijen een voldoende aantrekkelijke business case hebben.
Platformen zijn geweldig, maar discussies worden gemakkelijk verwarrend als er verschillende platformdefinities worden gebruikt zonder dat de deelnemers zich daarvan bewust zijn. Ik heb geprobeerd hier wat structuur aan te brengen. Voor de meeste bedrijven die DevOps implementeren, is de productgerichte manier van werken niet langer haalbaar en is in plaats daarvan een platformgerichte aanpak vereist. Dit heeft grote voordelen, maar vraagt om een zorgvuldige strategie en manier van werken omdat er verschillende valkuilen in het verschiet liggen.