Adopteren of dekking zoeken?

Het regent tools en technologieën

0

In de afgelopen periode is het aantal nieuwe tools en technologieën indrukwekkend gestegen. Het merendeel van de nieuwkomers bevindt zich in de categorie van big data. Achter creatieve namen als Virtuoso, Voldemort en Scalaris gaat functionaliteit schuil die een oplossing biedt voor problemen waarvan organisaties misschien niet eens op de hoogte zijn. Negeren is een optie, maar dan loop je het risico de boot te missen. Direct omarmen daarentegen gaat waarschijnlijk gepaard met kinderziektes. Is er geen betere strategie?

Bij nieuwe businesstechnologie kun je inderdaad afwachten en over een paar jaar kijken of de technologie überhaupt nog bestaat. Het alternatief is om direct te onderzoeken of het de moeite waard is de veelbelovende technologie misschien nu al te gebruiken.

Nu of nooit is het dilemma waarmee veel organisaties worstelen. Maar hoe bepaal je dan in welke tools en technologieën je wilt investeren? Bij de beantwoording van die vraag spelen drie uitgangspunten een rol:

  1. een hybride omgeving;
  2. architecten nieuwe stijl;
  3. een proof of value (PoV) als oefenveld.

Hybride omgeving

In een niet zo ver verleden was het samenstellen van een zogenoemde STOP-list (zie figuur 1), die aangeeft welke software wordt gebruikt voor welke toepassing, relatief eenvoudig. Uitgangspunt was om te kiezen voor een van de grote softwareleveranciers, de megavendors, ook wel bekend als MISO: Microsoft, IBM, SAP en Oracle.

Figuur 1: de STOP list

Een keuze voor meer dan één MISO-vendor betekent echter een conflicterende visie over hoe de IT-wereld zich gaat ontwikkelen en welke richting (en producten) dus gevolgd moeten worden. Elke MISO-vendor komt daarnaast met zijn eigen ecosysteem: een bonte lijst van kleinere leveranciers die ontbrekende functionaliteit of minder sterke MISO-producten invullen en doen vergeten.

Anno 2017 steekt de softwarewereld een stuk complexer in elkaar. Het lijstje met megavendors is aangevuld met een schier eindeloze reeks van big data-technologieën. Wat te denken van Flume, Kafka, Zookeeper, Spark, SOLR, Kudu, Sqoop, Oozie, Impala en ga zo maar door. Leveranciers als Cloudera bieden deze open source-producten als één geheel aan en plakken er vervolgens ook niet-open source-producten (dus te betalen) aan vast zoals Cloudera Manager.

Verschillende use cases vragen om verschillende tooling

De NoSQL-databasecategorie is eveneens indrukwekkend te noemen: HBase, Cassandra, CouchDB, MongoDB, Redis, Riak, Membase, InfoGrid, Neo4j, OrientDB, Voldemort, Scalaris, et cetera. Geen wonder dat veel organisaties zich afvragen of ze hier iets mee moeten – en zo ja, wat dan? En om het helemaal complex te maken introduceren de grote vendors elk hun eigen proposities voor big data. Afwachten of toch nu al instappen?

Doelarchitectuur

De snelheid waarmee nieuwe ontwikkelingen en producten elkaar opvolgen, maakt dat het veel moeilijker is geworden om grote, alomvattende architectuurplannen op te zetten. Dat wil zeggen: het definiëren van de doelarchitectuur kan nog steeds, maar de kans dat de feitelijke invulling er ook zo gaat uitzien, is veel kleiner dan in het verleden.

Binnen de architectengemeenschap is de heersende opvatting dan ook dat er meer organisch gewerkt moet worden, waarbij gegroeid wordt naar een architectuur die van tevoren niet te voorzien was – maar die wel inspeelt op de ontwikkelingen die zich voordoen.

Waar men het ook over eens is, is dat elke IT-omgeving een hybride omgeving is – of dat in ieder geval zou moeten zijn (zie figuur 2). Met hybride wordt hier bedoeld dat organisaties zowel gebruik blijven maken van de bestaande, relationele softwarestack als van de meer recente big data-technologieën. De reden hiervoor is duidelijk: beide leveren een bijdrage aan de functionaliteit waaraan de organisatie behoefte heeft.

