Je Monoliet naar Services Ombouwen

In het SDN-magazine zie je veel auteurs vertellen over microservices, maar ook op onze SDN-events of andere conferenties zijn er veel sessies over. Ze vertellen dan altijd dat het belangrijk is om naar microservices over te stappen, want daarmee wordt het leven een stuk eenvoudiger. De voorbeelden die ze geven zijn dat altijd de standaardvoorbeelden van een product-order systeem of ze komen met voorbeelden vanuit een greenfield situatie. De presentaties gaan bijna altijd uit van het niet aanwezig zijn van legacy code of legacy systemen. Maar onze werkelijkheid is vaak veel weerbarstiger.

Veel bedrijven hebben een monoliet en een monoliet is niet iets waar je voor hoeft te schamen. Er zijn maar weinig omgevingen waar niet een vorm van monolithische code of omgeving is ontstaan. Zelfs bij startups begint het altijd met een redelijk puristische manier van ontwikkelen, maar na enkele weken/maanden wint de tijdsdruk van de schoonheid en raakt de software langzaamaan vervuild. Op zichzelf hoeft dat ook helemaal niet erg te zijn. Mits je tijdig refactor-slagen uitvoert en bij iedere volgende aanpassing/verbetering/bugfix je code weer beter achterlaat (incheckt) dan dat je hem gevonden hebt: de Boyscout rule, laat het kampeerterrein schoon achter voor de volgende gebruiker en liefs nog iets schoner. Ook hier voer je dus verbeteringen uit stapje voor stapje, hapje voor hapje. Ik ben een groot voorstander van “Make-it-work-then-make-it-better-then-make-it-pretty”.

“Make it work then make it better then make it pretty”

Want hoe migreer je vanuit een bestaande omgeving naar een service georiënteerde omgeving of microservices. Het antwoord is heel simpel zoals je ook een olifant eet, hapje voor hapje. “Haha wat leuk, neem je ons niet serieus of zo?”. Jazeker wel en ik zal jullie uitleggen hoe ik dat bedoel.

Monoliet naar Services

Door de conferenties en artikelen (waar Microservice behoorlijk gehypet worden) hebben veel bedrijven de wens om over te stappen naar een service georienteerde architectuur en bij voorkeur naar een Microservices architectuur. Maar natuurlijk moet de winkel wel open blijven en dat betekent dat support en bigfixes wel gewoon moeten door blijven gaan. Tenslotte betalen de huidige klanten de rekeningen en organisaties hebben niet de mogelijkheid om voor een paar maanden of soms jaren onder een steen te kruipen om orde op zaken te stellen. Natuurlijk kan dat niet, tenslotte zijn klanten de reden waarom het bedrijf bestaat en zij betalen niet voor een product dat niet verbetert, wordt onderhouden en gewoon stilstaat. Ander risico is dat er een andere partij opstaat en jouw plekje inneemt.

Ik denk ook niet dat je dicht hoeft om tijdens het rijden een wiel te verwisselen. Alleen moet je dan als bedrijf wel een behoorlijke tijd uittrekken om te migreren. Je zult dat wel dubbel onderhoud en dubbele code moeten accepteren. Wat vaak in jaren is opgebouwd, is niet in een paar weken terug te draaien. En doordat je niet alles vanaf de grond opnieuw bouwt, zul je meerdere refactor slagen moeten maken en Projects/files/classes/code meerdere malen zult aanpassen. Het is pas af als jullie puntje op de horizon gehaald is.

Ja, dat is niet exclusief voor Service Oriëntatie! Klopt, want het begint bij het ontrafelen van de kluwen van code en zorgen dat alle onbedoelde maar ingeslopen afhankelijkheden weer ongedaan gemaakt worden. Pas als je de basis op orde hebt, dan kun je de stap voorwaarts maken en nieuwe dingen toevoegen. Ook microservices (hoe hip ook) zijn niet perse nodig. Wel wil je dat verantwoordelijkheden goed verdeeld zijn over de verschillende servers, computer systemen of code.

