Organisatiegrenzen vervagen snel in een digitale wereld. De afgelopen twintig jaar hebben veel organisaties hun grote, monolithische systemen vervangen door modernere IT-architecturen. Hiermee is het werk niet af. Organisaties kiezen er steeds vaker voor om stukjes IT-functionaliteit ‘as a service’ af te nemen.

Daarnaast bieden deze bedrijven hun eigen functionaliteit ‘as a service’ aan. Bedrijven veranderen daarmee van IT-consumenten naar IT-providers. Termen die we in deze context vaak horen zijn hyperspecialization, microservices en api-based economy. Wat houden zij in en wat zijn de implicaties? Hoe kunnen organisaties deze ontwikkelingen omarmen en hoe kunnen ze zich ertegen wapenen? Hieronder praktische voorbeelden en handvatten.

Nieuwe technieken, zoals cloud, PaaS en SaaS, maken het mogelijk om personen en organisaties makkelijker onderling digitaal te verbinden en diensten aan elkaar te laten aanbieden. In de IT wordt gesproken van api’s (application programming interfaces), waarmee een computerprogramma kan communiceren met een ander programma of een onderdeel daarvan. Een api is een klein blokje functionaliteit dat op een gestandaardiseerde manier wordt aangeroepen en antwoord geeft.

Realtime verkeersinformatie is een bij velen bekend voorbeeld. Via een eenvoudig vraag-antwoordspel kan iedereen actuele verkeerssituaties op zijn website presenteren. Organisaties praten steeds vaker met elkaar via zulke api’s, vandaar ook de term ‘api-based economy’. Hiermee wordt een wereld van open architecturen aangeduid. Een wereld waarin digitale diensten eenvoudig te verkrijgen en aan te bieden zijn.

“De api-based economy dwingt organisaties zich te specialiseren”

In zo’n wereld ontstaat bijna vanzelf een drive om alleen die dingen zelf te doen waar je goed in bent en die te verkopen. Diensten waar je minder goed in bent (dat wil zeggen: niet onderscheidend) ga je inkopen. Zo ontstaat ‘hyperspecialization’: een steeds verfijnder netwerk van gespecialiseerde aanbieders van specifieke diensten. ‘Microservices’ is de techniek die hieraan het fundament biedt.

Al in 1980 schreef de Amerikaanse academicus Michael Porter over vier manieren waarop organisaties zich strategisch kunnen positioneren (zie figuur 1): door een keuze te maken tussen enerzijds een groot marktaandeel of een nichemarkt, en anderzijds kosteneffectiviteit of differentiatie. De combinaties van deze keuzes leiden tot vier ‘generieke strategieën’.

In het model van Porter levert de api-based economy een verschuiving naar ‘rechtsboven’ op: door iets kleins en specifieks heel goed te doen, kun je je onderscheiden en toch een grote markt aanboren. Hoewel kosten niet de primaire driver zijn, blijven de kosten per transactie door de grote schaal laag.

Met een aantal actuele praktijkvoorbeelden laten we de impact van de api-based economy en de verschuiving naar ‘rechtsboven’ in het Porter-quadrant in verschillende sectoren zien.

Figuur 1. Portner’s Generic Strategies

Praktijkvoorbeeld 1: api’s in de bancaire wereld

Op 16 november 2015 heeft de Europese Raad een richtlijn aangenomen over het verder openbreken van de Europese markt voor betalingsverkeer: de Payment Service Directive 2 (PSD2). Deze ‘directive’ schrijft voor dat Europese banken rekening- en transactiegegevens digitaal beschikbaar moeten kunnen stellen aan geautoriseerde derden en ook de initiatie van betaalopdrachten ‘van buitenaf’ mogelijk moeten maken. Iedere bank wordt hiermee de facto verplicht een aantal api’s aan te bieden.

