Blog van Casper Otto

Productontwikkeling (deel 4); "Doorontwikkeling"

Sun, 26 Sep 2021 10:02:17 GMT

The Show must go on .... (click here for English version)

Eindelijk is het zo ver. Na lang testen, veranderen en ‘bij-’schaven kunnen we starten met de onthulling. Na maanden gewerkt te hebben aan het product gaat de wereld er kennis mee maken. Hoe pak je dat aan. In dit vierde deel van de reeks wil ik daar dieper op in gaan.

Productontwikkeling, deel 4, “ The Show must go on”.

Je staat voor een grote beslissing; “Het product onthullen en tonen aan de wereld. Je kan je product immers maar één keer introduceren, toch? Ik denk dat het beter in fasen kan. Kleine stapjes. Bedenk maar; Je leert ook eerst lopen en dan pas kun je trainen voor een marathon. Introduceer je product eerst binnen een beperkte groep. Noem het ‘Beta Versie’ en verzamel feedback. Zorg dat je goed contact heb met de gebruikers. Je zal versteld staan hoe goed de woorden ‘Beta Versie’ werken. Gebruikers voelen zich betrokken bij de ontwikkeling, zeker als er naar ze geluisterd word. Het gevoel deel uit te mogen maken van een exclusieve groep trekt toch. Deze groep heeft de mogelijkheid om ambassadeur te kunnen worden van je product in de begin dagen. Wees niet bang om fouten te maken, maar vooral om deze toe te geven. Als iets niet werkt, erken het, verander het en ga verder.

Tijdens de pilot of ‘Beta’ fase kun je al plannen maken om het product uit te rollen naar een groter publiek.

Belangrijke factoren om over na te denken zijn:

Planning : Wanneer is het handig om te releasen? Zijn er andere grote events waardoor mijn product-lancering overschaduwd wordt?
Beschikbaarheid : Als ik het product lanceer kunnen de nieuwe gebruikers er dan meteen mee aan de slag?
Toegankelijkheid : Is het product direct toegankelijk of moeten er eerst andere aspecten geregeld worden door de gebruiker? Mooi voorbeeld was de introductie van een overheidswebsite maar om daar op aan te melden heb je eerst DigiD nodig.
Schaalbaarheid : Is er voldoende capaciteit? Als het een succes wordt (en dat hoop je natuurlijk) moet de pret niet bedorven worden doordat het systeem de vraag niet aan kan.

Vervolgens wil je nieuwe opties toevoegen, de doorontwikkeling van het product. In de MVP ( Minimum Viable Product ) was daar geen tijd en ruimte voor. Belangrijk is om een programma te creëren. Niet alles kan tegelijk. Maak het overzichtelijk, transparant en wissel zichtbare dingen af met minder zichtbare verbeteringen. Het zou mooi zijn als er in het programma thema’s zitten. Dat helpt de focus van de teams te zetten en vast te houden. Ook de gebruikersgroep snapt dan beter dat andere zaken buiten het thema even moeten wachten.

Eén van de grote valkuilen is dat organisaties pas gaan nadenken over doorontwikkeling na de MVP. Hierdoor ontstaat er een gat tussen de eerste (MVP-) release en de opvolgende tweede release. Kans is dat gebruikers afhaken omdat het MVP-product te weinig meerwaarde biedt. In de praktijk is het heel lastig om deze afgehaakte gebruikers weer ‘ aan boord ’ te krijgen. Plan het daarom goed en werk, waar mogelijk, vooruit. Zorg dat er snel nieuwe opties worden toegevoegd. Liever in kleine stapjes dan lang wachten op een grote release, immers “ The Show must go on ”.

Boven al vergeet niet de mensen in het zonnetje te zetten die er maanden keihard aan gewerkt hebben. Dat zijn de echte sterren in de show, geef ze erkenning en waardeer ze. Maak er een feest van. Je gaat ze nodig hebben in het programma.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Productontwikkeling (deel 3); "Productiewaardig maken"

Sun, 16 May 2021 16:24:50 GMT

Een innovatieve weg naar een nieuw product

(click here for English version)

Het idee is geboren, de ooievaar is geland. Hoe pak je als organisatie door? Welke stappen moet je nemen om het idee een goede overlevingskans te geven? In het derde deel van deze blogreeks wil ik dieper in gaan op het productiewaardig maken van een idee.

Productontwikkeling, deel 3, “Productiewaardig maken”.

Hoe mooi en creatief ook een ideefase is, er komt een tijd dat je het idee of de POC (Proof Of Concept) naar een hoger niveau moet brengen en er een product of propositie van moet maken. Om dit goed te doen dien je met een aantal zaken rekening te houden;

Structuur van de organisatie
Techniek
Data
Security
Ethiek
Kwaliteit

Ik zal de bovengenoemde punten stuk voor stuk langslopen en tips geven. We beginnen met het aller belangrijkste; Structuur van de organisatie . Is de organisatie procesmatig klaar voor een nieuw innovatief ( desruptive ) product? Hierbij moet je denken aan continuïteit in de vorm functioneel- en technischbeheer. Waar kunnen je klanten terecht met vragen en hulp? Wat gebeurt er als je product ineens succesvol blijkt te zijn? Kun je opschalen horizontaal, maar ook verticaal. Denk daarbij aan je partners (leveranciers). Vorm (shape) je organisatieprocessen en maak een duidelijk businessdraaiboek. Vergeet daarbij niet de investeerders en je leveranciers te betrekken.

Dan de techniek . Zorg voor een voldoende flexibele techniekkeuze. Zet je zelf niet vast in een niche door je afhankelijk te maken van één leverancier. Probeer het hart van je architectuur ‘main-stream’ neer te zetten. Aan de randen kun je je wat meer permitteren zolang je maar goede afspraken maakt. Let op dat je bij de licenties / subscripties niet ten onder gaat aan je eigen succes. Reken dat goed door.

Data , de inhoud. Soms word er wel eens gezegd dat je er niet genoeg van kan hebben (“ik wil alles”). Trap daar niet in, het gaat je in de hiel bijten qua performance, opslag en kosten. Denk goed na wat je nu nodig hebt voor je product en in de nabije toekomst maar zeker niet verder dan dat. Als de techniek schaalbaar is hoef je er niet over na te denken. Niemand weet hoe de toekomst er exact uit gaat zien, flexibiliteit is dan vele malen belangrijker dan met ‘alles maar rekening te houden’. De kans dat dit bij de toekomstige verwachtingen 1-op-1 aansluit acht ik vrijwel nihil, je kunt het dan beter in één keer oppakken.

Security ; Denk goed na over je data. Hoe gevoelig is de data welke je verzameld. In mijn blog Security by design ( https://www.casperotto.nl/security_by_design ) geef ik een aantal praktische tips. Lees dit vooral en maak een plan.

Vaak denk ik bij de realisatie van een product; “Wat zou ik ervan vinden als het om mijn data gaat?”. Het woord ‘ ethiek ’ ligt dan in het verlengde van je eigen moraal. Het is prima als er geld verdient wordt aan een product maar dat moet wel in verhouding zijn met je normen, waarden en maatschappelijk belang. Betrek deze vraagstukken ook in je businessplan. Wat vind jij aanvaardbaar en wordt dat ook zo door de maatschappij gezien? Zorg dat daar zo min mogelijk verschil tussen zit.

Lever kwaliteit . Test het product en alle aspecten. Ook op mogelijk misbruik. Investeer in een segmentatie architectuur zodat als er iets mis gaat de schade beperkt blijft. Zie het als het inbouwen van ‘branddeuren’ die dicht kunnen vallen bij een brandalarm.

Naast alle bovenstaande facetten stel een duidelijke scope, een MVP (Minimum Viable Product), vast en probeer daar niet te veel van af te wijken. Hou focus en betrek de juiste experts en luister naar de adviezen. Dan komt het vanzelf goed!

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Productontwikkeling (deel 2); "Creativiteit"

Mon, 05 Apr 2021 16:40:08 GMT

Een innovatieve weg naar een nieuw product

(click here for English version)

Productontwikkeling, het begint vaak met een idee, een gedachte aan iets nieuws, beetje in de zin van; “ Wat zou het mooi zijn als ….. ”. Hoe ga je daarmee om binnen een organisatie? Dit blog is de tweede in de serie en gaat over creativiteit in relatie tot productontwikkeling.

Productontwikkeling, deel 2, “Creativiteit”.

Creativiteit, wat is dat eigenlijk? In het woordenboek is de volgende omschrijving te lezen: “Betekenis 'creativiteit', cre·a·ti·vi·teit (de; v); 1) scheppend vermogen” * . In productontwikkeling is dat een essentiële eigenschap. Hoe creëer je scheppend vermogen binnen je organisatie? Ik zie het als een stappenplan welke in lijn moet zijn met de organisatiestrategie, of beter nog de visie. Dat stappenplan helpt je om van heel breed naar een punt toe te werken.

