Kleine stapjes

Je kunt ervoor kiezen om vanuit jouw behoefte aan flexibiliteit de totale IT architectuur van de hele organisatie op de schop te nemen. Vaak is deze rigoreuze aanpak niet erg effectief. Je belandt al snel in een situatie waarin alle oude systemen nog minder flexibel en betrouwbaar zijn dan ervoor, en de prognose wanneer het nieuwe landschap bedrijfsklaar is wordt steeds verder naar achteren geschoven. De politieke steun daalt onder het nulpunt en iedereen moet zo ver uit zijn of haar comfort zone komen om met de nieuwe manier van werken vertrouwd te raken, dat ook bij de gebruikers iedereen klaagt. Dus hoe dan wel?
 
Stel je voor: het IT landschap is een huis, de web-site is een staande schemerlamp. Hoe voorkom je dat je schemerlamp vastzit aan je huis? Met een stekker en een stopcontact! Hoe voorkom je dat je web-site vastzit aan je IT landschap? Met een API. Dat staat voor Application Programming Interface. De belangrijke term hier is Interface, de Nederlandse vertaling is koppelvlak. Wij gebruiken de term koppelvlak omdat die term goed omschrijft waar het ons om gaat. Als we met techneuten gaan praten, dan gebruiken we natuurlijk als goede Marketeers de taal van onze doelgroep en noemen we het weer een API (ik zeg meestal éé-pie-aai, maar aapie vindt ook niemand gek).
 
Dus als je wilt dat bezoekers iets kunnen bestellen op je web-site, dan heb je een koppelvlak nodig met de catalogus en met het order-invoersysteem. Een IT architect kan je helpen om te bedenken met welke systemen je koppelvlakken nodig hebt en wat je minimaal van dat koppelvlak nodig hebt. Begin simpel. Het koppelvlak met de catalogus kan een wekelijkse export uit het ERP systeem zijn. Laat je helpen door een architect of analist om oplossingen te bedenken voor addertjes onder het gras (wat doe je als een klant een openstaande order heeft op een product dat uit de catalogus is verwijderd).
 
Laat IT vervolgens deze koppelvlakken bouwen tegelijk met een minimaal stukje web-site (web-app) dat dit koppelvlak gebruikt. Stuur daarbij op de principes van Scrum: bouw kleine afzonderlijk te gebruiken onderdeeltjes. Lever zo snel mogelijk iets op dat werkt. Begin klein en bouw het stap voor stap uit. Iedere stap moet waarde toevoegen. Idealiter worden het koppelvlak en de web-app door hetzelfde team gemaakt. Je kunt wel het koppelvlak met de catalogus en de bijbehorende web-app door één team laten maken en het koppelvlak met het order-invoersysteem en de bijbehorende web-app door een ander team.
 
Het koppelvlak wordt zo dicht mogelijk bij de applicatie(s) geplaatst dat het ontsluit en beschikbaar gesteld aan de buitenwereld (met voldoende beveiligingsmaatregelen natuurlijk). De web-app wordt in de cloud gehangen. Bij elke oplevering kijk je of de web-app nu de nieuwe functies heeft en of de informatie en de acties in de web-app consistent zijn met de gegevens in de rest van het IT landschap. Stel bij deze web-app nog geen eisen aan de vormgeving of de gebruikerservaring, dat is zonde van de tijd en energie die erin gaat zitten.
 
Als de benodigde koppelvlakken ver genoeg ontwikkeld zijn, kun je beginnen met een productie web-app voor een complete winkel. Wederom bij voorkeur door één team. Dit team kan starten door te kijken naar de web-apps die de eerdere teams hebben gemaakt. Deze demonstreren hoe de koppelvlakken moeten worden aangesproken. Het nieuwe team integreert de koppelvlakken en voegt vormgeving en een prettige gebruikerservaring toe (bijvoorbeeld, strakke opmaak met de kleuren en lettertypen van de huisstijl, uitklapbare menu’s, harmonica, tijdlijn, directe validatie van invoervelden, vertaalde labels, informatieve tooltips, etc.).
 
Laat ook een koppelvlak maken waarmee losse web-apps in de complete web-site geïntegreerd kunnen worden. Idealiter kun je bij elke web-app instellen welke URL de browser gebruikt om de web-app aan te spreken, bijvoorbeeld https://acme.nl/winkel/. Via het koppelvlak met de web-site kan dan worden ingesteld dat alle URLs die beginnen met https://acme.nl/winkel/ worden doorgestuurd naar de cloud instantie waarop de winkel web-app draait. Naarmate de site en de bezoekersaantallen groeien, kan het koppelvlak van de web-site worden uitgebreid, zodat het verkeer naar de web-site kan worden afgehandeld door meerdere cloud instanties (bij pieken kunnen dat er heel veel zijn) en dat er ook meerdere instanties van dezelfde web-app gestart kunnen worden waarover het zoeken in de catalogus en en plaatsen van orders verdeeld kan worden. Bij een goede voorbereiding hoeft de programmatuur voor de web-app hiervoor niet aangepast te worden. Mogelijk moeten de koppelvlakken naar de achterliggende systemen worden aangepast om, bij piekbelasting, de achterliggende systemen te beschermen, bijvoorbeeld door orders in een wachtrij te plaatsen en één voor één aan te bieden aan het order-invoersysteem.
 