Eerst moeten we voor ons zelf bepalen, wat de reden is om te migreren naar Service Oriëntatie. Wat zijn de huidige uitdagingen met je applicatie, platform of service? Is het dat het testen niet meer te doen is? Of dat het aanpassen van code op de ene plek betekent dat er op een andere plek code / functionaliteit omvalt? Er te veel afhankelijkheden tussen verschillende onderdelen bestaan? Of dat het deployen een probleem is geworden en gewoon te lang duurt? Of wil de organisatie van het ASP (Application Serivice Provider) model af en omvormen naar overstappen naar een SAAS (Software As A Service) model? Is de applicatie, service of platform eigenlijk niet geschikt voor multi users omgeving? Of is je oplossing niet of nauwlijks in staat op te schalen bij meer gebruik? Is in het algemeen reageren op gewijzigde wensen van je klanten gewoon lastig, omdat er te vlug andere functionaliteit omvalt.

Belangrijk is, dat de reden niet moet zijn omdat iedereen het doet of dat services of erger microservices zo belangrijk lijken in de business. Op zichtzelf hoeft er niks mis te zijn aan een monoliet. Er moeten andere redenen zijn om aan te passen. Ik heb liever een goede monoliet dan een slecht uitgevoerde Service Oriëntatie. Technology is een middel en moet nooit een doel op zichzelf zijn.

Technology is een middel en niet een doel

De formele beschrijving van een Service Orientation Architecture service: “A SOA service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.”. Microservices zijn opzichzelf niet heel anders, maar waar we de definitie van een op zichzelf staande eenheid van functionaliteit wel iets strakker wordt neergezet. In een minder goed uitgevoerde Service Oriëntatie omgevingen zijn de services vaak te klein, waardoor de services elkaar aanroepen en eigenlijk niet meer los van elkaar gebruikt worden. Dat resulteert meestal in een Chatty systeem, waarbij services elkaar herhaaldelijk aanroepen en allesbehalve onafhankelijk van elkaar zijn. Iedere aanroep van een service levert weer vertraging op en als het een losse service is. Soms zijn de services dan ook nog eens zo gebouwd, dat ze niet verwachten dat de aanroepende service stuk of niet aanwezig is. En dat gebeurt juist als het zo losgekoppeld is. Waarmee de “updated independently” uit de definitie eigenlijk niet meer kan, andere services rekenen op elkaar en feitelijk heb je dan een monoliet in stukjes.

Belangrijkste in de definitie is volgens mij ook op zichzelf staande functionaliteit. Er staat nergens hoe groot de “op zichzelf staande functionaliteit” moet zijn. Wat er wel staat, alles wat de service nodig heeft om volledig autonoom te kunnen werken onafhankelijk van de rest van de systemen. Even heel gechargeerd, een monoliet is in deze beschrijving dus ook een goede service. Een monoliet herbergt misschien te veel verschillende functionaliteiten. Zoals een ordersysteem, een productsysteem, een klantsysteem etc. Ik schrijf expliciet systeem om aan te geven dat het losse onderdelen moeten zijn. Maar het ordersysteem heeft informatie nodig van de producten en de klanten! Ja, dat klopt, maar het ordersysteem zal niet het adres van de klant updaten in de database. Ieder systeem heeft zijn eigen verantwoordelijkheden. Het ordersysteem gebruikt de data van het klantsysteem. Verandert het adres in het ordersysteem? Dan maakt het ordersysteem een werkbon voor het klantsysteem om dit aan te passen. Voor hier gaat het te ver om hier dieper op in te gaan, lees het artikel van Dennis van der Stelt uit ons vorige magazine eens over het Starbucks model. Vuistregel is, maak je functionaliteit niet te klein en let goed op welke verantwoordelijkheden de functionaliteit heeft. Services zijn ook een middel en niet een doel. Keep it simple, maar om met Einstein te spreken; maak het niet simpeler dan dat.

Terug naar ons initiële probleem. We zien de monoliet als een samengeklonterde functionaliteit, maar feitelijk bestaat deze toch ook uit losse stukken en op zichzelf staande functionaliteit. Echter de functionaliteit is alleen te veel op de achtergrond geraakt door gebruik van technology. Vaak zijn databases te ver uitgenormaliseerd (8st normaalvorm) of is object Oriëntatie te strict doorgevoerd. Heel vaak is door technologische overload de functionaliteit teveel door elkaar heen gaan lopen. De technologie geeft de mogelijkheid en de druk om snel nieuwe functionaliteit er uit te sturen neemt dat ook toe.

Maar als je het goed doet, dan kun je het best weer naar zijn oorsprong ontrafelen. Je zult dan strict bezig moeten zijn met de functionaliteit en de technologie weer een middel laten zijn.