Ik vergelijk het wel eens met het aanvliegen van een vliegtuig op een luchthaven. De luchtvaart gebruikt een systeem “ PAPI – Precision Approach Path Indicator ” **. In elk stadium geeft het systeem een indicatie over de positie van het vliegtuig en de norm. In het begin is het grof en langzaam wordt het steeds nauwkeuriger totdat het vliegtuig op de landingsbaan staat. Als we dit voorbeeld op het traject van productontwikkeling projecteren zijn er wel leuke vergelijkingen te maken. Het scheppend vermogen, creativiteit, is de vlucht. De directie als de luchtverkeersleiding en het team als de bemanning van het vliegtuig. De taakverdeling is duidelijk; De bemanning is verantwoordelijk voor het vliegtuig en de luchtverkeersleiding voor de veiligheid en organisatie. Essentieel zijn de verantwoordelijkheden en het stadium van het proces. Zoek een goede crew bij elkaar. Een team welke elkaar aanvult en uitdagingen vindt in de verschillende aspecten van het te ontwikkelen product. Dus niet allemaal piloten, maar ook niet allemaal stewardessen. De route, hoe start je die? Probeer van grof naar fijn te gaan maar wel met voortgang. Telkens een stapje verder naar het doel. Borg de stappen en leg ze vast. Dit voorkomt dat er in cirkels wordt gedacht. Zelf vind ik het handig ‘gedurende de vlucht’ wat houvast te hebben, dat is ook handig voor de luchtverkeersleiding. Grof weg verdeel ik de vlucht in de onderstaande stappen, maar voel je vrij om stappen er tussen te zetten of samen te voegen. Let wel op dat het over een totaal product gaat.

Stappen in het creatieve proces;

Brainstorm sessies ; Ideeën verzamelen, combineren en weer nieuwe ideeën verzamelen.
Wrap-up sessies ; Borgen ideeën en relevante delen uitwerken om vervolgens weer als input te dienen voor de brainstorm sessies.
Model sessies ; Na voldoende Brainstorm sessies en Wrap-up sessies kan er een poging gewaagd worden om voorzichtig een model te creëren. Geeft niet als het de eerste keer nog nog niet lukt.
Tuning sessies ; Verder uitwerken, meer detail en samenhang toevoegen.
Split-up sessies ; Opknippen van de verschillende onderdelen en de volgordelijkheid aangeven. Groepeer de onderdelen en kijk waar het MVP (Minimum Viable Product) ligt.

Gedurende bovenstaande sessies is er natuurlijk communicatie met de verkeersleiding. Wat het team dan hoop te horen: “... You’re in the flight path looking good ... ”. Wat een vlucht zou dat kunnen worden, misschien met turbulentie of een looping …. moet het team dan wel even aankondigen; “... Please fasten your seat belts and return your tray table to its full upright and locked position ... ”. Totdat het signaal klinkt; “... Cabin crew prepare for landing ... ” en een paar minuten later klinken de verlossende woorden “ ... We’ve just landed on Schiphol Airport ... ”.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

*) https://www.vandale.nl/

**) https://en.wikipedia.org/wiki/Precision_approach_path_indicato r

Productontwikkeling (deel 1); "De harde aspecten"

Sun, 21 Mar 2021 18:28:56 GMT

Een innovatieve weg naar een nieuw product

(click here for English version)

Productontwikkeling, het begint vaak met een idee, een gedachte aan iets nieuws, beetje in de zin van; “ Wat zou het mooi zijn als ….. ”. Hoe ga je daarmee om binnen een organisatie? Omdat het een groot onderwerp is wil ik er vier blogs aan wijden. Het eerste deel gaat over de ‘harde’ aspecten en voorwaarden. In het tweede wil ik ingaan op de creatieve aspecten. Vervolgens wil ik in het derde deel het productiewaardig maken bespreken. Als toegift wil ik in een vierde deel aandacht besteden aan doorontwikkeling.

Productontwikkeling, deel 1, “ De harde aspecten ”.

Om iets nieuws te ontwikkeling moet er een goed klimaat gecreëerd worden. Het hangt een beetje af van de organisatie maar je kan er voor kiezen om het product buiten je organisatie te ontwikkelen. Is je organisatie wendbaar en is er voldoende kennis aanwezig zou ik snel de keuze maken om het product binnen de organisatie te ontwikkelen, met ondersteuning. Da’s veel leuker en het helpt ook de acceptatie en de levenscyclus binnen de staande organisatie. Daarover meer in delen drie en vier. Ook vergt het wel wat van de creativiteit van je medewerkers en hoe dat in te richten komt in deel twee aanbod. In dit deel richt ik me op de harde aspecten. Wat zijn dat die harde aspecten? En waarom zijn ze zo belangrijk. Onder harde aspecten versta ik; strategie, budget en proces. Ze zijn zo belangrijk om dat deze zaken houvast geven in de bochtige weg van innovatieve productontwikkeling. Zij zijn het baken om tot ‘iets’ of ‘niets’ te komen, eigenlijk het enige houvast.

Strategie.

Zorg voor een duidelijke strategie, een visie, waarbij mensen geïnspireerd raken. Let er wel op dat die strategie ruimte biedt voor invulling, anders verwordt de strategie tot meer een werkinstructie en dat is zonde. Bedenk dat een strategie of visie coachend moet zijn. Het team moet het zelf doen, net als in de sport. Neem ruim de tijd als organisatie om een goede gedragen strategie en visie neer te zetten. Het zal je in de rest van de processen veel tijd schelen. Bouw ijkpunten in om de strategie en visie bij te stellen. Niemand weet immers wat de toekomst brengt of welke disruptieve innovaties op het pad komen. Wees ook niet bang de strategie of visie aan te passen, maar denk er goed over na.

Budget

Productontwikkeling kost geld. Ik herhaal het nogmaals: Productontwikkeling kost geld! Kosten gaan immers voor de baten uit zo luidt het spreekwoord. Plan productontwikkeling goed. Zorg dat je organisatie gezond is en blijft zodat je budget vrij kunt maken. Ik adviseer wel om, als het concept idee goed is, er ‘ All-in ’ mee aan de slag te gaan. Als je iets doet, doe het goed, beknibbel niet. Dat ga je namelijk altijd zien, of erger nog je concurrenten. En als zij wel ‘ All-in ’ gaan kan je zomaar ingehaald worden.

Proces

Het proces is de derde belangrijke pijler. Productontwikkeling kent verschillende (hoofd) fasen. Haal deze niet door elkaar want dan loop je de kans dat het team of de organisatie er niets meer van snapt. Je organisatie ‘ Buy-in ’ brokkelt dan in rap tempo af en je team voelt zich niet meer gesteund.

Welke fasen kun je grofweg onderscheiden;

Start ; In deze fase is het uitproberen, aftasten. ‘ POC-en ' (Proof Of Concept). Vallen en opstaan. Niet nadenken over security of beheer.
Prototype ; Aan de hand van de eerste fase een prototype opbouwen. Dus niet een POC ombouwen maar met een echt goede structuur beginnen. Doe onderzoek.
Uitwerken ; Zoek medestanders, ‘ Launching Customers ’, om samen met het team het prototype uit te proberen en te verbeteren. Doe verder onderzoek.
Pilot ; De eerste voorzichtige stappen naar een echt product. Gebruik het prille product in een gecontroleerde (pilot) omgeving. Noem het ‘beta’ of iets van die strekking. En verzamel gegevens om te combineren met je onderzoek. Klopt het nog? Zijn de verwachtingen nog realistisch? Stuur bij.
Integratie ; Nu wordt het serieus. Maak je organisatie klaar voor een nieuw product. Pas lijnprocessen aan indien nodig en creëer focus in de lijnorganisatie. Gebruik je onderzoek en de gegevens van de pilotfase om draagvlak te creëren en te houden.
Livegang . Zorg dat alles bij elkaar komt. Techniek, organisatie en mediamomenten. Het kind is geboren. Zet de ooievaar maar in de tuin en sla beschuit en muisjes in. Vier het moment. Let op dat je oog heb voor nazorg. Stuur desnoods bij als dat nodig is.

Door je een beetje aan bovenstaande fasen te houden is het wel zo duidelijk en zijn de verwachtingen veel beter te managen. Dat zal de sfeer in het team en de organisatie zeker ten goede komen. Productontwikkeling moet namelijk een feestje zijn!

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Security by design

Sun, 31 Jan 2021 18:52:50 GMT

Meer dan alleen een slot op de deur. (click here for English version)

Laatste tijd hoor ik er veel over in de media; - datalekken -. We leggen veel data vast in systemen welke relatief makkelijk zijn in gebruik. Daar bovenop komt dat het thuiswerken ook de sociale controle vermindert. Deze combinatie blijkt gevoelig voor misbruik van data. Wat kun je als organisatie doen om dit tegen te gaan?

Om dit vraagstuk te beantwoorden is het goed om het op te knippen in een aantal onderdelen;

Technisch; hardware (infra) en software (applicaties)
Procesmatig; functies, processen en ‘ease-of-use’
Sociaal; bewustwording en cultuur

De eerste categorie (Technisch) is naar mijn mening als CTO de makkelijkste. Richt Identity en Access Management goed in (IAM, beheer van identificatie en toegang). Beperk en segmenteer je infrastructuur en hardware zodat je niet één groot netwerk hebt waar alles en iedereen toegang tot heeft. Probeer dat ook op hardware niveau te realiseren. Een stap hoger naar applicaties is naast identificatie, de toegang tot de applicatie, ook belangrijk dat je de authenticatie inricht. Makkelijk om te onthouden: identificatie zegt iets over OF iemand toegang heeft. Authenticatie zegt iets over WAAR iemand toegang tot heeft. Ik adviseer altijd de tweede (authenticatie) zo op te zetten dat het werkbaar blijft (en niet iedereen alsnog de zwaarste authenticatie nodig heeft) maar toch duidelijke segmenten te creëren in lijn met functies en processen. Streef een duidelijke rol-scheiding na, maar daarover later meer. Vergeet ook niet toezicht in te richten en vast te leggen zeker bij gevoelige gegevens: “wie wanneer waar naar heeft gekeken”. Zorg ook dat er een proces is om misbruik te detecteren en er opvolging aan te geven. In films zie ik dat vaak dat iemand inlogt in de computer van de FBI en er gelijk allemaal zwaailichten afgaan en mensen gealarmeerd worden.

