Country Selector: Nederland
Organisaties kiezen bij de selectie van hun oplossing vaak voor een best of breed of best-of-suite -aanpak. Er zijn vele wegen die leiden tot een totaaloplossing en verschillende routes hebben hun eigen pluspunten en valkuilen. Hoe weet je bijvoorbeeld of alle deeloplossingen goed met elkaar samenwerken? Welke verschijningsvormen bestaan er voor integraties en welke invloed heeft het type ‘stekker’ op de keuzevrijheid van uw organisatie?
Egied Bormans, Portfolio Manager
De oplossingen waarmee u de werkprocessen in uw organisatie ondersteunt, bestaan zelden uit één onderdeel. Het zijn veelal combinaties van applicaties en systemen die er samen voor zorgen dat uw medewerkers hun werk efficiënter of veiliger kunnen uitvoeren. Bij de selectie van (deel)oplossingen is het begrijpelijk dat organisaties vaak de voorkeur hebben voor een zogenaamde best of breed-aanpak. Het komt er feitelijk op neer dat u als organisatie voor elk onderdeel de beste oplossing kiest (waarbij de classificatie “de beste” afhankelijk zal zijn van diverse weegfactoren). In de praktijk betekent het dat verschillende deeloplossingen vaak van verschillende leveranciers afkomstig kunnen en zullen zijn. Sterker nog, je wilt als organisatie vaak niet afhankelijk zijn van één bepaalde leverancier. Je wilt de vrijheid hebben om voor elke individuele deeloplossing nu én in de toekomst de beste oplossing en leverancier te kunnen kiezen.
Maar hoe weet je als eindgebruiker dan of alle “beste” deeloplossingen goed met elkaar samenwerken? Heb ik daarmee ook de beste totaaloplossing? Met andere woorden: heb ik met de beste spelers wel het beste team? Het antwoord ligt voor een groot deel in samenwerking. Als alle spelers uitstekend hun taak uitvoeren en ook nog eens uitstekend samenwerken met hun teamgenoten, dan staat er waarschijnlijk een zeer sterk team op het veld. Een soortgelijke samenwerking heb je dus ook nodig voor deeloplossingen.
Applicaties en systemen werken samen dankzij “ integraties”. Deze integraties kunnen verschillende verschijningsvormen hebben, en die verschijningsvormen hebben vervolgens invloed op de keuzevrijheid die u als organisatie heeft. In selectietrajecten is het van belang om na te denken over deze verschijningsvormen, zodat hierin de juiste keuzes gemaakt worden.
De voorkeursoptie voor een integratie is beschikbaar als er een gestandaardiseerde interface bestaat. Door middel van zo’n gestandaardiseerd koppelvlak kunnen meerdere systemen, meestal zonder problemen, met elkaar samenwerken zonder dat er wijzigingen nodig zijn in de applicaties of systemen. Voorbeelden hiervan zijn WiFi, SIP, LDAP en HL7. Helaas zijn er soms zaken die roet in het eten kunnen gooien bij dit soort koppelvlakken, maar meestal worden die problemen juist veroorzaakt door opties of details die niet goed gestandaardiseerd zijn. De voordelen zijn veel groter dan de onvolkomenheden. Zo kun je in principe elk WiFi-device op elke WiFi-infrastructuur gebruiken. Binnen het mobiliteitsportfolio besteedt Ascom om die reden erg veel aandacht aan interoperabiliteitscertificeringen: daarmee verifiëren we dat Ascom-oplossingen met oplossingen van derden werken, nu en in de toekomst.
Als er geen gestandaardiseerd koppelvlak beschikbaar is, dan zal een leverancier een “stekker” moeten maken om te kunnen integreren met de oplossing van een andere leverancier. U bent daarbij afhankelijk geworden van de leverancier van deze stekker: mocht deze leverancier de aanpassing namelijk niet meer kunnen leveren of onderhouden, dan zult u op zoek moeten gaan naar een andere leverancier, en misschien zelfs een andere deeloplossing. Op zich is deze afhankelijkheid geen probleem: deze is immers onvermijdelijk omdat er een stekker nodig is. Het is wel belangrijk om te beseffen dat deze afhankelijkheid heel sterk bij één leverancier kan komen te liggen. Als één leverancier alle benodigde aanpassingen voor integraties met andere deeloplossingen levert en onderhoudt, dan bent u ook in grote mate afhankelijk van deze leverancier. De leverancier is weliswaar “leverancier-onafhankelijk” (omdat de leverancier kan integreren met oplossingen van alle andere leveranciers), maar u bent daarmee zelf wel afhankelijk geworden van die ene leverancier. U kunt niet van de één op de andere dag deze leverancier verruilen voor een ander.
Een mogelijkheid die meer vrijheid (of eigenlijk meer spreiding van risico) biedt, is het gebruik van API’s (Application Programming Interfaces). Hiermee geeft een leverancier derden de mogelijkheid om van zijn systeem gebruik te maken. De derde partij kan hiermee dus zelf een integratie realiseren met het systeem van de leverancier. De derde partij realiseert dus de “stekker”. Daarmee bent u dus wel afhankelijk van deze derde partij (uzelf of een andere leverancier) geworden, maar u heeft daarbij wel zelf in de hand van wie u afhankelijk wilt zijn. Ascom heeft binnen haar portfolio diverse API’s beschikbaar die door derden worden gebruikt. Een voorbeeld hiervan binnen het Unite-portfolio zijn de API’s voor toewijzing van alarmen en voor het beheer van gebruikers. Kenmerkend voor het gebruik van dergelijke API’s is dat ú bepaalt wie de stekker realiseert, en van wie u dus afhankelijk wilt zijn.
Kortom, er zijn vele wegen die tot een totaaloplossing leiden. En verschillende routes hebben hun eigen pluspunten en valkuilen. Ascom ondersteunt u bij de realisatie van een totaaloplossing door middel van een ecosysteem van eigen oplossingen en van oplossingen van partners. Wilt u weten welke mogelijkheden Ascom u kan bieden in het realiseren van een echt open oplossing? Neem dan contact met ons op.