Maak een vertical slice van je functionaliteit

Laagjes zoals in een taart

De volgende stappen kunnen dan gedaan worden. Bepaal een stuk functionalitieit dat op zichzelf staat of had moeten staan. Beschrijf het dan van de user interface tot aan de kern (de dataopslag of de servicebus of wat ook het eindpunt is). En zodra je een afhankelijkheid spot, bedenk dan steeds of deze afhankelijkheid noodzakelijk is en of er andere oplossingen zijn. Als er geen eindpunt is, dan is er misschien een uitdaging met de functionaliteit zelf. Poplulair gezegd maak een verticale doorsnede (vertical slice) van je applicatie. Zie het als de taart met die vele gekleurde laagjes, beschrijf alles van dat ene stuk uitgesneden staart en alleen wat bij dat stuk hoort. Bouw dan dat stuk opnieuw en hergebruik zo min mogelijk eerdere code. Anders word je te vlug weer in de rabbithole getrokken. Bereid je voor op het herhaaldelijk refactoren van de code. Er lijkt geen einde aan te komen, maar uiteindelijk zal het beter worden.

Vertical Slices

Deze strategie maakt het ook mogelijk om de oude flow van de functionaliteit nog beschikbaar te houden en de nieuwe er echt los van te laten. Uiteindelijk is dat ook je doel in Service Oriëntatie. Als je dan volledig tevreden bent met de nieuwe implementatie, dan zet je de wissel om.

Soms kan de aanpassing ook aan de buitenkant gemaakt worden, waardoor bepaalde werkvoorraad niet eens je platform/applicatie of omgeving bereikt. Controle aan de deur. Beschrijf deze functionaliteit zo onafhankelijk mogelijk en als je of het team de behoefte voelt om andere functionaliteit toe te voegen of samen te voegen, stel dan de waarom vraag zo vaak mogelijk. Als je dan nog steeds niet zonder kunt, dan moet je het samenvoegen niet laten.

Maar iedere andere wijziging verstoort het proces. Dus probeer niet gelijk ook volledig nieuwe functionaliteit toe te voegen of bestaande functionaliteit volledig te veranderen. Niet omdat het niet zou kunnen, maar als we technologie of functionaliteit wijzigingen gaan doorvoeren dan worden we afgeleid en wij mensen kunnen helaas niet teveel multitasken. Het onafhankelijk en losgeweken van het stukje functionaliteit is al moeilijk genoeg. Daarom moet je de eenheid ook zo klein mogelijk maken. Dat voorkomt dat de rest van de applicatie/omgeving op slot zit voor aanpassingen of wijzigingen.

Het is te doen, maar je zult wel heel gericht door moeten gaan en je niet laten afleiden. En als je eenmaal begonnen ben, dan kun je eigenlijk niet meer stoppen. Meer dan eens zullen verschillende stukken software door je handen gaan en meer dan eens zal je code aanpassen om deze later weer ongedaan te maken. Dat geeft niet, je doel is op zichzelf staande stukken software/services. Niets is onmogelijk. Maar laat technologie niet de reden zijn! En blijf refactoren.

Cloud Strategie

Er wordt de laatste tijd erg veel gesproken over het opstellen van Cloud Strategieën bij bedrijven. Maar gaat het daadwerkelijk om Cloud strategieën of gaat het om een breder omvattende IT strategie waar Cloud een implementatie vorm van is?

Voor een bredere IT strategie is het volgens mij belangrijk om te bepalen wat de core business is en welke processen ondersteunend zijn. De voorwaarden en eisen van deze processen bepalen welke software ondersteuning kunnen bieden. Mogelijk is out-of-the-box software  (OOB) of software as a service (SAAS) een oplossing. Als dan blijkt dat er geen software op de markt is om de processen te ondersteunen, dan is er een optie om de software zelf te ontwikkelen. Dit inzicht bepaalt dan waar de inspanningen moeten liggen. Voor de OOB software of zelfgemaakte software heb je dan een Cloud strategie nodig.

Maar is het dan een Cloud strategie of gewoon een implementatie strategie? Bijvoorbeeld OOB software stelt bepaalde eisen aan de onderliggende infrastructuur. De frequentie waarmee de software pieken en dalen van gebruik zal ondergaan, gecombineerd met ondersteuning van de software voor het opvangen van deze pieken, met deze parameters kunnen dan de kostverschillen tussen eigen hosting of een Cloud omgeving bepaald worden. Hierbij dienen dan wel de non functionele parameters voor o.a. beheer, back-ups en monitoring meegenomen worden. Applicatie beheer moet ook een plekje krijgen in het kostenplaatje.