Naast bovenstaande is de procesmatige inrichting van je organisatie ten aan zien van security minstens zo belangrijk. Immers luidt het spreekwoord “… gelegenheid maakt de dief …”. Let daarbij op dat functies zo zijn afgestemd dat ze elkaar nodig hebben, aanvullen en controleren. Zorg ook dat je niet te weinig barrières opwerpt maar ook niet te veel. Bij te veel barrières zie je vaak dat het lastig is om geautoriseerd te worden tijdens een verlof of vakantie van een collega en er dan maar gewerkt word met de identificatie en autorisatie van de collega. Tja dan helpt de techniek hier ook niet tegen. Ook ‘on-boarding’ en ‘off-boarding’ zijn belangrijk. Als iemand start met werken maar nog belangrijker als iemand stopt met zijn werkzaamheden en de organisatie verlaat. Wat nog vaker mis gaat is wanneer iemand promotie maakt en bij een andere afdeling gaat werken om z’n authenticatie aan te passen (doorstroom). On-, off-boarding en doorstroom moeten goed verankerd zijn in de processen van de organisatie.

Als laatste punt wil ik het sociale benadrukken. De organisatie moet investeren in een veiligheidscultuur. Een cultuur waarbij medewerkers zich bewust zijn van de gevaren en risico’s en daar ook om geven. Zorg dat deze bewustwording dicht bij de individuele normen en waarden liggen. Ook moet het management luisteren naar de medewerkers en stappen ondernemen als er terecht zaken worden aangekaart. Bagatelliseren is schadelijk voor al de voorgaande punten, als de baas zich niet druk maakt over security, waarom zullen wij dat wel doen? Zo zie je maar weer dat het sleutelwoord samenwerken is!

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Foto: De Nieuwe Hollandse Waterlinie;

https://nieuwehollandsewaterlinie.nl/

https://odeaandehollandsewaterlinies.nl/

Schaalbare Architectuur

Sun, 06 Dec 2020 11:51:01 GMT

Een ' must have ' voor iedere organisatie. (click here for English version)

Websites, mobile-apps en IOT zijn niet meer weg te denken in een organisatie om te communiceren met klanten en business partners. De opzet van digitale platformen word steeds belangrijker. Het antwoord lijkt gevonden in een flexibele opzet van de digitale architectuur; Schaalbare Architectuur.

Schaalbaar zowel horizontaal, -- meer dezelfde processen naast elkaar --, als verticaal, -- nieuwe specialistische processen binnen een kolom --, zijn noodzakelijk om technisch flexibel te blijven binnen de organisatie. Flexibel, daar zit gelijk ook een valkuil. Vaak zie je dat hoe flexibeler een digitale architectuur is hoe complexer deze zal zijn, zeker met de invulling over twee assen (horizontaal en verticaal). Daarnaast krijg je te maken met reeds bestaande platformen, structuren en processen, de zogenaamde ‘legacy architectuur’. Hoe maak je daar nu een schaalbaar en flexibel geheel van welke ook nog goed te beheren en makkelijk uit te breiden is in de toekomst? Dat schreeuwt naar een visie, strategie en aanpak. Mijn advies is altijd; ‘Denk groot (niet ‘te groot’), start klein (ook niet ‘te klein’) in visie en strategie. Houd de aanpak overzichtelijk en betaalbaar. Zorg dat het geheel bij de organisatie past. Besef dat je een architectuur niet alleen moet neerzetten maar ook moet kunnen beheren en veranderen als deze in gebruik is. Vaak wordt de beheer component vergeten in alle plannen en kom je na in gebruik name voor verrassingen te staan.

Wat heel goed kan werken is een ‘ICT-transitie programma’ op te zetten en alle facetten hierin een plaats te geven. Met zo'n ICT-transitie programma houd je het ook voor een niet technisch publiek overzichtelijk en begrijpelijk. Ook laat je zien dat niet alles in één keer hoeft te veranderen maar dat de organisatie geleidelijk naar een punt op de horizon beweegt. Houd in het ICT-transitie programma voldoende ruimte om bij te kunnen sturen met nieuwe technieken of een nieuwe business koers.

Als inspiratie voor technologie topics verwijs ik naar mijn eerdere blogs;

Headless Architecture , https://www.casperotto.nl/headless_architecture
Big Data , https://www.casperotto.nl/big_data
Omnichannel, https://www.casperotto.nl/omnichannel
Cloud Infrastructuur , https://www.casperotto.nl/cloud_infrastructuur
Big Data Strategie , https://www.casperotto.nl/big_data_strategie

Planmatig staan er wat tips in mijn blog over Plan en Strategie , https://www.casperotto.nl/plan_en_strategie .

Veel om te lezen en te combineren. Nu de wintermaanden aanbreken het jaar ten einde loopt, we voor komend jaar weer goede voornemens en plannen maken, is het goed om inspiratie op de doen. Probeer een aanzet te geven, praat met mensen maar bedenk de plannen vooral samen.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Big Data

Sun, 04 Oct 2020 08:41:53 GMT

Het digitale goud, de gegevens bekeken. (click here for English version)

Websites, slimme apparaten, het internet der dingen (IOT) het lijkt wel een stofzuiger voor het verzamelen van data, veel data. Als je naar de curves in de grafieken kijkt van hoeveelheden data die worden opgeslagen zie je dat exponentieel toenemen; “ Big Data ”.