Als het achterliggende systeem er nog niet is, begin dan met een koppelvlak waarbij het indienen van een verzoek en het ophalen van het antwoord gescheiden handelingen zijn (dat heet asynchroon). Dan kun je eerst een hele simpele achterliggende module laten maken waarbij elk verzoek handmatig wordt afgehandeld. Als deze module dan later vervangen wordt door een echt geautomatiseerd systeem, dan geeft een asynchroon koppelvlak ook meer mogelijkheden om de binnenkomende verzoeken betrouwbaar en snel over meerdere servers te verdelen.
 
Projecten die in één keer een grote stap proberen te maken hebben een griezelig kleine kans van slagen. Ik noem dat: meteen naar de bovenste trede van een trap proberen te springen. Je kunt alleen kleine stapjes maken als het IT landschap uit kleine modules bestaat. Om er zeker van te zijn dat je een module afzonderlijk kunt vervangen of verbeteren moet je goed nadenken over de koppelvlakken die deze module aanbiedt en aanspreekt. Dit is belangrijker dan van tevoren proberen te bedenken welke modules je allemaal nodig gaat hebben.
Advertenties

Wat duurt het allemaal lang!

Herkenbaar? Tja, of je nu iets nieuws wilt neerzetten, of een bestaand systeem wilt aanpassen, automatiseren kost een hoop tijd. Hoe zorg je er nu voor dat je vandaag snel met iets nieuws kunt komen. En morgen weer.
 
Daarvoor is het handig om te weten dat geautomatiseerde systemen uit meerdere onderdelen bestaan waarvan sommige flexibel zijn en andere niet. Verder is het zo dat de manier waarop systemen aan elkaar gekoppeld zijn invloed heeft op de flexibiliteit. Dit ligt redelijk voor de hand. Wat minder voor de hand ligt is dat hoge tijdsdruk over het algemeen tot inflexibele systemen leidt. Dat komt doordat de snelste manier om iets voor elkaar te krijgen vaak inhoudt dat er oneigenlijk gebruik wordt gemaakt van toevallige eigenschappen van het oude systeem. Als je dat een paar keer doet zonder de troep achter je op te ruimen, dan wordt de werking van het systeem volkomen ondoorgrondelijk, ook voor de programmeurs.
 
Hoe pak je zoiets dan beter aan. Simpel: knip de implementatie op in twee fasen: 1) realisatie van de functionaliteit en 2) herstellen en verbeteren van de onderliggende code. Laat je aan het eind van de herstel-fase uitleggen welke maatregelen er genomen zijn om de flexibiliteit van het systeem te herstellen of te verbeteren.
 
Het is helemaal mooi als dit gecombineerd kan worden met Scrum en DevOps. Scrum is een op dit moment veel gebruikte methode om programmatuur te ontwikkelen. Scrum werkt met kleine zelfsturende teams. Elk team brengt in korte tijd genaamd ’sprint’ (twee to vier weken) een aantal overzichtelijke wijzigingen aan in een systeem. Deze wijzigingen zijn afgebakend in ’stories’. Elke story is een overzichtelijke wijziging met aantoonbare waarde voor de organisatie. Aan het eind van de sprint worden deze wijzigingen ook direct in productie genomen. DevOps is een samentrekking van Development en Operations. Met DevOps wordt bedoeld dat dezelfde mensen die de programmatuur ontwikkelen ook de mensen zijn die de programmatuur in productie onderhouden.
 
Zorg ervoor dat een team in één sprint nooit stories voor de realisatie fase combineert met herstel- of verbeter-stories. Zorg er ook voor dat niet meer dan de helft van de teams werkt aan realisatie-stories. Beheerwerkzaamheden worden alleen uitgevoerd door teams die aan herstel- of verbeter-stories werken. En, last but not least: betaal beide fasen uit het Marketing budget. Waarom? Omdat anders de IT afdeling er belang bij heeft om herstel- en verbeter-stories uit te stellen ten gunste van realisatie-stories. Het resultaat is dan per saldo een stroperig veranderingsproces, klagende ITers en klagende Marketeers. Daarbij kan het verstandig zijn om het oplossen van incidenten wel te laten betalen uit het IT budget. Daarmee zorg je ervoor dat IT gemotiveerd is om goed na te denken over de prioriteiten bij preventief onderhoud.
 
Onthoud goed: als Marketing Professional ben jij de klant. Jij gaat over het budget en wie betaalt die bepaalt. Dus als jij zegt: ga heel hard hollen, dan gaan ze heel hard hollen. En als dat de verkeerde kant op is (richting brokkelige onontwarbare code), dan is dat ook waar je uitkomt. Een van de hoofdoorzaken van een inflexibel IT change proces is dat urgente en minder urgente doelen uit hetzelfde budget moeten komen en dat de minder urgente doelen daardoor ondergesneeuwd raken. Het is zaak om het minder urgente, maar zeer belangrijke, preventief onderhoud te scheiden van de urgente doelen om ervoor te zorgen dat de systemen flexibel genoeg blijven om ook in te toekomst mee te blijven bewegen met veranderende omstandigheden.