Als de ondersteunende software zelf ontwikkelt wordt, dan gelden dezelfde afwegingen als bij iedere implementatie. Welke architectuur, welke technieken en welke diensten kunnen we hergebruiken. Een strategie hier is dan buy-before-build, of populairder kunnen we gebruik maken van PAAS (platform-as-a-service diensten).

Welke deployment omgeving is mede afhankelijk van de gebruikte technieken of platform onderdelen. Daarbij komt ook de vraag, ontwikkelen we in eigen beheer of besteden we ontwikkeling uit? In het laatste geval kunnen we ook bepalen of de ontwikkelpartner wellicht de hosting en beheer over kan nemen.

Een Cloud strategie zou onderdeel kunnen zijn van de IT strategie. Cloud is een implementatie methode en behelst het geheel van on premise private Clouds tot public Clouds. In welke Cloud de software optimaal en flexibel landt, is helemaal afhankelijk van de requirements.

Op basis van een matrix met de requirements en de applicatie behoefte, zou je met een beslisboom redelijk kunnen bepalen waar de keuzes uit bestaan. De IT strategie zal dan zijn SAAS versus eigen hosting. Voor software ontwikkeling is de Cloud strategie dan PAAS versus IAAS of buy-before-build.

Eigenlijk is iedereen een Startup!

In het weekend van 13-14 mei was ik bij een Startup weekend van RockStart in Moldova. In twee maanden tijd worden startups begeleid in het geheel rondom hun product/dienst/service. Ze moeten een aantal milestones halen met als doel in een accelerator programma te komen en funding van investors te krijgen.

De twee maanden is verdeeld in verschillende onderdelen. Het weekend dat ik mentor/presentator was, ging over Global Market potential. Wij (Remi, Eduard en ik) deden sessies over Global Market, Things to love as Entrepreneur, Exponential Organisations, Agile and what is a MVP en Mapping Competitors. De startups gingen hiermee met workshops aan het werk. De workshops bestonden onder andere uit het doen van een Pecha Kucha en een Competitor mapping oefening. Op de zaterdag avond was er een persoonlijk Sad Founders story, de ups en downs van een entrepeneur door Remi.

De sessies en oefeningen werden allemaal gretig gevolgd en uitgevoerd. Er ontstonden leuke discussies en tussendoor werden er erg veel goede vragen gesteld. Erg leuk om te zien dat de theorie en oefeningen bij de startups daadwerkelijk veranderingen opleverde, zowel in hun houding als in aanpassingen aan hun initiële idee. Nog belangrijker ze waren allemaal geïnteresseerd en behulpzaam bij elkaars uitdagingen.

De sessie over MVP (Minimal Viable Product of liever Experiment) leverde een mooie interactieve sessies op en leverde veel aha momenten op. Tijdens de sessie over “Things to love as Entrepreneur” vertelde iedere founder wat hij/zij leuk vond en wat niet. Een hele levendige en interactieve discussie over de pains and gains van een startup. En het kwam overeen met de lijst van items die wij hadden opgesteld. Het panel van Remi, Eduard en mijzelf konden verschillende tips en tricks meegegeven om nog effectiever te worden.

De Pecha Kucha werd als erg lastig ervaren, maar wel als erg leerzaam. Een Pecha Kucha is een presentatie die bestaat uit 20 slides van elk 20 seconden. De slides bevatten geen (of nauwelijks) tekst en alleen een visual, beetje ala Steve Jobs altijd deed. 20 slides lijkt dan erg veel, maar de tijdsdruk van 20 seconden levert dan weer hoge druk op. Belangrijk bij een Pecha Kucha is om je te focussen op je verhaal. Daarna plaatjes te zoeken die je verhaal ondersteunen en je geheugensteuntjes geven voor het verhaal. De plaatjes en de slides vullen elkaar aan en leiden het verhaal niet. Veel van de startups vonden dat lastig. Bijna iedereen stelde zijn team voor en het was lastig om 20 seconden iets te vertellen over ieder lid. Het vergt het vermogen om compact te vertellen wat je product, dienst of service doet.