Figuur 2: het belang van een high-level hybride architectuur

Bewustwording

Waar organisaties gebruik willen blijven maken van de bestaande, voornamelijk relationele producten en waar big data-technologie een betere oplossing biedt, hangt af van de kenmerken van de use cases (toepassingen) die ondersteund moeten worden.

Hieronder een aantal voorbeelden:

  • Analytics: uit grote hoeveelheden data snel inzichten verkrijgen. Bigdatatechnologie kan goed omgaan met grote hoeveelheden data, die in een datalab snel bevraagd kunnen worden. Inzichten waarop je vervolgens wilt rapporteren passen weer beter bij een (relationeel) datawarehouse.
  • E-commerce: bezoekers van de website maximaal ondersteunen en hoge conversie nastreven. Het gaat hier om het in realtime afhandelen van vele verschillende transacties en het verwerven van inzicht in de klantgegevens, betaal- en bestelhistorie, interesses en de meest aantrekkelijke proposities. MPP (massively parallel processing) en in-memory databases passen hier, maar ook een grafendatabase als Neo4j kan goede diensten leveren.
  • Een heel andere use case is het uitsturen van uitnodigingen als onderdeel van een marketingcampagne of het periodiek factureren. Dit type bewerkingen kan prima door een standaardpakket met relationele database worden uitgevoerd.
  • Kostenbesparing van dataopslag en dataverwerking. Veel opslag en verwerking kan goedkoper plaatsvinden in een datalake.
  • Auditing, datalineage, tracking en tracing. Wetgeving zoals GDPR eist dat organisaties weten waar hun data zijn opgeslagen en hoe deze data door de organisatie stromen. Dat betekent dat deze informatie verzameld moet kunnen worden, ongeacht of de data (nu) in Hdfs staan en vervolgens in een relationeel datawarehouse. De vraag naar tools die metadata beheren voor alle datatypen (gestructureerd, semigestructureerd en ongestructureerd) is aanwezig, waarbij het aanbod nog achterloopt en het aan elkaar knopen van verschillende deeloplossingen momenteel nog het hoogst haalbare is. Wat duidelijk zal zijn is dat verschillende use cases om verschillende tooling vragen. Beide componenten (regulier en big data) zijn met elkaar verbonden en ‘spelen elkaar de bal toe’ als daar aanleiding voor is.

Visie en implementatie

Trends waarmee organisaties geconfronteerd worden zijn datavolumes die continu toenemen, het groter wordend aandeel van ongestructureerde data hierin en steeds minder beschikbare tijd om deze data te verwerken. In de reguliere stack is de voornaamste reactie hierop om zwaardere hardware (MPP) in te zetten en in-memory-varianten van databases te ontwikkelen.

Denk bijvoorbeeld aan SAP HANA en IBM DB1 BLU. Data in geheugen werkt immers sneller dan data die van schijf gelezen moet worden. Meer processoren, gebruikmaken van caching, compressie van gegevens en dataopslag die aansluit bij het gebruik (multitemperatuurconcept) leveren allemaal een bijdrage aan een snellere afhandeling.

In de big data stack wordt de oplossing gezocht in het verspreiden van de werklast over een cluster van standaardservers, waarna de deelresultaten vervolgens weer gecombineerd worden tot een eindresultaat. NoSQL-databases gaan uit van de semi- of niet-gestructureerde data die worden verzameld.

Documentstores gaan uit van documenten, terwijl grafen-databases uitblinken in het ‘on the fly’ aan elkaar knopen van heel veel bestanden (nodes), waar relationele databases verzanden.

Uitdaging

Het goede nieuws is dan ook dat er inmiddels wel voor elke toepassing (use case) een mooie oplossing bestaat. Als dat nog niet zo is, wordt daar waarschijnlijk aan gewerkt. De uitdaging voor organisaties is: kies je voor een relatief nieuw product, ga je door met de bestaande tooling en/of wacht je op het moment dat de bestaande vendor met een eigen versie komt? En kun je zolang wachten?

