Steeds meer organisaties onderzoeken de mogelijkheden (en onmogelijkheden) van big data trajecten en data analytics toepassingen. Sommige staan nog aan het begin van een ontdekkingstocht en onderzoeken de voor- en nadelen van deze concepten nog en hebben wellicht enige beginnersbezwaren. Andere organisaties zijn al verder en hebben al geëxperimenteerd met deze concepten en hebben zich een beeld kunnen vormen van de mogelijkheden voor de eigen context. De laatste groep, en waarschijnlijk de kleinste, heeft de kansen en mogelijkheden onderzocht en weet dat big data en data analytics toegevoegde waarde kan leveren.

Maar hoe zit het met de toegevoegde waarde van de architect in dit soort trajecten. Bij een opdrachtgever waar ik een big data project heb ondersteund werd geopperd dat het prima zonder architect kon. Dat is misschien wat kort door de bocht. Echter de architect zal zichzelf wel heel duidelijk moeten afvragen: Wat is mijn toegevoegde waarde? Duidelijk is in ieder geval dat de “traditionele architect” zichzelf opnieuw zal moeten uitvinden. In deze blogserie worden een aantal suggesties gedaan en aandachtspunten beschreven die je kunnen helpen bij het uitvinden van jezelf als waarde toevoegende architect.

Activiteiten van de traditionele architect

Mogelijk komt de term “traditionele architect” wat denigrerend over. Dat is niet de insteek van deze blogserie. De term wordt gebruikt om aan te geven op welke aspecten de veranderingen in de architectuur plaatsvinden. Beschouw de “traditionele architect” als een vertrekpunt voor het schetsen van de rol van een big data architect in de toekomst.

In veel gevallen bestaat het werk van de architect, zowel traditioneel als big data, uit twee soorten werkzaamheden. Dit zijn voorschrijvende- en beschrijvende werkzaamheden. Met voorschrijven worden kaders en beperkingen gesteld aan veranderingen. Beschrijven geeft een beeld van de toekomstige situatie. Huidige situaties zijn er nog niet veel in het werkveld big data.

In de paragrafen hieronder gaan we in op een aantal activiteiten en producten die de “traditionele architect” hoogstwaarschijnlijk onder de loep moet gaan nemen.

Architectuur principes tijdens big data trajecten

Voorschrijvende architectuur is vaak gebaseerd op een set van principes. Deze principes zijn daarmee een algemeen kader gericht op het sturen van de verandering, veelal in projecten. Principes zullen vaak gericht zijn op gestructureerde data die opgeslagen worden in relationele databases. Bij big data toepassingen zullen ook datasets die minder gestructureerd zijn.

Gevolg is dat er twee mogelijkheden zijn:

• Herschrijf de principes zodat ze ook inzetbaar zijn voor minder gestructureerde data bruikbaar zijn. Dit heeft als voordeel dat de set van principes relatief beperkt blijft, nadeel is dat de principes mogelijk nietszeggend of minder toepasbaar blijken.
• Maak een aantal principes gericht op laag gestructureerde datasets binnen big data toepassingen. Daarmee wordt er een specifieke set van principes geïntroduceerd. Nadeel is dat de grens tussen laag en hoog gestructureerd moeilijk te bepalen kan zijn. Voordeel is dat je een beperkte specifieke set van principes introduceert voor je big data initiatieven.

Veel traditionele dataprincipes zijn gericht op kwaliteit van data in de bron, dat is bij big data initiatieven een uitdaging. Veelal is de afstand tot de bron groot, heb je weinig invloed op het eigenaarschap en is terug melden van laag kwalitatieve data knelpunten niet relevant. Gevolg is dan ook dat de kwaliteit verhogende maatregelen in de transformatie van de brondata tot aan het gebruik van de afgeleide data plaats zullen vinden. Denk hierbij niet alleen aan het opschonen van data maar ook aan het inzitten van controlestromen of het combineren van stromen om data met voldoende kwaliteit voor gebruik te kunnen produceren.

Als het lastig is om de principes toepasbaar te maken, bijvoorbeeld doordat big data nog in de kinderschoenen staat bij de organisatie. Dan kun je overwegen om niet met principes te werken maar te kiezen voor een uitwerking gebaseerd op requirements. Hierbij kun je requirements verzamelen van de stakeholders rond je big data toepassing en op basis daarvan een kader stellend beeld schetsen van de te introduceren oplossing.