Tijdens de Competitor mapping oefening (gebaseerd op Red Ocean/Blue Ocean) keken veel van de startups voor het eerst echt naar hun concurrenten. Ze hebben wel een idee van competitie, maar nu gingen ze een stuk dieper. Tijdens deze oefening moesten ze een slide maken met de specifieke functionaliteiten van hun idee. Hun slide werd gepresenteerd en beoordeeld door iedereen. Dat leverde voor sommige eye-opening momenten op.

Ik vond het een heel gaaf, interessant en (ook voor mezelf) leerzaam weekend. Gaaf om te zien hoe de startups met de input omgingen en hun eigen initiële ideeën pivotten. Mooi was ook om te zien hoe verliefd en trots de startups waren op hun ideeën. Heerlijk!

Maar waarom vind deze begeleiding wel plaats bij startups en niet bij bestaande bedrijven. En ik bedoel dan niet alleen bedrijven die een product verkopen, maar die intern producten of diensten ontwikkelen. Veel bedrijven zie ik toch nog vaak worstelen met MVP, Agile en Competitors mapping.

Want is niet iedereen in beginsel een Startup?

Recruitement Tips

Op verschillende media lees ik vaak klachten over recruiters en hoe zij omgaan met CV’s. Maar wellicht is een beetje zelfreflectie ook wel op zijn plaats. Vanuit de aanbiedende kant, maar ook vanuit de vragende kant kunnen we het makkelijker maken. Ik pretendeer niet het beter te weten, maar mijn zelfreflectie levert dit op.

In mijn vorige rol was ik in de positie om freelancers in te huren, de vragende kant dus. Op het moment dat je een dergelijke vraag dan uit zet in de markt, krijg je inderdaad verschillende CV’s opgestuurd. Het is lastig om dergelijke CV’s op waarde te schatten. Ze bevatten allemaal generieke informatie over de potentiële opdrachtnemer. Ik weet dat veel recruiters de CV in eerste instantie anonimiseren, maar als je interesse hebt dan sturen ze de juiste versie.

Maar als ik eerlijk ben, was onze uitvraag naar de tijdelijke capaciteit niet heel smart geformuleerd. De opdrachtomschrijving bestond uit een aaneenschakeling van algemeenheden en technische vaardigheden. De complexiteit van de opdracht en de functionele requirements stonden niet uitvoerig beschreven. De opdracht was als een vacature opgesteld. Dan is het niet zo gek, dat je heel algemene CV’s aangeboden krijgt.

Maar ook algemene CV’s kunnen meer waarde bevatten; Een beschrijvend stukje wie je bent en wat je wilt. Dan kun je aanvullen met specifieke ervaringen en kennis. Ik heb mensen afgewezen op basis van hun CV omdat ik oprecht dacht dat ze bij ons erg ongelukkig zouden worden en botweg niet de juiste competenties leken te hebben.

Als ik iemand op gesprek liet komen, dan deed ik wel onderzoek met mijn vrienden Google, Bing en Linkedin om iets meer te weten te komen over de persoon. Soms vind je dan ook blogs of andere uitingen van de persoon op het internet. Kleeft ook wel een gevaar aan, je zult het dus nooit als enige bron kunnen gebruiken. Maar daarvoor is dan ook een gesprek. Het is als opdrachtnemer dan wel van belang om je Linkedin profiel op orde te hebben.

Nu zit ik weer aan de andere kant, de aanbiedende kant. Ik heb mijn CV her en der neergelegd, in de hoop dat de droomopdracht er tussen gaat zitten. In mijn CV hadden korte en lange klussen ogenschijnlijk hetzelfde gewicht, opdrachtgevers zouden daaruit kunnen opmaken dat ik heel veel korte klusjes heb gehad. Wat tot heel veel speculaties en verkeerde conclusies kan leiden.

Via de verschillende vacaturesites heb ik inmiddels een aantal keren gereageerd op advertenties. Met alle respect ook hier zijn niet alle opdrachten smart geformuleerd. De meeste advertenties zijn zelfs opgesteld, alsof ze vast personeel zoeken. Het een sluit het ander uit, lijkt mij. Als ik een loodgieter inhuur, dan vertel ik hem ook heel specifiek waarom ik hem inhuur en wat ik van hem/haar verwacht. Ik reken op een langdurige relatie, maar niet permanent bij mij in huis. Bij freelance advertentie voor een bepaalde tijd (met opties tot verlengen) zouden ook zo opgesteld moeten worden. Welke expertise verwacht je van de tijdelijke arbeidskracht. En wat houdt de tijdelijk opdracht in, sugarcoating van de opdracht is niet nodig. En deze duidelijkheid helpt ook weer voor de wet DBA.