Het enkele feit dat er mooie, nieuwe functionaliteit wordt aangeboden betekent nog niet dat organisaties daar ook massaal voor kiezen. Er is immers tijd, geld en energie in de huidige spullenboel gestopt en mensen zijn voor bepaalde tools opgeleid en hebben hiermee ervaring. En hoe levensvatbaar zijn producten die minder dan twee of drie jaar in de markt staan? Daarbij: als er al wordt besloten om een selectietraject in te gaan, is dat meestal een langdurig traject. Uit onderzoek blijkt dat het aantal functionarissen dat hierbij is betrokken inmiddels is toegenomen van gemiddeld 5,4 naar 6,8 personen.

In de IT-sector wordt elk interessant idee al snel gekopieerd. Sterker nog: dit is een voorwaarde voor de levensvatbaarheid ervan. Als een idee niet aanslaat en dus niet wordt gekopieerd, leidt dat ertoe dat het een beperkte markt blijft, een niche. Het kan dus een doelbewuste strategie zijn voor organisaties om te wachten. Als het idee wordt gekopieerd, is dat een bevestiging dat het om iets substantieels gaat waarmee je ook je voordeel kunt doen. En, bijkomend voordeel, het wordt dan waarschijnlijk ook geboden door (een van) de huisleverancier(s).

Voor elke use case bestaat een mooie oplossing

We moeten twee kanttekeningen maken bij deze strategie. Het wachten leidt ertoe dat je geen deel uitmaakt van de kopgroep die als eerste profijt heeft. Of je deze voorsprong aan andere kunt laten is een vraag die elke organisatie voor zichzelf moet beantwoorden. De tweede kanttekening is dat het kopiëren van de nieuwe functionaliteit niet altijd leidt tot eenzelfde oplossing. Om terug te komen op het voorbeeld van grafen-databases: leveranciers als Oracle en Microsoft werken ook aan een grafen-oplossing. Maar in hoeverre dat een vergelijkbaar product is als dat van Neo4j (de leider in dat segment) is nog maar de vraag.

Architecten nieuwe stijl

Architecten hebben de afgelopen tien jaar te maken gehad met een omslag in de waardering van hun werk. Waar ze voorheen voornamelijk werden gezien als een belemmering en vertraging voor projecten, hebben ze vandaag de dag de taak om de verschillende trends en technologieën te volgen en te vertalen naar kansen voor de organisatie. En daarbij is de verwachting dat ze vervolgens ook nog actief deze mogelijkheden intern gaan verkopen. De ‘pratende’ architect als partner van de business – het moet niet gekker worden. Marktonderzoeksbureau Gartner duidt deze nieuwe rol aan als de vanguard, ofwel de ‘voorhoede-architect’.

Organisaties die in hun gelederen beschikken over deze vanguard-architecten hebben daarmee een constructie waarmee technologische ontwikkelingen in de buitenwereld worden gefilterd als zijnde relevant of niet-relevant. Als architecten voldoende animo vinden voor de door hen gesignaleerde opportunities (use cases en technologieën) is daarmee ook een eerste keuze gemaakt voor de tools en technologieën die nodig zijn om het gekozen pad in te gaan.

Proof of value

Omdat de centrale gedachte een use case is (en niet een product) is het een goede gewoonte om een proof of value (PoV) op te zetten en er zo achter te komen wat noodzakelijk is om de use case uit te voeren – en hoe soepel dat gaat. Bij deze werkwijze wordt continu gespeurd naar nieuwe opportunities, waaruit vervolgens een keuze wordt gemaakt om in een PoV uit te voeren.

Op basis van behaalde resultaten wordt besloten om het toch niet te doen (fail fast), of op te schalen naar productie. Dit is een andere manier om grip te krijgen op de dynamische werkelijkheid en daarvan te profiteren. Bij het opzetten en uitvoeren van een PoV kan prima gebruik worden gemaakt van cloudoplossingen zoals Amazon Web Services (AWS) of Microsoft Azure, waarbij tijdelijk capaciteit kan worden geregeld voor zolang dat nodig is.

Conclusie

Organisaties hebben nog nooit zo veel keuze gehad in nieuwe tools en technologieën, met name vanuit de big data-hoek. Door een hybride architectuur als uitgangspunt te nemen en de vanguard-architect relevante ontwikkelingen in technologieën en use cases te laten signaleren, verkrijgen ondernemingen meer grip op deze dynamische omgeving. Een zogenoemde ‘proof of value’-dienst fungeert hierbij als oefenveldje.