Low code & team interactie
Chris Vinke, CEO & oprichter GRN Consultancy
Arnaud Disberg, Intelligent Automation Specialist
Ewout Masereeuw, Automation Expert
In dit derde deel van onze blog serie leggen we uit wat het verschil is en welke problemen ze voor organisaties oplossen. We doen dit door ze middels Team topologies met elkaar te vergelijken, zodat niet alleen het verschil duidelijk is, maar we ook een gemeenschappelijke taal (en instrument) hebben voor het toepassen ervan op je eigen situatie.
Team interactie
Aan welke knoppen kan je als organisatie draaien als het gaat om het organiseren van low code ontwikkeling? Om die vraag te beantwoorden biedt de theorie van Team topologies uitkomst.
Team topologies beschrijft 3 vormen van interactie tussen teams:
- Samenwerking met een ander team, voor een bepaalde periode; bedoeld om te innoveren, problemen op te lossen en alternatieven te verkennen.
- As-a-service; gebruiken of aanbieden van een dienst met minimale interactie met het andere team.
- Faciliteren; helpen of geholpen worden door een ander team om obstakels weg te nemen.
In ieder van deze interacties draait het om afhankelijkheid met een ander team in termen van kennis, taken en/of resources (mensen, middelen of technologie).
NB. Organisaties zoals Spotify houden deze afhankelijkheden tussen teams bij om de cognitieve belasting per team tot een minimum te beperken en streven naar samenwerking met hooguit één team, faciliteren van enkele teams en as-a-service interactie met meerdere teams.
In essentie hebben de verschillende manieren van low code ontwikkeling te maken met de interactie tussen business en IT teams, die we met team topologies kunnen duiden.
Citizen development - Nadruk op DevEx en UX
Bij citizen development is de gedachte dat IT vooral een platform biedt voor business gebruikers waarop zij zelfstandig oplossingen kunnen realiseren (zoals chatbots , automation en self-service BI). Daarbij komt nauwelijks tot geen code aan te pas en sluit daarbij aan op de no code gedachte die we in deel 2 hebben besproken. Het platform biedt de vangrails en de governance is ‘ingebakken’. Het probleem dat organisaties met citizen development oplossen is de wildgroei aan Excel-applicaties (zgn. shadow IT) en daarmee deels het capaciteitsgebrek van IT.
In citizen development vindt de interactie tussen business en IT plaatsvindt op basis van de as-a-service team topology; IT levert een platform as-a-service aan de business. De afhankelijkheid tussen business en IT bestaat daarmee hoofdzakelijk uit technische resources.
Voor een goede invulling van citizen development is de as-a-service interactie essentieel. Simpel gezegd moet het platform dat IT biedt ‘gewoon werken’. IT moet een goed begrip hebben van de business gebruikers van het platform en het managen van het platform. Daarnaast moet IT een sterke verantwoordelijkheid voelen (attitude) om de citizen developer experience (DevEx en UX) zo aantrekkelijk mogelijk te maken.
Met een goed platform kan IT het ontwikkelen van oplossingen door de business faciliteren, het sleutelwoord hierbij is eigenaarschap. Er moet bij IT een duidelijke focus zijn op de gebruikerservaring van het platform maar daartegenover staat dat de door de business ontwikkelde oplossingen juist zoveel mogelijk in beheer moeten blijven van de business zelf.
Fusion development - Veel interactie en wederzijds respect
Fusion development is gericht op een nauwe samenwerking tussen business en IT om samen oplossingen te realiseren. Veelal is de gedachte dat beide op hetzelfde platform werken en de oplossingen zijn complexer of omvangrijker.
Het probleem dat organisaties met fusion development oplossen is het capaciteitsgebrek van IT door het versterken (en uitbreiden) van rollen zoals proces- en data analisten en UX designers. Omdat de producten die zij opleveren (procesmodellen, datamodellen, UX designs) in low code platforms de basis zijn van de realisatie.
In fusion development is de interactie tussen business en IT een combinatie van samenwerking, faciliteren en as-a-service. Door de verschillende interacties zijn er ook veel afhankelijkheden te vinden tussen business en IT, deze bestaan vaak uit een combinatie van kennis, taken en/of resources.
Gedurende de ontwikkeling van een oplossing zal er sprake zijn van nauwe samenwerking tussen business en IT. Daarnaast biedt IT een platform (as-a-service) waarop gezamenlijk ontwikkeld wordt; bijvoorbeeld met een eigen of gedeelde ontwikkelomgeving (IDE). Ook komt het veel voor dat IT de complexere onderdelen van de oplossing voor rekening neemt (samenwerking op een aantal onderdelen).
Voor fusion development staat de samenwerking tussen business en IT centraal. Alignment tussen de teams moet goed zijn en er moet sprake zijn van wederzijds respect, een sterke ‘appetite’ en vaardigheden om samen te werken (pair programming, mob testing, whiteboard sketching etc.).
De samenwerking betekent wel dat er een hogere cognitieve last is voor beide teams. De samenwerking moet dus zo worden vormgegeven dat de (tastbare) resultaten hiertegen opwegen.
NB2. Een federated organisatiemodel is een decentraal model, maar wel met centrale regiefunctie, zoals een Center of Excellence.
Enterprise low code development - Helpen en geholpen worden
Enterprise low code development volgt de meest traditionele vorm van softwareontwikkeling, waarbij business teams met name verantwoordelijk zijn voor het aanleveren van business requirements en IT teams op basis daarvan een oplossing realiseren. Het probleem dat organisaties hiermee oplossen is ook het capaciteitsgebrek van IT, maar dan door het verhogen van de productiviteit van de bestaande IT teams door low code ontwikkeling.
In het geval van enterprise low code development is er vaak een center of excellence (CoE) die zelf oplossingen ontwikkelt of een decentraal team daarbij ondersteunt (zgn. federated teams). Dit model is met name zinvol voor organisaties die de adoptie van een low code platform willen vergroten, decentraal georganiseerd zijn maar wel centraal regie willen voeren.
De interactie tussen business en IT bestaat uit samenwerking waarbij IT een stream-aligned team is met afhankelijkheid van de business op het gebied van kennis (met name requirements en domein expertise).
In de interactie draait het om het samenwerken tussen business en IT zodat IT een zo’n goed mogelijk begrip heeft van de business requirements. Wederom geldt dat wederzijds respect en onderling begrip centraal moet staan. En dat vaardigheden in het samenwerken van groot belang zijn.
In de interactie tussen een centraal CoE en een decentraal ontwikkelteam staat vooral faciliteren centraal. Het CoE zal meerdere federated teams tegelijkertijd ondersteunen om effectiever te werken, sneller te leren, nieuwe technologie beter te begrijpen en veelvoorkomende problemen en obstakels bij teams weg te nemen. Teams moeten elkaar helpen (of coachen) en geholpen willen worden – een open minded houding is daarom van belang.
Tot slot
Ieder model dat we besproken hebben heeft voor- en nadelen. En welk model het beste past bij een organisatie is afhankelijk van een aantal factoren. Zoals de grootte van de organisatie, het technologische landschap en de mate waarin medewerkers kennis hebben van softwareontwikkeling.
Welk model je als organisatie ook kiest, als je de teams en de interactie tussen de teams goed vormgeeft, dan volgt de technologie (bijna) vanzelf.
Nederlands 
English (UK)