Zo zou je dan ook het intakegesprek moeten voeren. Je wilt als opdrachtgever helemaal niet weten welke ambities de freelancer allemaal heeft of waar hij over een x periode wil staan. Jij hebt een opdracht of een gat in de kennis of capaciteitsgebrek om iets uit te voeren of in te vullen. Je wilt weten of hij die kennis bezit, of hij de klus kan uitvoeren en de vastgestelde tijd zal blijven. Als het probleem is opgelost, dan kan de tijdelijk kracht weer gaan. Als je het op deze manier insteekt, dan weet je beide waar je aan toe bent en waar je of op afgerekend te wordten.

En als je dat gesprek voert, doe dan ook een beetje onderzoek naar de persoon. In deze digitale tijd laten we allemaal meer digitale voetafdrukken achter dan soms wenselijk, maar alleen iemands linkedin profiel bekijken is vaak al genoeg (wie kent hij, wat leest hij etc.). Sommige vragen hoef je dan niet meer te stellen en kun je beide tot essentie van het gesprek komen. Het inhuren van tijdelijke krachten of vast personeel is gewoon werk en kost ook gewoon tijd. Tijd die je terugverdiend als je de juiste persoon hebt in gehuurd. Soms ga je harder door even stil te staan.

Samengevat heb ik voor mezelf de volgende tips. Als aanbieder/opdrachtnemer: zorg dat je CV iets van jezelf bevat (je valt dan toch op als je CV anoniem gemaakt is) en zorg dat je Linkedin profiel in elk geval relevant en up-to-date is. Voor de vragende kant/opdrachtgever de tips: formuleer een heldere, smart opdracht en bevraag de freelancer daarop uit, en doe een beetje backchecking van de kandidaat en maak tijd. Voor de freelance recruiters, jullie zouden kunnen helpen de aanvragers/de aanbieders de opdracht helder en smart te krijgen, jullie hebben er baat bij dat de juiste informatie wordt gedeeld. Vraag en aanbod komen dan beter bij elkaar.

Oja en als je dan op iemand zijn Linkedin pagina kijkt, doe dat dan met open vizier en niet annoniem. Ik vind het leuk om te zien wie er naar mijn profiel kijkt, en zeker als dat de gesprekspartner van het intakegesprek is.

My two cents.

Get Ready for SharePoint 2010

Mijn werkgever VX Company nodigt u uit voor het seminar ‘Get ready for SharePoint 2010’ op donderdag 28 januari 2010 in Baarn.

De lancering van Microsoft SharePoint 2010 staat in Nederland gepland op april 2010. Als officieel Microsoft ‘early adopter’ van SharePoint 2010 biedt VX Company u de mogelijkheid ruimschoots voor de officiële lancering op de hoogte te worden gebracht van alle ins en outs rondom SharePoint 2010.

De opzet van het programma, de live demo’s en de maximale groepsgrootte bieden volop gelegenheid voor interactie.

Er is een programma opgesteld met als doel u handvatten te bieden uw IT-plannen voor 2010 met betrekking tot SharePoint nu al verder invulling te kunnen geven. Het programma ziet er in hoofdlijnen als volgt uit:

  • What’s new in SharePoint 2010 (inclusief Office Web Apps)
  • Migratie en upgrade van MOSS 2007 naar SharePoint 2010
  • Business oplossingen zonder gebruik van code (Business Connectivity Service, InfoPath en Workflow)
  • Taxonomie en Tagging (structureren van gegevens, Social Networking en Search)

Er zijn 40 plaatsen beschikbaar dus meld u snel aan. Het seminar vindt plaats bij VX Company in Baarn en de deelname is gratis. Het programma start om 09.30 uur en eindigt om 15.30 uur. Na aanmelding ontvangt u een bevestiging, inclusief routebeschrijving en een parkeerkaart.

Voor vragen kunt u contact opnemen met Anne Jansen: telefoon 035 539 0940 of e-mail: ajansen@vxcompany.com.

We begroeten u graag op donderdag 28 januari.

bron: http://www.vxcompany.com/?s=14&m=7&p=#