Ik vertel je waarschijnlijk niets nieuws wanneer ik zeg dat de eisen van business op IT steeds hoger worden. Business kijkt steeds meer naar IT als een oplossing voor hun problemen.
Organisaties worden quasi verplicht een digitale transformatie te ondergaan, waarbij IT de strategische ‘enabler’ is van hun business. Denk maar aan IoT, mobile enablement, omnichannel sales en communicatie, partnerintegratie etc.
Hoe kan je een solide IT-architectuur voorzien die met al deze business requests kan omgaan? Ik noem ze bewust business requests, want wat we hier proberen te doen is het aanwenden van technologie om business value te genereren.
Ik hoorde onlangs een term die de nagel op de kop sloeg: bedrijven moeten ‘composable enterprises’ worden.
Wanneer we kijken naar het IT-landschap van een typisch middelgroot bedrijf, dan zien we daarin een mix van custom-built en off-the-shelf software, het gebruik van een variëteit aan technologieën, zowel on premise als in de cloud.
Al deze bouwstenen van het landschap zijn typisch point-to-point met elkaar geconnecteerd, pompen data over van de ene applicatie naar de andere, zonder te denken over zaken als hergebruik, onderhoudbaarheid, vervangbaarheid etc. Door al deze point-to-point interacties te gaan transformeren tot degelijke interfaces bovenop deze applicaties onder de vorm van services/API’s en daarbij gebruik te maken van geaccepteerde standaarden zoals REST en SOAP, maak je je architectuur een flink stuk robuuster.
Kort gezegd kunnen waardevolle assets veel sneller in projecten ingeschakeld worden en kan er dus sneller geïnnoveerd worden, aan de hand van kortere doorlooptijden.
Denk dus niet alleen binnen het kader van je eigen bedrijf, maar durf ook breder te denken: projecten waarbij data gedeeld wordt met partners, assets verkocht worden aan derde partijen en die jouw data kunnen gebruiken om te innoveren, … Dit kan allemaal dankzij het gebruik van API’s.
Meer nog, je kan de waarde van je eigen assets verhogen door je eigen API-data en die van derden te gaan aggregeren en hiermee een nieuwe API te creëren. Omdat interfacing op een vrij uniforme manier gebeurt, is het niet zo moeilijk om deze data te aggregeren. Dit gebeurt typisch door een API-gateway, zowel voor security als voor performance redenen.
Werken met API’s ziet er aantrekkelijk, niet? Maar misschien heb je daarbij nog wel enkele vragen, zoals:
- Hoe identificeer je wat je precies als API moet exposen?
- Wat is de impact op onze huidige architectuur en waar in onze puzzel past het precies?
- Hoe ontwikkelen we een API en zorgen we ervoor dat hij herbruikbaar, onderhoudsvriendelijk en veilig is?
- Hoe evolueren we naar zo’n “composable enterprise”?
Al deze zaken worden belicht tijdens onze AE Foyer van volgende week, maar laat ons alvast een tipje van de sluier oplichten.
Eerst en vooral moeten we het verschil maken tussen de API’s voor intern gebruik (on premise application-to-application communicatie, eigen mobile app, cloud integratie, etc.) en de API’s die je aan partners en derden wil aanbieden. We zullen ons vooral op die laatste categorie focussen, aangezien daar de echte waarde van API’s ligt.
Een eerste challenge bij het starten van een API-programma is hoe het te definiëren. Dat ligt niet altijd voor de hand, maar onderstaand stappenplan kan je misschien op weg helpen:
Eens we deze business goals en requirements hebben, kunnen we verder gaan met een solution design en de realisatie van de API’s. Maar dat is niet het eindpunt. Twee belangrijke onderdelen van een API-strategie die vaak vergeten worden, zijn de operationele kant en retirement. Hoe zorg je ervoor dat mensen op je services kunnen vertrouwen? Hoe maak je het gemakkelijk voor hen om je API’s te integreren? Hoe zorg je dat ze überhaupt van het bestaan van je API afweten en moedig je hen aan hem te gebruiken?
Aangezien API’s gebouwd zijn om wendbaar te zijn, zullen ze snel evolueren. Daarom moet je weten om te gaan met ‘breaking’ en ‘non-breaking’ veranderingen en bepalen hoe lang je een bepaalde legacyversie zal blijven ondersteunen. Derde partijen hebben tijd nog om samen met jou(w API) te kunnen evolueren.
Ahankelijk van de use case, staat API-security ook bovenaan de checklist. Want API’s openstellen naar de buitenwereld mag niet betekenen dat je intern bepaalde risico’s loopt. Zorg ervoor dat je je interne datastructuur niet blootstelt, want daar kan misbruik van gemaakt worden. Het invoegen van een API-gateway kan heel wat risico’s helpen inperken en ervoor zorgen dat alles op data/infrastructuur/applicatie-niveau veilig blijft. De uitdaging hier blijft om de mogelijke pijnpunten goed in kaart te brengen en op de juiste manier problemen proberen te voorkomen.
Hebben deze vragen en bedenkingen je aan het denken gezet? Kom dan zeker naar onze AE Foyer op 20 september.
Als je niet naar het event kan komen, maar je toch nog vragen rond dit topic hebt, neem dan gerust contact met ons op.