Paniek alom bij de banken, want als iedereen die dat wil en mag buiten de eigen kanalen om bij ‘jouw’ diensten kan, hoe onderscheid je je dan nog als individuele bank? Wat verhindert dat de klant gewoon de mooiste app van een willekeurige aanbieder – die zelf geen bank hoeft te zijn – gebruikt om zijn financiën te beheren, zonder zich druk te maken over waar zijn geld eigenlijk staat? Hoe voorkom je dat je rol als bank zich reduceert tot die van provider van een betaalinfrastructuur? En op welke manier kan je geld verdienen aan deze nieuwe mogelijkheden? Een aantal nieuwe uitdagingen waar individuele grootbanken binnen Europa antwoord op moeten vinden, als gevolg van de api-based economy.

Ondertussen maken fintechs als Atom, Bunq en Simple gretig gebruik van de nieuw ontsloten data en functies. En ze roepen om het hardst dat zij disruptief zijn. Met die boodschap weten ze investeerders en klanten te verleiden. Voor de traditionele banken met veel niet zo gemakkelijk te veranderen legacy wordt de uitdaging: specialiseer of sneuvel.

Figuur 2. Hoe fintechs gebruikmaken van bestaande bankdiensten

Praktijkvoorbeeld 2: api’s in de bouwwereld

Hoewel de bouwwereld niet bekend staat als uitblinker in het innovatieve gebruik van IT, wordt ook hier geëxperimenteerd met het aanbieden van api’s. De verwachting is dat het gebruik van api’s vooral de kosten van non-kwaliteit zal terugbrengen. Non-kwaliteit kent vele verschijningsvormen in de bouwwereld: net niet passend, net te laat, net niet in de juiste kleur, net niet op de juiste locatie, net niet in de juiste kwaliteit, enzovoort.

De aan non-kwaliteit verbonden kosten zijn in omvang vergelijkbaar met de winstmarge. Elke besparing daarop is pure bottom-linewinst. Daarom wordt er op dit moment gewerkt aan een platform waarop verhuurders, huurders, bouwers en keukenaanbieders samenwerken voor keukenrenovaties. Wanneer de catalogus van de keukenleverancier als api beschikbaar komt, wordt het bestellen van een keuken op maat vereenvoudigd. Door het beschikbaar stellen van de maten door de bouwer en de exacte lay-out van de keuken door de huurder, wordt het proces klantvriendelijker en meer digitaal.

Door de verhuurder kan direct de nieuwe huurprijs op basis van de kosten van de keuken worden berekend. Uiteraard is er daarnaast een api waarmee de productiestatus is af te lezen, zodat de installateur tot op de minuut inzicht heeft in wanneer de keuken klaar is. Die moet dan nog wel vervoerd worden en daar vinden we het volgende voorbeeld van de api-economie: de logistiek.

Praktijkvoorbeeld 3: api’s in de logistiek

De logistieke sector is een heel stuk verder dan veel andere sectoren met de transitie naar de api-economie. Als je in een webwinkel een product bestelt, wordt de logistiek meteen geregeld en de track-and-trace-informatie gedeeld. Dat vinden we allemaal al heel gewoon.

Ook hier geldt dat er op de achtergrond heel wat api-verkeer plaatsvindt om dit mogelijk te maken. Er moet gekeken worden in welke rit het product mee kan en hoe de levering in de routering past. Gezien het belang van logistiek gaat de ontwikkeling hier razendsnel. Levering op de volgende dag en in een specifiek tijdslot zijn al orde van de dag. Een volgende stap is het realtime aanpassen van de leverlocatie (‘thuis of op je werk’) op basis van de verwachte levertijd. Ontwikkelingen waarvoor vele integraties benodigd zijn.

Wat kunnen we leren van deze voorbeelden?

Het aanbieden of afnemen van api’s is technisch gezien niet heel moeilijk, maar de implicaties van de transitie naar een api-based economy zijn enorm. De belangrijkste is dat het organisaties dwingt om dat (en alleen dat!) te doen waar zij specifiek goed in zijn. Dus om zich te specialiseren. Immers, wanneer je als organisatie een dienst levert die goedkoper via een api van een andere partij afgenomen kan worden, ben je niet future-proof.