Project Start Architectuur

In principe is het uitwerken van een kader stellend architectuurdocument bij de start van een verandering binnen een project een goede aanpak. Project Start Architect zijn een kenmerkend voorbeeld van dergelijke architectuurdocumenten. Vandaar de titel van deze paragraaf. Echter ook solution architectuurdocumenten worden veelal voor de start van een project geschreven.

Bij big data trajecten, zeker bij de innovatieve projecten, zal de traditionele werkwijze met een uitgebreid en gedetailleerd architectuurdocument niet goed werken. Aan het begin van het project zijn er nog teveel onzekerheden, is er nog geen duidelijk beeld over de toekomstige situatie en weet niemand wat de ICT inrichting wordt van de uiteindelijke oplossing.

Bijvoorbeeld het werk van een data scientist en een beeld van de relevante algoritmen voor de oplossing zal iteratief ontstaan gedurende de analyse activiteiten binnen het project. Dit heeft echter wel invloed op de uiteindelijke configuratie van de oplossing, helder zal zijn dat dit niet in een start architectuur uitgewerkt kan worden bij aanvang.

Betekent dit nu dat een start architectuur overbodig wordt? De organisatie die ik als even beschreef, nam dit als uitgangspunt. Neemt niet weg dat een start architectuur document nog altijd nodig is maar dat het wel heel anders van opbouw zal zijn. Het zal een veel minder gedetailleerde beschrijving van de oplossing bevatten. De kaders die gesteld worden zijn algemener van aard èn er wordt aangegeven hoe ze later in het project concreet gemaakt worden. Ook is het aan te bevelen om aan te geven in welke situaties contact gezocht zal moeten worden met de architect gedurende het project bij welke mijlpalen en welke onduidelijkheden er interactie noodzakelijk is.

Ondersteunen van ontwikkelteams in big data projecten

In de vorige paragraaf zijn we ingegaan op de up front werkzaamheden en de veranderingen die optreden rond de architectuurdocumenten. Deze verandering heeft eveneens gevolgen voor de werkzaamheden tijdens het project en de ondersteuning van de ontwikkel- en beheerwerkzaamheden.

Omdat er een beperkte architectuur wordt opgesteld bij aanvang van een verandertraject zullen de meeste vragen en uitdagingen tijdens de uitvoering van het traject gaan plaatsvinden. Gevolg is dan ook dat een architect tijdens de uitvoering onderdeel dient uit te maken van het ontwikkelteam. Niet om ontwikkelwerkzaamheden uit te voeren maar om de architecturele vragen te beantwoorden met architecturele oplossingen. Dat beantwoorden zal enerzijds bestaan uit de rechtstreekse ondersteuning van het team, anderzijds zullen er detailuitwerkingen van de architectuur gemaakt worden. Deze detailuitwerkingen zullen met het ontwikkelteam maar ook met andere stakeholders  worden gevalideerd. Gevolg is dat er een Just In Time architectuur ontstaat. Dit vraagt een significant andere aanpak voor de architect.

Knelpunten in de traditionele werkwijze

In de bovenstaande paragraaf zijn een aantal aspecten van de dienstverlening van de architect beschreven die problemen op zullen gaan leveren binnen big data projecten. Blijf je als architect op een “traditionele wijze” acteren dan zal je toegevoegde waarde afnemen. Reden om na te denken wat de knelpunten zijn rond deze werkwijze en op welke wijze je wel toegevoegde waarde kunt leveren aan big data projecten.

In het volgende blog gaan we een aantal mogelijke diensten beschrijven waarmee je toegevoegde waarde kunt leveren aan big data projecten.

Lees alle blogs in deze serie over Big Data architectuur

Big data architectuur, welke rol speel je als architect?

Big data project aanpak en de rol van architect

Data architectuur opstellen. Hoe lever je waarde als architect?

Deze blog is geschreven door IT-professionals Bert Dingemans en Han van Roosmalen. Wil je meer informatie over dit onderwerp? Neem eens een kijkje op de site van Bert Dingemans en Han van Roosmalen.