Het korte antwoord is ja. Een ervaren IT-team kan integraties bouwen tussen applicaties, databronnen en partners. De technologie is beschikbaar, de documentatie is er, en er is geen technisch obstakel dat het onmogelijk maakt. De vraag die er werkelijk toe doet, is een andere: is het de beste besteding van uw schaarse IT-capaciteit?
Dat is een vraag die IT-leiders in de publieke sector en het onderwijs zichzelf te weinig stellen, en die het waard is om eerlijk te beantwoorden voordat de keuze al impliciet is gemaakt.
Vraag een willekeurige IT-specialist of hij liever een standaardoplossing implementeert of zelf iets op maat bouwt, en het antwoord is voorspelbaar. Maatwerk is uitdagender. Het geeft meer voldoening. En er schuilt vaak een onuitgesproken aanname achter: als we standaardoplossingen gebruiken, kunnen we nooit beter worden dan onze concurrenten.
Dat is het not-invented-here-syndroom, en het is geen kwestie van onkunde of onwil. Het is een heel menselijke reactie op een vak waarin bouwen nu eenmaal leuker is dan beheren. Maar een organisatie die haar integratiestrategie laat bepalen door wat IT-medewerkers het leukst vinden om te doen, neemt een beslissing op basis van het verkeerde criterium.
Ervaren IT-specialisten zijn schaars, en wie ze wel heeft, houdt ze niet altijd lang. Specialisten hebben bovendien de neiging om vast te houden aan de technologie waarmee ze zelf ervaring hebben opgebouwd, ook als die niet aansluit bij de bredere organisatiestandaard. Iemand die een specifieke programmeertaal op de universiteit heeft geleerd, beargumenteert vaak overtuigend waarom precies die taal de juiste keuze is, ook wanneer de rest van de organisatie iets anders gebruikt.
Dat is geen verwijt aan die specialist. Het is een illustratie van wat er gebeurt wanneer technologiekeuzes verspreid worden over individuele voorkeuren in plaats van organisatiebrede afspraken. En het verklaart ook waarom zelfbouw-trajecten op de lange termijn moeilijker te onderhouden zijn dan ze er op papier uitzagen.
In organisaties waar veel eigen maatwerk wordt gebouwd, is iedereen vaak vooral bezig met zijn eigen stukje van het landschap. Dat is geen toeval. Wie zelf bouwt, onderhoudt en beheert, heeft simpelweg minder ruimte om mee te denken over het geheel. “Silodenken” is dan niet een cultuurprobleem dat los staat van de technische keuzes, het is er een directe consequentie van.
Een API-first strategie klinkt eenvoudig, maar vraagt in de praktijk om strakke richtlijnen en grote discipline. Niet elke IT-professional is daar even goed in, en dat is geen kritiek, het is simpelweg een andere vaardigheid dan het bouwen van een werkende koppeling. Het bewaken van standaarden, het afstemmen tussen teams, het vasthouden aan afspraken ook als een snelle workaround verleidelijk is: dat kost veel overleg-, management- en afstemtijd. Tijd die niet meer beschikbaar is voor de dingen die een organisatie daadwerkelijk onderscheidend maken.
Binnen de publieke sector en het onderwijs is IT vooral ondersteunend. Een gemeente onderscheidt zich niet door een knap stukje eigen integratiecode, maar door wat ze met haar data en processen voor inwoners kan betekenen. Een onderwijsinstelling onderscheidt zich niet door haar koppelvlakken, maar door het onderwijs zelf.
Dat vraagt om een andere rolopvatting van IT: meer in de regiestoel, minder “ikke doen”. Regie voeren is een andere vaardigheid dan zelf programmeren. Het vraagt om iemand die met organisatie specifieke kennis slimme keuzes kan maken, juist omdat hij/zij niet tachtig procent van de tijd kwijt is aan het op orde houden van de operationele basis.
Die verschuiving gebeurt niet automatisch. Het vraagt om een bewuste mentaliteitsverandering, en om beloningsstructuren die meebewegen. Een organisatie die regie belonen wil, moet ook stoppen met het impliciet belonen van “ik heb het zelf gebouwd” als hoogste vorm van IT-prestatie.
De combinatie van integration as a service en een API-first strategie levert iets op wat met zelfbouw maar zelden ontstaat: een blokkendoos-model. Omdat data organisatiebreed vanuit elke applicatie te combineren is met data uit andere applicaties en bronnen, ontstaat er veel meer flexibiliteit om nieuwe en innovatieve oplossingen te bouwen. Niet omdat er meer wordt gebouwd, maar omdat het fundament eronder al klaarstaat.
Wat in de discussie over zelf bouwen vaak onderbelicht blijft, is wat er na de bouw gebeurt. Elke leverancier waarvan een applicatie is aangesloten, brengt op enig moment wijzigingen aan: nieuwe releases, aangepaste protocollen, andere beveiligingseisen. Iemand moet dat per leverancier in de gaten houden, de impact beoordelen, en de eigen integraties daarop aanpassen.
Bij vijftien verschillende leveranciers ontstaan in theorie al meer dan tweehonderd onderlinge afhankelijkheden om rekening mee te houden. Bij tachtig leveranciers is dat geen overzichtelijk vraagstuk meer, maar een vrijwel onbeheersbare opgave. En dan is er nog de simpele maar hardnekkige vraag: wie is eigenlijk de eigenaar van welke specifieke API, en waar wordt die precies gebruikt binnen de organisatie? In veel zelfbouw-landschappen is het antwoord op die vraag verrassend vaak: niemand weet het precies.
Bij integration as a service ligt die verantwoordelijkheid bij de partij die de dienst levert; als kernonderdeel van wat er wordt afgenomen.
Zelf integraties bouwen is mogelijk. De vraag is niet of het kan, maar of het de juiste plek is om de schaarse en kostbare IT-capaciteit van uw organisatie aan te besteden. Voor organisaties waar IT vooral ondersteunend moet zijn, en waar onderscheidend vermogen ontstaat door wat er met data gedaan wordt, niet door wie de meest elegante koppeling heeft gebouwd, is dat een vraag die het overdenken waard is.
Enable U levert integration as a service inclusief het volledige lifecycle Management van uw API’s en koppelingen, zodat uw eigen IT-capaciteit beschikbaar blijft voor de zaken die uw organisatie daadwerkelijk onderscheidend maken. Wilt u weten wat dat voor uw organisatie betekent? Neem contact op met Enable U.