Traditioneel ontwikkelde ieder bedrijf in een bepaalde sector dezelfde functies, ook al onderscheidde je je daar niet mee: je had het gewoon nodig. Denk bijvoorbeeld aan banken die allemaal individueel on-premise IT hadden (of hebben) om transacties af te handelen. Dergelijke commodities worden in een api-based economy verplaatst naar de goedkoopste aanbieder. Die zal deze aanbieden aan een groot aantal afnemers. Hierdoor zullen de kosten per afnemer laag blijven.

Een vijftal stappen zijn volgens Deloitte essentieel. Ze zijn samen te vatten als ‘specialiseer of sneuvel’. Organisaties moeten een keuze maken voor de toekomst en deze richting consequent doorvoeren. Deloitte heeft de laatste jaren veel klanten mogen ondersteunen bij deze transformatie. Hoewel de stappen logisch lijken, blijkt het in de praktijk lastig om deze door te voeren in de staande organisatie:

  1. Kies – Bepaal op welke manier je je wil onderscheiden en ga daarvoor. Voorkom consessies die ertoe leiden dat je ‘overal een beetje goed in bent’, want dat is voor geen klant meer goed genoeg.
  2. Focus – Doe de dingen waarmee je je wil onderscheiden zo goed mogelijk en doe ze zelf. Besteed de rest zoveel mogelijk uit, zodat je capaciteit hebt om te focussen.
  3. Rationaliseer – Is je IT-landschap complex of monolitisch? Doe hier dan snel wat aan. Alleen dan kun je immers je gekozen focus ook in de praktijk brengen.
  4. Externaliseer – Besteed IT voor zaken buiten je focusgebied uit, bijvoorbeeld naar SaaS-providers en cloudtechnologie.
  5. Evalueer – Blijf continu toetsen of je propositie nog onderscheidend en scherp genoeg is. Stuur bij waar nodig.

Naast dit vijfpuntenschema is er ook een vijftal kenmerken van een goede api om rekening mee te houden:

  1. Toegankelijk: wanneer je een grote markt wil kunnen bedienen, moet een api toegankelijk zijn voor een breed publiek, efficiënt zijn ingericht en opgebouwd uit gangbare standaarden.
  2. Eenvoudig: een api moet eenvoudig zijn in gebruik. Deze zal sneller geadopteerd worden omdat mensen beter begrijpen hoe de interactie werkt. In een hyperspecalized omgeving biedt een api idealiter één dienst aan die met zo min mogelijk input kan worden geleverd.
  3. Onderscheidend: de via de api aangeboden dienst moet onderscheidend zijn, bijvoorbeeld in termen van functionaliteit, eenvoud of kosten, om de potentie te hebben markt te veroveren.
  4. Economisch: de api moet een logisch onderdeel van een businessmodel kunnen zijn. Denk hierbij bijvoorbeeld aan voordelige outsourcing van een functie.
  5. Veilig: het gebruik van de api, waaronder het versturen en ontvangen van data, moet veilig zijn. Dit geldt ook voor eventuele opslag van data bij de aanbieder van de api.

Wanneer je ervoor zorgt dat api’s aan deze eigenschappen voldoen, is de kans op adoptie door de markt het grootst. Een grote adoptie maakt het mogelijk de kosten per klant te verlagen, wat een katalyserend effect heeft.

Concluderend geldt dus: doe uitsluitend waar je goed in bent, doe dat voor een zo groot mogelijke doelgroep, maar doe het wel op een zowel technisch als commercieel verantwoorde manier. En realiseer je dat wat vroeger business heette, namelijk het verkopen en leveren van diensten, tegenwoordig IT is. Op die manier word je een disruptor in plaats van disrupted in de wereld van open architecturen; daar waar het gezegde ‘eat of be eaten’ steeds vaker van toepassing is.

Door Erik Hegeman, Sebastiaan Koenen en Eric Onderdelinden, werkzaam bij Deloitte Consulting, binnen de afdeling Enterprise Architecture.