Hoe ga je binnen de organisatie met Big Data om? In mijn eerste blog ( Big Data Strategie , https://www.casperotto.nl/big_data_strategie ) schreef ik over het opzetten van een strategie. In dit blog wil ik het hebben over de data zelf. Om de data zelf op te slaan heb je regels nodig, zie het als vaarregels, om een beetje in de analogie te blijven van mijn blog Big Data Strategie; "... Een watersportvakantie in de Nederlandse provincie Friesland ... ".

Hoe stel je deze vaarregels op, waar moet je op letten? De eerste fase is je data te classificeren in " persoonsdata " en " bedrijfsdata ". Onder persoonsdata wordt grofweg alle data verstaan welke direct of indirect te herleiden is naar een individu en daar heb je een aantal gradaties in, onder andere;

Persoonlijke data ; Hier worden bijvoorbeeld adresgegevens onder verstaan.
Gevoelige data ; Gegevens welke onder andere ras, geloof of overtuiging vastleggen.
Medische data ; Data met een medische inslag. Bijvoorbeeld diagnoses, ziekten en medicijnen.
Gedragsdata ; Data welke gedrag en patronen in kaart brengt van een individu.

Veelal gaat het bij bedrijfsdata om gevoelige data die voor de organisatie belangrijk is voor het vervaardigen van inzichten en het versterken van de concurrentiepositie. Hieronder vallen bijvoorbeeld de volgende categorieën;

Geaggregeerde (patroon-) data ; (Bedrijfs-) data welke niet te herleiden is aan een individu
Prijs informatie ; Waaronder bijvoorbeeld data met betrekking tot marge, inkoop-, kost-, en verkoopprijs.
Strategisch ; Data met betrekking tot bedrijfsstrategieën.

Om een goed Big-Data-Plan te maken is het belangrijk je dataverzamelingen te classificeren . Bovenstaande categorieën kunnen helpen. Neem vervolgens de plaats waar de data opgeslagen wordt en toegankelijkheid onder de loep in een Risicoanalyse . Op de uitkomsten en inzichten van deze onderzoeken bouw je de regels op (‘vaarregels’) dit om zo goed als mogelijk met je gegevens om te gaan. Deze ‘vaarregels’ samen met de classificatie en risicoanalyse kun je natuurlijk laten toetsen (audit) aan wet- en regelgeving. Belangrijker nog vind ik om de opzet ook te toetsen aan ethische normen en (bedrijfs-) waarden.

Big Data wordt wel eens het digitale goud genoemd. Laten we dat digitale goud goed opbergen, er zuinig op zijn en de Big Data inzetten voor iets goeds .

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

User eXperience

Sat, 19 Sep 2020 09:53:12 GMT

Een klantreis door een woud van functionaliteit, techniek en ideeën. (click here for English version)

Dit blog gaat over het ontstaan van een digitaal platform, in mijn subtitel aangegeven als ‘woud’. Steeds meer organisaties ontdekken de meerwaarde van een digitaal platform, maar worstelen met de invulling ervan.

Binnen organisaties worden antwoorden gezocht op onder andere de volgende vraagstukken; Hoe te beginnen? Voor wie is het? Wat levert het op? Dat laatste wordt door de sceptici meestal vervangen door; Wat kost het? Dat is jammer want een digitaal platform hoeft geen kostenpost te zijn bij een juiste business case. Immers ' wat levert het op ' is een resultaat van opbrengst minus de kosten. Let er op dat onder ' wat levert het op ' niet alleen geld valt, maar ook marktpositie, doorgroei potentie, slagkracht en klantbinding.

Hoe start je nu zo’n digitaal portaal? Misschien is de volgorde in de subtitel je opgevallen; functionaliteit , techniek en ideeën . Dat is vaak hoe ik zie dat een organisatie een poging waagt om een klantportaal te realiseren. Vanuit een specifieke functionele behoefte wordt er een set van functionaliteiten (scope) afgebakend, het zogenaamde ‘MVP’ (Minimum Viable Product). Aan de techniek de eer om dit te realiseren. Gedurende het realiseren ontstaan er allerlei nieuwe ideeën waardoor de scope onder druk komt te staan, het ‘MVP’ verandert en de deadlines verschuiven. Erger is dat, als je niet oppast, ook de focus verdwijnt en het hele project een andere wending krijgt. Naast al het voorgaande houdt vooral het belang van je klant in het oog. Zet de klant centraal in elke discussie. Is het voor de klant logisch, voegt het iets toe? Kan de klant logisch, eenvoudig en veilig door het woud lopen?

Ideeën ontstaan meestal als een groep gefocust bezig is en de vraagstukken van meerdere kanten – multidisciplinair - bekijkt. Liefst met de digitale mogelijkheden in het achterhoofd van de huidige tijd. ' Een oldtimer kan soms een statement zijn maar in deze context wil je een auto met de juiste techniek aan board. ' Starten met alleen de focus op functionaliteit of alleen op techniek is dus niet handig. Luister naar elkaar, waardeer elkaars expertise. Laat de klant (gebruiker) een centrale rol in nemen, het gaat immers ook om de ervaring van de gebruiker de '... User eXperience ...' .

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Omnichannel

Sun, 23 Aug 2020 11:16:17 GMT

Een fantastische klantervaring … of … jungletocht door de techniek? (click here for English version)

De afgelopen periode zijn er veel apparaten en mogelijkheden bijgekomen. We leven in een technologietijdperk. Soms vraag ik me wel eens af of de techniek er is om ons te helpen of andersom? Omnichannel Strategie kan je daar bij helpen, mits je hem aanvliegt vanuit de gebruiker.

Wat is een Omnichannel? Vrij vertaald (in mijn ogen): Omnichannel is de inzet van technologie waarbij je de klant centraal zet en hem of haar het medium (apparaten en/of applicaties) laat kiezen om te communiceren. Dat kan een combinatie zijn van verschillende technieken welke naadloos in elkaar over horen te vloeien. Bij het naadloos in elkaar overvloeien van technologie is de grote valkuil vaak de logica vanuit de klant gedacht. Het blijkt soms enorm lastig voor organisaties om zich echt in hun klantengroep te verplaatsen en inzicht te hebben in hun gedachtepatroon. Ik denk vaak terug aan vroeger. Ben opgegroeid in een kleine stad en iedereen kende elkaar. Als mijn moeder bij de bakker kwam wist de bakker wie z’n klant was en wat deze nodig had. Ook adviezen werden daarop afgestemd. Dit is voor mij het vertrekpunt voor een goede strategie. Zet niet alleen de klant centraal maar ken hem ook! Onderzoek of en hoe je klant zit te wachten op een Omnichannel benadering.

Soms hoor ik het voorbeeld; “ … Als de klant iets in zijn winkelmandje stopt via zijn laptop nou dan moet hij zijn bestelling af kunnen maken met een ander medium bijvoorbeeld zijn telefoon … ”. Ik vraag me dan altijd af: waarom? Is het omdat het kan of omdat het handig is. Welke massa’s van je klanten schreeuwen om deze methode? Niemand kan het me echt vertellen en als er een onderzoek naar word gedaan blijkt de minder geavanceerde oplossing een prima keuze.

Om bij het opzetten van een Omnichannel Strategie te helpen heb ik wat aandachtspunten opgesteld;

Ken je klant. Weet wat hij of zij wil en nodig heeft. Dat hoeft per definitie niet hetzelfde te zijn!
Weet wat je klant aan technologie gebruikt of bereid is te gebruiken in de toekomst.
Betrek de klant bij nieuwe toepassingen en mogelijkheden. Omdat iets kan wil het per definitie niet zeggen dat het zinnig is (in de ogen van de klant/gebruiker).
Maak de klant bewust van de voordelen. Als er hiermee 24/7 openings- en afhaaltijden zijn te realiseren benoem dat en zoek uit of ook de (toekomstige) klant hierop zit te wachten. Leuk onderzoek is bijvoorbeeld het afsluiten van reisverzekeringen dat gebeurt meestal ’s nachts en op het laatste moment. Dan is online een goed medium gebleken.
Hou contact met je klant. Waar kan je klant terecht met vragen als iets niet (voor de klant) logisch lijkt te werken. Kun je hem begeleiden naar een oplossing?
Bouw Omnichannel langzaam op, laat je klanten wennen aan het idee en neem ze mee in de toekomstige ontwikkelingen.

Het belangrijkste punt is wel: Hou het voor de klant simpel en overzichtelijk. Omnichannel kan een mooie en waardevolle ervaring zijn voor zowel organisaties als klanten. Have fun!

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Headless Architecture

Mon, 01 Jun 2020 08:40:20 GMT

One-backend-fits-all …. (click here for English version)

Nu er veel nagedacht wordt over Digitale Transitie rijst de vraag; “ Wat doen we met al die digitale gegevens? ” Waar vroeger de website het eindstation was zijn er anno 2020 betere oplossingen. Waarom je beperken tot een website, of mobiel? “ -- Mobile first -- ” is een veel gehoorde kreet. Ik pleit er voor dat om te bouwen naar “ -- API-first -- ” (API staat voor; Application Programming Interface).

Als we de software architectuur verdelen in een voor- en achterkant en we zetten daar een laag tussen die dat allemaal verbindt. We waren immers toch al bezig met het schaalbaar maken van de backend systemen (achterkant) in het kader van de digitale transformatie (Lees ook mijn blog over Digitale Transformatie , https://www.casperotto.nl/digitale_transformatie ). Hoe mooi is het als je een API-laag creëert waarop je alles zou kunnen aansluiten: een website of een mobiele applicatie of een koppeling met een ander platform of ….. wat je maar wil. Je bent flexibel om te doen wat voor jouw bedrijf het beste is. Bijvoorbeeld voor klanten een portaal realiseren waar ze zaken zelf kunnen regelen. Of koppelen met een ander portaal van een partner bedrijf. Ongekende mogelijkheden.

Van belang is wel om de digitale transformatie goed door te voeren. Als systemen op een goede manier gekoppeld zijn heb je daar veel profijt van. Belangrijke vraagstukken zul je moeten beantwoorden (onder andere);

• Welke delen van de architectuur gedragen real time, welke niet?

• Waar leg ik gegevensverzamelingen aan?

• Waar moet ik buffers creëren om niet (te) afhankelijk te zijn van andere systemen?

• Waar maak ik gebruik van API’s en waar van (micro) services?

Belangrijk is om goed het evenwicht in het oog te houden. Net als met alle goede apparaten moeten de componenten in balans zijn. Alleen dan werkt het optimaal samen.

Naast het technische is het ook belangrijk dat je een groep met de juiste mensen samen stelt. Met focus op techniek, business en financiën. Multi disciplinair, laat ze samen werken, stel kaders op maar zo min mogelijk doelen. Laat het team dat doen, je kunt de uitkomst toetsen aan de strategie welke je voor ogen hebt. Misschien word je wel verrast met een uitkomst die je niet voor mogelijk had gehouden. Dat geeft je als ondernemer ook een boost, nieuwe terreinen verkennen, nieuwe dingen leren en ontdekken. Iedere disruptieve gebeurtenis, hoe vervelend ook, opent de deur voor nieuwe kansen en oplossingen. Laten we er wat mee doen!

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Mobiele Apps

Sun, 19 Apr 2020 10:42:52 GMT

Het digitale goud .... (click here for English version)

Mobiele Applicaties, ook wel Apps zijn bijna niet meer weg te denken uit marketing strategieën. Vaak zie je dat de marketingfocus ligt op het communiceren met de consument via het mobiele kanaal de zogenaamde “mobile first-”-strategie. Maar werkt dat ook? Wanneer wordt het een succes?

Als ik kijk naar succesvolle Apps zijn dat allemaal programma’s welke iets toevoegen. Waar zit de consument op te wachten? Deze succesvolle Apps kloppen, zijn logisch, makkelijk in gebruik en voegen iets toe. Bij een Mobiele App zijn de belangrijkste criteria onder andere; ‘overal nodig’, ‘locatie onafhankelijk’, ‘persoonlijk’, ‘snel in gebruik’, ‘intuïtief’. Daarnaast is het belangrijk dat je de vraag stelt; “Zou ik het zelf gebruiken?” (Lees ook mijn blog over Disruptive Technology , https://www.casperotto.nl/disruptive_technology ).

Zodra je de juiste ' nut' en ' noodzaak' gevonden heb kies je de technologie, bedenk waar de gegevens vandaan moeten komen en hoe de veiligheid gegarandeerd kan worden. Begin klein, maar maak het platform schaalbaar naar de toekomst toe. (Lees ook mijn blog over Digitale Transformatie , https://www.casperotto.nl/digitale_transformatie )

Ook voor Mobiele Apps geldt: maak een plan. Laat de juiste mensen met de goede competenties over zaken beslissen. Wees realistisch maar durf te dromen en gewogen risico’s te nemen. Maak er echt een ontdekkingsreis van met multidisciplinaire teams. Zorg wel dat de mensen in het team elkaar aanvullen en versterken. Naast de creatie van een App denk ook na over het inpassen van zo’n App binnen je organisatie. Regel ondersteuning in op zowel functioneel als technisch vlak. Maak een plan over de verdere doorontwikkeling. … De creatie van een App stopt niet bij de lancering, dan begint het pas …

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

#Stay@home

Sun, 29 Mar 2020 11:09:26 GMT

Verveling en fouten een ideale combinatie? (click here for English version)

Binnen blijven, weken achtereen, de verveling slaat toe. Is dat slecht? Er zijn onderzoeken die beweren dat je verveling nodig heb om creativiteit te ontwikkelen. Nu ten tijden van thuisblijven, #stay@home, slaat de verveling toe. Tijd om te ‘klooien’ met ‘what-ever-it-is’. Op social media zie je de meest creatieve uitingen voorbij komen. Vaak gemaakt met beperkte middelen. Die kunnen alleen maar bedacht zijn uit pure verveling.

Als we bovenstaande beschouwen in het kader van innovatie, zie ik een paar belangrijke ingrediënten om te komen tot ‘iets’ nieuws. Ten eerste; Verveling . Tijd en ruimte om je gedachte ergens rustig over te kunnen laten gaan. Ten tweede; Schaarste . Door schaarste word je vindingrijk en combineer je dingen die je normaal gesproken niet zou overwegen. Ten derde; Lef . De durf om zaken uit te proberen en vol te houden. Ten vierde; Vertrouwen . In een vertrouwde omgeving, Niet bang te hoeven zijn om fouten te maken. En als vijfde: Doorzetten . Blijven proberen, volhouden tot het lukt. Niet opgeven bij de eerste keer, gewoon doorgaan. Eventueel plan aanpassen en opnieuw proberen. Uiteraard helpen een aantal katalysatoren bij de bovenstaande punten zoals; humor, noodzaak en saamhorigheid.

In een innovatieve organisatie is het belangrijk om invulling te geven aan de bovenstaande punten. Verveling ; medewerkers moeten de tijd krijgen ergens over na te kunnen en mogen denken, zonder dat ze gebombardeerd worden met hoeveelheden werk en deadlines. Schaarste ; Stimuleer medewerkers eerst iets op te zetten met beperkte middelen. Dan is het maar niet zo fancy in het begin. Hierdoor wordt de (budget) druk ook een stuk minder. Vertrouwen ; Geef je medewerkers vertrouwen in niet alleen het ‘lukken’ van iets maar ook in het ‘mislukken’ . Dat laatste in misschien nog wel belangrijker dan het eerste. Zelf geef ik stee vast medewerkers een target mee van ‘ Minimaal 5 fouten per jaar maken ’. Dat blijkt nog lastiger dan gedacht voor de medewerkers kan ik je zeggen. Uiteraard moeten ze, zodra ze een ‘fout’ hebben gemaakt het eerlijk toegeven. Standaard heb ik twee checkvragen; 1 – Maakte je de fout met opzet, expres? Als dat het geval blijkt is het geen fout meer maar opzet. Dan volgt er een ander gesprek. 2 – Wat heb je van de fout geleerd? Als je de fout herkent als leermoment dan is het van nut om deze situatie te ervaren. Dat is de reden waarom ik een paar zinnen terug het woord fout tussen aanhalingstekens heb geplaatst. De fout wordt een leermoment. Op deze manier stimuleer je medewerkers om ook een keer ‘iets nieuws’ te proberen en niet altijd te kiezen voor het vertrouwde, Lef en Doorzetten . Stimuleer je medewerkers niet te stoppen bij de eerste tegenslag, zet door. Maar wees realistisch. Werkt het niet? Probeer gerust iets anders.

In de tijd van thuiszitten, vervelen zouden er dus hele mooie innovatieve ideeën kunnen groeien en bloeien. Zoek elkaar op, natuurlijk niet letterlijk! Wissel ideeën en gedachten uit. Probeer iets geks, maak bijvoorbeeld gebruik van de katalysator humor. Ik zeg: “ … doe eens creatief, stay safe, #stay@home … “.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Cloud Infrastructuur

Sun, 08 Mar 2020 09:04:27 GMT

Met je business in de wolken.
Infrastructuur als een ‘ Blackbox ’ of niet ? (click here for English version)

Cloud, het begon als een hype en is nu ‘ to stay ’. Alles wat vroeger in de bezemkast stond gaat de wolken in. Van ‘On-Premise’ naar ‘De Cloud’, Liefst als Software-as-a-Service (SaaS) of op een Platform-as-a-Service (PaaS). Als dat niet kan dan door middel van het ‘Lift-and-Shift’ principe op een of Infrastructure- as-a-Service (IaaS). Met name de laatste twee -- PaaS en IaaS -- roepen vragen op.

De infrastructuur uitbesteden, hoe doe je dat en hoeveel kennis heb je nodig voor technische regie? Vaak zie je dat organisaties de ‘ ontzorging ’ op infragebied koppelen aan het ‘ Blackbox ’ denken. Alles afdekken met een contract en klaar. De technische infrastructuur wordt beschouwd als een ‘ Blackbox ’ onder regie van de leverancier. Het gevaar hiervan is dat organisaties het ontzorgen verwarren met technische onwetendheid. Daarnaast schept het verkeerd gebruik van terminologie vaak verwarring. Je merkt dat beide partijen het over totaal iets anders hebben in een gesprek. Zeker in de raakvlakken alerting, monitoring en up-time zie je dat de IaaS partner iets anders bedoeld dan de organisatie voor ogen heeft. Er ontstaan grijze gebieden waar de IaaS partner en de organisatie samen werken en in elkaars water varen. Om dat te kunnen doen is inzicht van elkaars gebied nodig.

Hoe ga je hiermee om als organisatie? Als eerste begint het met technisch inzicht bij de aanschaf en opzet. Vraag om een Reference Architectuur . Deze Architectuur verschaft inzicht en hoort onder andere de vragen als robuustheid, flexibiliteit, schaalbaarheid en netwerksegmentatie te beantwoorden. Het biedt de basis voor een risicoanalyse welke de CIO en de business gebruikt om te bepalen of de technische oplossing op een juiste manier de behoefte van de organisatie afdekt. Laat de technische specialisten met elkaar overleggen niet alleen op infra gebied, maar ook een laag hoger, de applicaties. Dit zijn immers de auto’s die over de weg moeten rijden, dan is het wel handig als de weg ook aan de verwachtingen voldoet. Ook geeft het de partner meer inzicht voor welke auto’s de weg geschikt dient te zijn. Waar liggen de uitdagingen en zwakheden? En hoe kunnen daar maatregelen voor ingeregeld worden?

Ik vergelijk bovenstaande wel eens met het bezoek aan een toprestaurant. Je bezoekt de website, checkt referenties / meningen, bekijkt de menukaart en reserveert een tafel. Als je bij het restaurant aankomt heb je een bepaalde verwachting. Vaak is er een open keuken en je ziet hoe de gerechten bereidt worden. Op de andere tafels zie je wat er geserveerd wordt en je besluit om het ‘verrassingsmenu’ te kiezen, beetje ‘ Blackbox ’, maar ja het vertrouwen is er. Dan sta je toch raar te kijken als het eerste gerecht een ‘ Patatje-Joppie-Saus ’ is. Contractueel geen spelt tussen te krijgen, een verassing is het zeker. Onthoud één ding; “ …. de ene Cloud is de andere niet …. ”

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

The Art Of Software Architecture

Sun, 23 Feb 2020 12:01:25 GMT

Koken op niveau (click here for English version)

Software Architectuur wordt steeds complexer. Een aantal jaren geleden werd vaak gekozen voor een totaal oplossing; “ Best-of-Suite ”. Vandaag de dag zie je steeds meer een aaneenschakeling van losse componenten, allemaal het beste in het uitvoeren van een specifieke taak; “ Best-of-Breed ”.

Hoe kun je als Software Architect nu om gaan met deze trend? Ik vergelijk het vaak met eten (heb ook bourgondische levensvoorkeur). Zie de Software Architect als een Chef Kok en vergelijk de architectuur met een menu. De applicaties zijn de ingrediënten. Keuzes welke een Chef maakt moet jij ook maken; ….. Hoeveel gangen heeft het menu? Zoet of hartig? Veel of weinig? Dure (exclusieve) of goedkope gerechten? Zelfgemaakt ijs of van de supermarkt? ….. Ook de wijze van bereiden, hoeveelheden en timing zijn van belang voor een super gerecht.

Laten we eerst eens kijken naar de ingrediënten. In een Hollands gezin werd er vroeger Hollandsepot gekookt (en geprakt of gestampt). Volgens een vast recept, op grootmoederswijze (Best-of-Suite). Er was één uitzondering op zondag; “de Chinees”. Dat had te maken met vader en zijn Studio Sport.

Zo’n 50 jaar geleden werd de paprika in Nederland geïntroduceerd. Vanaf dat moment zijn er tal van nieuwe - soms exotische - ingrediënten bij gekomen. Ook een tal van nieuwe recepten. De “Fusion Keuken” deed zijn intrede. Hierbij worden verschillende stijlen gecombineerd tot een smakelijke maaltijd (Best-of-Breed). Nog even over die recepten, hebben jullie dat nou ook? Je volgt een recept - met militaire precisie – maar het resultaat is niet hetzelfde als op het plaatje of op televisie, …. oh ja het duurde ook twee keer zolang. Terwijl de Chef soepel alles voordoet en daar bij nog grapt; “.... Een ieder kan het maken ....”. Yeah right, dat valt dus tegen. Zeker als je daarbij nog gaat experimenteren met verschillende ingrediënten: Chocolade is op zich lekker en tomaten ook, maar bij elkaar?

Bovenstaande kun je één op één vertalen naar Software Architectuur. Architectuur principes (recepten) zijn prima te combineren met allemaal nieuwe applicaties (ingrediënten). Je moet je wel telkens de vragen stellen: Waardoor, waarom, wanneer, waarmee en hoe? Dit zijn de onderliggende vragen achter een goede en flexibele architectuur. De keuzes welke hieruit voortvloeien zijn niet te vatten in een If-Then-Else-procedure (recept). Je heb een professioneel team nodig voor de bereiding en veel oefenen want: “ .... Oefening baart kunst .... ”.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Digitale Transformatie

Sun, 09 Feb 2020 11:33:10 GMT

Verandering in gebruik van technologie (click here for English version)

De inzet van technologie gaat sneller dan ooit. Slimme technologie voor het steeds persoonlijker maken van de interactie met een organisatie. De zogenaamde ‘mijn omgevingen’ zijn in opmars. Diensten verschuiven zich van ‘ off-line ’ naar ‘ on-line ’. Het wordt gemakkelijker om zaken te regelen, processen in te zien, producten en diensten af te nemen. Liefst 24x7 het hele jaar door. Technologie is getransformeerd naar een instrument om het de consument gemakkelijker te maken.

Verandering in gebruik van technologie door organisaties is noodzakelijk. Clusteren van gegevensverzamelingen (Master Data Management, MDM), samenvoegen van toegang (Identity and Access Management, IAM) en het instellen van generieke koppelvlakken (Application Programming Interface, API). Zo kun je op verschillende systemen doormiddel van één keer inloggen al je producten, diensten en instellingen regelen. Om dit mogelijk te maken zijn er aan de achterkant (backend) veranderingen nodig in het koppelen en gebruik van technologie. Waar eerst één keer per dag goed genoeg was (batch) moet nu alles liefst gelijk (real time). Dat vraagt nogal wat van de digitale architectuur, op alle vlakken. De opmars van ‘On-Premise’ naar ‘Cloud’. Voor zowel infrastructuur; IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-Service), als voor applicaties SaaS (Software-as-a-Service). In rap tempo worden applicaties geschikt gemaakt voor het gebruik in een ‘Cloud Architectuur’.

Er is, zeker op technologisch vlak, veel in beweging. Vraag is hoe speel je daar als organisatie handig op in? Mijn advies is maak een flexibel plan, wees realistisch en durf te investeren. Niet alles hoeft op het zelfde moment. Overigens; Wat is daar nou leuk aan? Soms is de reis naar iets nieuws ook leuk en spannend. Ontdek samen wat wel en niet werkt. Experimenteer en ondersteun nieuwe technieken en initiatieven. Werk met multidisciplinaire teams aan het plan, ieder vanuit eigen vakgebied. Vergeet vooral niet de successen te vieren en af en toe achterom te kijken wat bereikt is.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Common Sense als het beste model

Sat, 18 Jan 2020 10:31:29 GMT

Gebruik van goede modellen is niet altijd makkelijk
(click here for English version)

Trends en hypes zie je niet alleen in de mode, binnen de Software Development sector zie je het ook . Wat is hip, wat niet? Waar scoor je mee als bedrijf? Er zijn veel modellen en even zoveel afgeleide Software Development en Implementatie modellen soms gecreëerd door een organisatie om het verschil te maken en op te vallen.

Hoe kies je nu het ‘ beste ’ model? Wat werkt ... en wat niet? Da’s niet zo makkelijk te beantwoorden. Mijn advies is om goed te kijken wat bij jouw organisatie past. Je hoort vaak de term ' Agile '. En alles waar Agile in voor komt is hip. Agile is geen model maar een ‘levenswijze’ . Je kan bijvoorbeeld het vergelijk maken met het zijn van vegetariër. Dat kun je niet leren, da’s een overtuiging die je krijgt door inzichten. Op een dag besluit je om geen vlees meer te eten. De wijze waarop je vervolgens het inzicht (‘vegetariër zijn’) in de praktijk brengt kun je als een model beschouwen. Een model voor en van jou. Iets wat voor jou werkt. Je moet het immers wel vol kunnen houden.

Terug naar ‘ Agile ’. Belangrijk is als organisatie om als geheel het inzicht op te doen om anders te kunnen en te willen werken. Dus niet alleen de hippe Software Development Teams maar de organisatie als geheel. Kijk daarbij goed naar de nadelen. Net als de vegetariër op een BBQ, beetje jammer als je van BBQ-en houd. Afijn je snapt het vergelijk, soms moet je keuzes maken. Agile is een cultuur ding . De modellen die er bij horen, onder andere SCRUM, Kanban, RUP, zijn een uitwerking of implementatie ervan.

Boven alles geldt gebruik je gezonde verstand, Common Sense. Draaf niet door, wees niet bang om een model aan te passen zolang de uitgangspunten van de overtuiging en het model maar overeind blijven. Laat je adviseren door specialisten die het model en je organisatie kennen. Zij kunnen aangeven wat wel en niet tot succes zal leiden. Zelf zie ik dat 90% van het succes zit in de goede fit van een organisatie cultuur op de gekozen overtuiging en modellen.

Luister naar de mensen op de werkvloer, betrek ze erbij. Maak keuzes, bedenk alternatieven. Ontdek ook vooral wat niet werkt. Blijf realistisch. En boven alles: " Gebruik samen het gezonde verstand onafhankelijk van welk model dan ook !"

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Plan en Strategie

Mon, 30 Dec 2019 09:45:39 GMT

Het jaarplan met alle goede voornemens voor een heel nieuw jaar ! (click here for English version)

Bij elke jaarwisseling hebben we weer goede voornemens. In het nieuwe jaar moet het nog … beter … succesvoller … groter … meer. Ook binnen organisaties zien we dit. Reflectie naar afgelopen jaar en plannen voor het nieuwe jaar.

Zelf heb ik moeite met de term ‘ jaarplan ‘ ook met de concrete punten in zo’n plan. Het jaarplan zou eigenlijk omgedoopt moeten worden naar een visie of strategie. Dan klinkt de term ‘ jaar ’ wel erg kort. Ik pleit ervoor om als organisatie te werken aan een algemene visie en strategie met voldoende abstractie niveau. Regel voldoende draagvlak binnen je organisatie (en niet alleen van managers). Betrek het personeel erbij. Daag het personeel uit om vanuit de visie en strategie een plan te maken. Liefst een ‘meer-jaren-plan’. Het eerste jaar wat concreter dan de rest.

Stel kleine doelen, maximaal twee per afdeling, en hou het vooral realistisch! Probeer thema’s vast aan de doelen te koppelen, liefst voor de hele organisatie. Dat schept focus en saamhorigheid. De plannen moeten, als de situatie er om vraagt, aangepast en bijgestuurd kunnen worden. Bijsturen is oké, ook gedurende het jaar. Stem daar de beloningen op af. Niets is zo erg als dat er iets afgemaakt moet worden omdat daar een beloning aan vast zit, terwijl het oppakken van andere zaken veel beter is voor de organisatie.

Door een goed voornemen of plan niet individueel te maken maar samen wordt de kans op succes groter. Immers; “ ... Samen bereik je meer dan alleen ... ”

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Disruptive Technology

Wed, 25 Dec 2019 18:01:48 GMT

De Technologische Game Changers (click here for English version)

Sinds de mens bestaat doen we uitvindingen welke grote veranderingen teweeg brengen. We vonden bijvoorbeeld het vuur, stoommachine en elektriciteit uit. Al deze uitvindingen brachten een enorme verandering met zich mee. In het digitale tijdperk waarin we nu leven kennen we ook van dit soort uitvindingen. Neem nu de mobiele telefoon, begon eerst als device waarmee je alleen kon bellen. Echter is de mobiele telefoon uitgegroeid tot een communicatie device wat meer kan en doet dan alleen bellen. Telefoneren is getransformeerd naar ‘ Unified Communications ’. En de telefoon is daar een prima platform voor. Wat maakt zo’n mobile device nu zo geschikt? Volgens mij gaat het om de bundeling van activiteiten, de ‘ Ease of Use ’ en de plaats (het mobiele).

Als organisatie moet je de trends goed in de gaten houden. Niet alleen ' Hot or Not ' maar ook je continue de vraag stellen: Verrijkt het onze propositie. Zet daarbij de klant centraal, voegt het voor de klant iets toe. Zou je het zelf willen gebruiken op die manier (en voor langere tijd)? Als je iets ontwikkelt voor een mobile device, lees een ‘App’, Stel je dan deze vragen. Beter nog, laat deze vragen stellen door een kritisch publiek en wees eerlijk. Anders kan het zomaar zijn dat echt niemand zit te wachten op zo’n App. Een foutloze werking is minder belangrijk (veilig wel, zeker bij gevoelige gegevens). Maak gebruik van het magische woord ‘ Beta ’. Dit woord betovert de klant en maakt hem onderdeel van de ontwikkeling. Ook vraagt het, op voorhand, vergeving voor foutjes. Als je als organisatie een leuke feedback strategie aan koppelt kan het ook nog eens goede reclame opleveren door met gebruikers in gesprek te gaan. Nodig mensen uit voor een forum, panel of testgroep. Geef je meest kritische klanten een stem, zij zijn het waardevolste voor je organisatie.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

'Pull' en 'Push' Architectuur

Fri, 13 Dec 2019 19:54:13 GMT

Informatie en data ' trekken' en ' duwen' (click here for English version)

In dit blog wil ik het hebben over ‘Pull’ en ‘Push’ Architectuur. Grappig is dat het ene niet zonder het andere kan om tot een evenwichtige balans te komen. Net als de tegel-wijsheid vermeldt “ Op de deur van succes staat zowel duwen als trekken ”.

Om dieper in te gaan op het onderwerp wil ik de twee concepten even van een dagelijks voorbeeld voorzien. De ‘Pull’ of trekken kennen we allemaal van uit het bezoeken van een (traditionele) website. Je trekt informatie (webpagina of data) van een (web-) server. Het initiatief ligt bij de aanvrager, jou. Bij een ‘Push’ kun je denken aan de notificaties welke je ontvangt op een device, bijvoorbeeld telefoon. Het initiatief ligt dan bij de verzender, bijvoorbeeld een nieuwssite (NOS, RTL etc.). Een belangrijke is de NL-Alert. Dit bericht waarschuwt je en wordt verzonden vanuit de overheid (hulpdiensten bijvoorbeeld). Beetje ingewikkelder wordt het als het een combinatie is van de twee (Pull en Push). Ik heb niet voor niets in het eerste voorbeeld het woord ‘traditioneel’ gebruikt. Je ziet steeds vaker dat er informatie initieel ge-‘pulled’ wordt vanaf een locatie en zodra de verbinding er is aanvullende informatie ge-‘pushed’ wordt.

In een goede moderne architectuur zie je in feite hetzelfde gebeuren aan de top worden gegevens (data) ge-‘pulled’. De onderliggende laag gebruikt (micro-) services en het push principe voor bewerkbare processen en de data op strategische locaties te zetten. Je ziet dit vaak samen met een soort van messagebus waar microservices op geabonneerd zijn. Je kunt deze lijn doortrekken naar software architectuur (binnen de microservices) ‘Event-Driven-Development’ (EDD).

Okay, waarom hebben we het nodig? Simpel. We beschikken over steeds meer en complexere data en willen daar snel informatie uit extraheren liefst op maat naar persoonlijke wensen, op verschillende platformen (website, mobile, koppelingen, etc.). Het is daarom belangrijk om gegevensverzamelingen te groeperen en vanuit die groepen pull requests te faciliteren. Tussen de gegevensgroepen kan de data doormiddel van het ‘push’-principe geüpdate worden door bijvoorbeeld (micro-) services. Die gegevensgroepen kunnen dan redundant (schaalbaar) worden uitgevoerd al naar gelang de behoefte naar beschikbaarheid of snelheid. Zo voorkom je dat de core-architectuur vastloopt. Koppelvlakken met big data structuren (zie ook voorgaande blog ‘Big Data’, https://www.casperotto.nl/big_data_strategie ) kunnen hiermee worden gelegd en je kan op een meer Agile manier inzichten verkrijgen (zie ook voorgaande blog ‘Business Intelligence’, https://www.casperotto.nl/business_intelligence ). Uiteindelijk is het doel om een schaalbaar en flexibel concept neer te zetten waarop een organisatie haar business strategieën kan vorm geven. Voor zowel nu als in de toekomst.

Zo’n Pull en Push architectuur is nooit echt af, soms moet je verzamelingen opnieuw definiëren (refractor) om de slagkracht te behouden of te versterken. Een goede architectuur is altijd in beweging; ‘... W erk aan de winkel ... ’.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Bronnen:

A Temporal Analysis of Posting Behavior in Social Media Streams

https://pdfs.semanticscholar.org/b5a3/4d0d75cbc3a8b8cc0e46c880345306f939a0.pdf?_ga=2.261797828.851108803.1576604236-815865708.1576604236

Efficient Monitoring Algorithm for Fast News Alert

http://oak.cs.ucla.edu/~cho/papers/sia-blog.pdf

DCCast: Efﬁcient Point to Multipoint Transfers Across Datacenters

https://www.researchgate.net/publication/316921061_DCCast_Efficient_Point_to_Multipoint_Transfers_Across_Datacenters

Internet Of Things

Sun, 08 Dec 2019 16:59:35 GMT

IOT .. het Internet Der Dingen (click here for English version)

Wat websites in de jaren 90 waren is het ‘ Internet Of Things ’ (IOT) vandaag de dag; “ … Iedereen wil het echter er zijn maar weinigen met een plan …”. En dat is jammer want IOT kent ongekende mogelijkheden als onderdeel van een propositie of waardeketen.

Grote organisaties zouden aan de randen van hun proposities IOT devices kunnen inzetten om nog dichter bij de consument te staan. Een nog betere beleving te creëren van hun reeds bestaande dienst of product. Zeker in combinatie met een mobiele strategie (Mobiele Apps) kan het mooi zijn om zo’n device te ontwikkelen. Hoe pak je zo iets aan, waar begin je?

Ik zou bij de ontwikkeling van zo’n device eerst ‘nut en noodzaak’ testen. Beetje ‘plakken, knippen, solderen en programmeren’ om tot een soort van prototype te komen. In deze fase is het ontzettend leuk om het als een ontdekkingsfase in te steken en met een aantal mensen (start groep) uit de organisatie. Je zou dit op vrijdagen kunnen doen, gewoon afblokken en starten; “ … Start de innovatie … ”. Je ziet ook dat in deze fase samenwerking gezocht word met scholen of universiteiten. Als er een prototype klaar (toonbaar) is geef een demo binnen de organisatie. Sta open voor verbetering en stel je zelf continue de vragen; “ … Wat voegt het toe … ” en “ … Zou ik het willen hebben of gebruiken … ”. Maakt niet uit of het gammel is. Goed is wel om het idee even in een vroeg stadium vast te leggen: ‘aanvraag Octrooi’. Kost maar een paar euro’s en je krijgt soms ook nog subsidie voor het ontwikkelen. Gewoon even doen.

Na een paar demo’s is het tijd voor de volgende stap; doorgaan of stoppen. Bij doorgaan zoek je een partij die je idee productwaardig kan maken. Laat een echt prototype van het device ontwikkelen. Natuurlijk samen met de start groep. Dan is het zo ver en test het, gebruik het en bepaal of je hierin wil investeren. Bedenk wel dat je nu aan meer aspecten moet denken, bijvoorbeeld; security, veiligheid, betrouwbaarheid en prijs. Eigenlijk alles waar je in de voorafgaande fase niet aan dacht (bewust niet).

Ongeveer 1 op de 100 ideeën halen de eindstreep en daarvan zullen 1 op de 100 het 1e jaar overleven. Los van dit feit geven dit soort trajecten een enorme innovatie-impuls aan je organisatie. IOT is echt zo’n technologie welke zich daar prima voor leent. Kortom blaas wat innovatie in je organisatie en verken wat IOT kan betekenen. Doe het niet alleen maar met een groep; “ … Samen ontdekken is leuker dan alleen … ”.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Level Of Service

Sat, 07 Dec 2019 09:32:47 GMT

Service Level in Control (click here for English version)

In dit Blog wil ik mijn visie geven op de service van een applicatie of keten tijdens het gebruik (applicatie levens cyclus). Waar moet je op letten en wat heb je nodig. Ik merk dat in de praktijk het accent vaak op het verkeerde ligt. Namelijk op het oplossen en niet op het voorkomen of beperken van een verstoring.

Aan de hand van een aantal termen zal ik mijn visie proberen uit te leggen; -- MTBF (Mean-Time-Between-Failures) MTTF (Mean-Time-To-Fail), MTTD (Mean-Time-To-Detect) en MTTR (Mean-Time-To-Repair) --. Termen die allemaal de status van een applicatie of keten aanduiden.

De fase tussen de verstoringen (MTTF) is de meest gewenste applicatie status. Alles werkt zoals het moet, geen wolkje aan de hemel. Voor mij is dat de ‘OK’-status. Dan komt er een moment, en geloof me dat geldt echt voor iedere applicatie of keten, dat er een ongewenste situatie -- incident-- optreedt, de niet-OK (NOK) status. Dan komen de andere processen aan bod; het detecteren (MTTD) en oplossen (MTTR). Ik ben van mening dat de diagnose onderdeel is van het vinden van een oplossing, vandaar voor mij geen aparte fase.

Wat ik nu vaak zie is dat het accent vaak ligt op het oplossen van verstoringen, Mean-Time-To-Repair (MTTR). We verdelen dat in prioriteiten. Het verhelpen van een grote verstoring de zogenaamde ‘ P rio-1 ’ moet zo snel mogelijk. Je ziet dan ook dat in contracten hier veel aandacht naar toe gaat. Afspraken worden gemaakt hoe snel iets opgelost moet zijn, vaak met boetes om de afspraak kracht bij te zetten. Tuurlijk is het belangrijk om het snel oplossen van verstoringen in te regelen. Maar nog belangrijker is het voorkomen van verstoringen (MTBF). Als je het accent legt op het voorkomen van verstoringen ga je nadenken over redundantie van systemen of alternatieve vormen van beschikbaarheid van een applicatie of keten (workarround). Door hierover na te denken en passende maatregelen te implementeren zullen de grote verstoringen afnemen.

Van veel ‘ Prio-1 ’ verstoringen, ook al zijn ze binnen de Service Levels opgelost, wordt niemand blij. Zeker de techneuten niet, die weten immers dat de verstoring voorkomen had kunnen worden door meer na te denken over de Mean-Time-To-Fail (MTTF) fase. Ik weet zeker dat als een organisatie de focus legt op deze fase, techneuten er over mee laat denken en beslissen, dat bij een grote verstoring iedereen klaar staat om dit te verhelpen. Met of zonder contract. Een spreekwoord zegt immers; “ ... Voorkomen is beter dan genezen ... ”.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Business Intelligence

Thu, 05 Dec 2019 20:15:17 GMT

Business Intelligence, een visie. (click here for English version)

Business Intelligence, BI afgekort, iets mysterieus bekruipt me als ik die die term hoor. Zeker een aantal jaren geleden een hot item. Weg met dat onderbuik- en ‘fingerspitzen’-gevoel waar managers op varen. Keiharde data, dat is het. ‘Meten is weten, gissen ….’ Je snapt het punt. Voor mijn gevoel zijn we wel een beetje op het punt beland van ‘ ... Computer-says-no ... ’ of in deze context ‘... Report-says-no ... ’. Managers durf je eigen beslissingen te nemen. Okay vroeger was het hip-en-happening om een Datawarehouse te hebben waar alle BI activiteiten plaatsvinden. Maar nu? Dat Datawarehouse barst nu wel een beetje uit z’n voegen met al die verzamelde data. Hoe moet dat nu? Hoe krijgen onze managers dat ‘fingerspitzengefühl’ weer terug?

Ik zeg drastisch aanpakken! Natuurlijk een paar KPI's (Key Performance Indicators) wil je in de gaten houden, maar de rest? Ik zou dat, anno 2020, toch wat ‘Lean-en-Mean’-er inrichten . Laat managers verdedigen waarom ze een bepaald rapport absoluut moeten hebben, ze niet zonder kunnen. Vervolgens het traditionele Datawarehouse in afgeslankte vorm koppelen aan een Big Data Strategie en met z’n allen gaan varen (zie vorige Blog), inzichten verkrijgen en weer zin hebben in het ondernemerschap. Als er dan zo’n inzicht is waarvan je zegt; “Ja …… dat zouden we vaker in de gaten moeten houden” voeg die dan toe aan je KPI’s. Leuke is ook dat je het goed kan verdedigen. Hou het dynamisch, laat er ook zaken van af vallen. Durf keuzes te maken.

Op zo’n manier wordt BI meer een ontdekkingstocht dan de huidige rapport-genereer-tool. Ik zeg rugzak om, op je gevoel af, lekker de wijde wereld ontdekken .

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Big Data Strategie

Sun, 01 Dec 2019 20:15:13 GMT

Een watersportvakantie in de Nederlandse provincie Friesland. (click here for English version)

Big Data , wat is dat nu eigenlijk? Letterlijk betekend het; " … Een grote hoeveelheid aan gegevens … ". De term 'Big Data' is echter uitgegroeid tot containerbegrip welke gebruikt wordt voor data analyse van verschillende, vaak ongestructureerde, gegevensverzamelingen. Uit deze analyse komen inzichten en trends welke organisatie helpen processen, producten en propositie te verbeteren.

Om het holistische begrip 'Big Data' en de strategie erachter wat tastbaarder uit te leggen gebruik ik vaak de vergelijking met een watersportvakantie in de Nederlandse provincie Friesland. Onze mooie provincie Friesland beschikt over een aantal meren. Deze meren zijn aan elkaar verbonden door middel van rivieren en kanalen. Hoogteverschillen worden opgevangen met sluizen. Als je nu een leuke vakantie wil hebben stippel je de route uit over deze verschillende meren. Je vaart van het ene naar het andere meer. Soms door sluizen, soms door tol te betalen. Gedurende je vakantie maak je foto's en doe je indrukken op.

Als je bovenstaande voorbeeld nu eens vergelijkt met een 'Big Data strategie' komt dat volgens mij wel goed overeen. De meren kun je vergelijken met gegevensverzamelingen. Rivieren en kanalen met de verbindingen tussen de gegevensverzamelingen. Sluizen zou je kunnen zien als een vorm van security. De tolbetaling als een afrekenmodel voor gegevensgebruik. De foto's die je gedurende je reis maakt kun je zien als analyse. Alles resulteert in indrukken, vergelijkbaar met inzichten.

Wat ik het mooie vind aan de vergelijking dat voor beide geldt; "... Hoe onverwachter dingen zijn hoe leuker en spannender de ervaring is ... ". Een Big Data strategie is dan ook niet het beschrijven van de foto’s en indrukken maar het uitstippelen van de trip. En natuurlijk ruimte laten voor onverwachte dingen. Ik zeg: “ Bon voyage ! ”.

Casper.

https://www.casperotto.nl/

https://www.casperotto.nl/blog

Product Development (part 4); "further development" (English Version)

Mon, 26 Sep 2011 10:02:21 GMT

The Show must go on ....

Finally the time has come. After a long time of testing, changing and fine-tuning, we can start with the unveiling. After months of working on the product, the world will get to know it. How do you handle that. In this fourth part of the series I want to go into more detail.

Product Development, Part 4, “ The Show Must Go On”.

You face a big decision; “Reveal the product and show it to the world. After all, you can only introduce your product once, right? I think it can be done better in phases. Small steps. Just think; You also learn to walk first and only then can you train for a marathon. Introduce your product within a limited group first. Call it "Beta Version" and collect feedback. Make sure you have good contact with the users. You will be amazed at how well the words 'Beta Version' works. Users feel involved in the development, especially if they are listened to. The feeling of being part of an exclusive group is still appealing. This group has the opportunity to become an ambassador for your product in the early days. Don't be afraid to make mistakes, but above all to admit them. If something doesn't work, acknowledge it, change it and move on.

During the pilot or 'Beta' phase you can already make plans to roll out the product to a larger audience. Important factors to consider are:

Planning : When is it useful to release? Are there other major events that overshadow my product launch?
Availability : When I launch the product, can the new users start using it right away?
Accessibility : Is the product directly accessible or do other aspects have to be arranged by the user first? A good example was the introduction of a government website, but to register on it you first need DigiD.
Scalability : Is there enough capacity? If it's a success (and you hope it does), don't spoil the fun because the system can't handle the demand.

Then you want to add new options, the further development of the product. There was no time or space for that in the MVP. It is important to create a program. Not everything can be done at once. Make it clear, transparent and alternate visible things with less visible improvements. It would be nice if there were themes in the program. This helps to set and maintain the focus of the teams. The user group will then also understand better that other features outside the theme will have to wait a while.

One of the major pitfalls is that organizations only start thinking about further development after the MVP. This creates a gap between the first (MVP) release and the subsequent second release. There is a chance that users will drop out because the MVP product offers too little added value. In practice, it is very difficult to get these users who have dropped out 'on board' again. So plan well and work ahead where possible. Make sure new options are added quickly. Rather in small steps than waiting a long time for a major release, after all “ The Show must go on ”.

Above all, don't forget to put the spotlight on the people who have worked hard for months on this. Those are the real stars in the show, give them credit and appreciate them. Make it a party. You're going to need them during the program.

Casper.

Blog van Casper Otto

Productontwikkeling (deel 4); "Doorontwikkeling"

The Show must go on .... (click here for English version)

Productontwikkeling (deel 3); "Productiewaardig maken"

Een innovatieve weg naar een nieuw product

(click here for English version)

Productontwikkeling (deel 2); "Creativiteit"

Een innovatieve weg naar een nieuw product

(click here for English version)

Productontwikkeling (deel 1); "De harde aspecten"

Een innovatieve weg naar een nieuw product

(click here for English version)

Security by design

Meer dan alleen een slot op de deur. (click here for English version)

Schaalbare Architectuur

Een ' must have ' voor iedere organisatie. (click here for English version)

Big Data

Het digitale goud, de gegevens bekeken. (click here for English version)

User eXperience

Een klantreis door een woud van functionaliteit, techniek en ideeën. (click here for English version)

Omnichannel

Een fantastische klantervaring … of … jungletocht door de techniek? (click here for English version)

Headless Architecture

One-backend-fits-all …. (click here for English version)

Mobiele Apps

Het digitale goud .... (click here for English version)

#Stay@home

Verveling en fouten een ideale combinatie? (click here for English version)

Cloud Infrastructuur

Met je business in de wolken. Infrastructuur als een ‘ Blackbox ’ of niet ? (click here for English version)

The Art Of Software Architecture

Koken op niveau (click here for English version)

Digitale Transformatie

Verandering in gebruik van technologie (click here for English version)

Common Sense als het beste model

Gebruik van goede modellen is niet altijd makkelijk (click here for English version)

Plan en Strategie

Het jaarplan met alle goede voornemens voor een heel nieuw jaar ! (click here for English version)

Disruptive Technology

De Technologische Game Changers (click here for English version)

'Pull' en 'Push' Architectuur

Informatie en data ' trekken' en ' duwen' (click here for English version)

Internet Of Things

IOT .. het Internet Der Dingen (click here for English version)

Level Of Service

Service Level in Control (click here for English version)

Business Intelligence

Business Intelligence, een visie. (click here for English version)

Big Data Strategie

Een watersportvakantie in de Nederlandse provincie Friesland. (click here for English version)

Product Development (part 4); "further development" (English Version)

The Show must go on ....

Product Development (part 3); "Production worthy" (English Version)

An innovative way to a new product

Product Development (part 2); "Creativity" (English Version)

An innovative way to a new product

Product Development (part 1); "The hard aspects" (English Version)

An innovative way to a new product ﻿

Security by design (English Version)

More than just a lock on the door.

Scalable Architecture (English Version)

A ' must have ' for every organization.

Big Data (English Version)

The digital gold, the data viewed.

User eXperience (English Version)

A customer journey through a forest of functionality, technology and ideas.

Omnichannel (English Version)

A fantastic customer experience… or… jungle tour through technology?

Headless Architecture (English Version)

One backend-fits-all ….

Mobile Apps (English Version)

The digital gold ....

#Stay@home (English Version)

Boredom and mistakes an ideal combination?

Cloud Infrastructure (English Version)

With your business in the clouds. Infrastructure as a ' Blackbox ' or not?

The Art Of Software Architecture (Englisch Version)

Cooking on top level

Digital Transformation (English Version)

Change in use of technology

Met je business in de wolken.
Infrastructuur als een ‘ Blackbox ’ of niet ? (click here for English version)

Gebruik van goede modellen is niet altijd makkelijk
(click here for English version)

An innovative way to a new product

With your business in the clouds.
Infrastructure as a ' Blackbox ' or not?