Low code & team interaction
Chris Vinke, CEO & founder 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 interaction
Which buttons can you turn as an organization when it comes to organizing low code development? To answer that question, the theory of Team topologies offers a solution.
Team topologies describe 3 forms of interaction between teams:
- Cooperation with another team, for a certain period of time; intended to innovate, solve problems and explore alternatives.
- As a service; using or offering a service with minimal interaction with the other team.
- Facilitate; help or be helped by another team to remove obstacles.
Each of these interactions revolves around dependency with another team in terms of knowledge, tasks and/or resources (people, resources or technology).
Note: 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 essence, the different ways of low code development have to do with the interaction between business and IT teams, which we can interpret with team topologies.
Citizen development - Emphasis on DevEx and 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, the interaction between business and IT takes place on the basis of the as-a-service team topology; IT provides a platform as-a-service to the business. The dependence between business and IT therefore mainly consists of technical 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.
With a good platform, IT can facilitate the development of solutions by the business, the key word here is ownership. IT must have a clear focus on the user experience of the platform, but on the other hand, the solutions developed by the business must remain under the management of the business itself as much as possible.
Fusion development - Lots of interaction and mutual 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.
The problem that organizations solve with fusion development is the lack of IT capacity by strengthening (and expanding) roles such as process and data analysts and UX designers. Because the products they deliver (process models, data models, UX designs) in low code platforms form the basis of the realization.
In fusion development, the interaction between business and IT is a combination of collaboration, facilitation and as-a-service. Due to the various interactions, there are also many dependencies between business and IT, which often consist of a combination of knowledge, tasks and/or 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).
For fusion development, the collaboration between business and IT is central. Alignment between the teams must be good and there must be mutual respect, a strong appetite and skills to work together (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.
Note 2: A federated organizational model is a decentralized model, but with a central management function, such as a Center of Excellence.
Enterprise low code development - Help and be helped
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 the case of enterprise low code development, there is often a center of excellence (CoE) that develops its own solutions or supports a decentralized team (so-called federated teams). This model is particularly useful for organizations that want to increase the adoption of a low-code platform, are organized decentrally, but still want to maintain central control.
The interaction between business and IT consists of cooperation in which IT is a stream-aligned team with dependence on the business in terms of knowledge (specifically requirements and domain expertise).
The interaction revolves around cooperation between business and IT so that IT has the best possible understanding of the business requirements. Once again, mutual respect and mutual understanding must be central. And that skills in cooperation are of great importance.
In the interaction between a central CoE and a decentralized development team, facilitation is central. The CoE will support multiple federated teams simultaneously to work more effectively, learn faster, better understand new technology and remove common problems and obstacles for teams. Teams must help (or coach) each other and want to be helped – an open-minded attitude is therefore important.
Finally
Each model we discussed has advantages and disadvantages. And which model best suits an organization depends on a number of factors. Such as the size of the organization, the technological landscape and the extent to which employees have knowledge of software development.
Whichever model you choose as an organization, if you properly design the teams and the interaction between the teams, the technology will (almost) follow automatically.