Development

Software-ontwikkeling
Scrum

Oversimplificatie is groot risico

Complexiteit niet wegredeneren maar accepteren en reduceren

© CC BY 2.0 - Flickr,  Kay Kim
20 april 2017

Complexiteit niet wegredeneren maar accepteren en reduceren

De IT-manager wordt geconfronteerd met toenemende complexiteit, zowel binnen het IT-domein als daarbuiten. Om die complexiteit beheersbaar te houden, wordt de oplossing vaak gezocht in organisatorische en procesmatige middelen binnen de IT-afdeling: agile werken, zelfsturing et cetera. De vraag is of dit leidt tot het beheerst omgaan met complexiteit.

Voor het IT-domein neemt de complexiteit toe, zeker bij bedrijven met stevige legacy-applicaties. Een belangrijke complicerende factor zijn de technologische ontwikkelingen.

Van monolithische Cobol-applicaties groeien we door naar een complex microservice-landschap. Het aanbod van technologieën en hulpmiddelen voor ontwikkeling en beheer van software is groot.

Bij afwegingen rondom technologie staat men voor de keuze: state of the art of bewezen technologie? Oftewel: de afweging tussen veronderstelde efficiëntieverbetering en robuustheid. Op de achtergrond speelt dat een te grote variëteit aan technologie kan leiden tot problemen met beheersbaarheid. Bij nieuwe of weinig gebruikte technologie is het moeilijk personeel te vinden.

De kunst is abstracties te specificeren

In toenemende mate worden systemen ontsloten voor het grote publiek. Dit brengt nieuwe uitdagingen met zich mee op het gebied van functionele en niet-functionele eisen. Juist die laatste zijn vaak cruciaal. Cruciaal omdat ze de beleving van het genoemde publiek beïnvloeden. Sterker, ze zijn reputatiebepalend voor de betreffende organisatie. Ingrijpende organisatorische en procesmatige veranderingen zijn vaak nodig, bijvoorbeeld als gevolg van de noodzakelijke 24/7-beschikbaarheid.

Meten

Hoe vaak worden cruciale beslissingen niet genomen op basis van vooronderstellingen, die niet geverifieerd zijn? Meet op basis van de volgende elementen en borg de evaluatie daarvan:

• Statische metingen van codekwaliteit;

•     Implementatie architectuur in componenten en code;

•     Applicatiegebruik (middels gedetailleerde logging);

•     Beschikbaarheid en verstoringen;

•     Volwassenheid organisatie (Cobit);

•     Voortgang van het projectportfolio op directieniveau.

 

Bij veel organisaties bestaat er een portfolio aan systemen en toepassingen. De systemen bevinden zich, als de organisatie enige historie bezit, in verschillende stadia in de levensloop en bezitten een verschillende mate aan technische schuld. Wij hebben de voor een portfolio benodigde expertises van een grote organisatie op een rij gezet en kwamen uit op meer dan 100.

IT is in toenemende mate cruciaal voor de uitvoering van bedrijfsprocessen. Hoge time-to-market-eisen en een soms onuitputtelijke vraag vanuit de doel- of klantorganisatie zijn het gevolg.

Ten slotte dient de IT-manager adequaat om te gaan met beveiliging, privacyvraagstukken en eisen vanuit wetgeving. Ook deze ontwikkelingen gaan snel en zijn vaak onoverzichtelijk.

Het bestuur lijkt uit te gaan van een versimpelde werkelijkheid

Deze complexiteit hoeft geen probleem te zijn. Het is bijzonder hoe onze maatschappij draait op complexe systemen, die de eindgebruiker steeds meer mogelijkheden geven. Toch valt het voor de IT-manager niet altijd mee. Samenwerking of, zoals dat tegenwoordig heet, verbinding met bestuur of directie is fundamenteel om de complexiteit te managen en waar mogelijk te reduceren.

Ontkoppeling bestuur

Agile en Scrum ontwikkelen zich tot een algemeen toegepast bedrijfs-/organisatieconcept, toegepast in steeds meer branches. Dit transitieproces kan leiden tot ontkoppeling tussen werkvloer en bestuur of directie (hierna genoemd ‘bestuur’). De managementlaag wordt gesaneerd, het bestuur daarboven wordt strategisch gericht en de onderliggende organisatielagen bij elkaar gezet in zelfsturende teams. Het gevaar is dat de kloof tussen het strategisch gerichte bestuur en de operationeel gerichte mensen groter wordt. Het gesaneerde managementniveau had, als het goed is, inhoudelijke kennis, een feitelijk beeld van de operatie en voeling met het bestuur. Het gevaar is dat de sturing vanuit het bestuur te afstandelijk en te globaal is, wat leidt tot gebrek aan richting bij de zelfsturende teams.

Als deze (ont)koppeling onvoldoende aandacht krijgt, zien we dat:

• eigenaarschap, taken en verantwoordelijkheden onduidelijk zijn;

• budgetten onvoldoende realistisch worden ingeschat, zeker in maatwerkomgevingen;

• het vertrouwen ontbreekt en er zelfs onderliggende angst ontstaat;

• prioritering een bijna onmogelijke taak wordt.

Het kan zijn dat de ontkoppeling een tijdelijke groeistuip is. Die groeistuip wordt opgelost als het bestuur voor het eigen functioneren de agile principes omarmt. Een bedrijf dat we kennen als klant werkt al lange tijd agile (agile is cultuur geworden) en eist dat managers en directie een deel van hun tijd operationele activiteiten uitvoeren. Dat werkt goed, leidt tot face-to-face-communicatie en tot effectieve en efficiënte systemen, die daadwerkelijk waarde toevoegen aan het voortbrengingsproces van de organisatie.

Simpel

Het beheersen en reduceren van complexiteit binnen het IT-domein kan bemoeilijkt worden door het fenomeen oversimplificatie. Het bestuur wenst de complexiteit, waar het IT-domein mee te maken heeft, niet onder ogen te zien. Het bestuur en vaak ook de op bestuurlijk niveau opererende adviseurs lijken uit te gaan van een abstracte, versimpelde werkelijkheid. Die werkelijkheid is uitgewerkt in te globale documenten (oplossingsvoorstellen, architecturen). Jammer genoeg geldt voor het beheer en de ontwikkeling van de IT-portfolio vaak de uitspraak ‘the devil is in the detail’.

Reduceren complexiteit

Beheersing van complexiteit begint met het onder ogen zien van de complexiteit. De vervolgstap is het reduceren ervan:

• Start met wat overzichtelijk, urgent en goedkoop is (MVP);

• Hoed u voor groots en meeslepend;

• Bepaal stip aan horizon en werk met voortschrijdend inzicht;

• Koester uw legacy-omgeving;

• Blijf meten en maak een feedback-loop om verbetering in gang te zetten.

Als de betrokken projectleider dat aan de orde stelt, doet men dit af met zinnen als: ‘Doe het gewoon!’, ‘Wil je vernieuwing tegenhouden?’ of ‘Blijf je achter de kar hangen?’.

Het inspelen op deze oversimplicatie door als IT-afdeling ook te komen met abstracte documenten met veel disclaimers is geen oplossing. Sturing wordt nog moeilijker: waar zegt het bestuur ‘ja’ op?

Hoe kunnen we besturen bereiken en oversimplicatie pareren? Hieronder een opsomming van mogelijke instrumenten om de complexiteit binnen het IT-domein te beheersen en waar mogelijk te reduceren.

Stappen

1. Communicatie is cruciaal. Probeer het bestuur inzicht te geven in de complexiteit waar de IT-functie mee te maken heeft en aan te geven hoe deze beheerst en gereduceerd kan worden. Ga niet mee met de oversimplificatie, probeer feitelijk en concreet te zijn en complexiteit niet te ontkennen.

2. Basis voor communicatie met het bestuur is inzicht in het complexe landschap. Een middel is de zogenaamde platen. Wij hebben goede ervaringen met het beeldend overbrengen van relevante aspecten van het IT-domein. Geen meningen, geen ontwerpen, maar de feitelijke situatie. Bijvoorbeeld het IT-landschap, de portfolio-infrastructuur en applicatiestructuur. Eigenlijk zou dat overzicht in de directiekamer moeten hangen van elke organisatie die sterk afhankelijk is van IT voor haar voortbrengingsproces.

3. Als er sprake is van oversimplificatie is de kunst abstracties te specificeren. Een heel simpel middel is het stellen van vragen. Bijvoorbeeld gericht op het specificeren van de doelen achter de inzet van nieuwe technologische middelen. Of het gezamenlijk specificeren van strategie, zodat deze vertaald wordt in operationele doelen. Geregeld komen we de ‘model-code gap’ tegen. Remedie is om (enterprise)architectuur te specificeren naar softwarearchitectuur [zie artikel Softwarearchitectuur onderbelicht, februarinummer AG Connect].

4. Er is meer meetbaar dan we denken. En dan bedoelen we niet de op controle gerichte KPI’s, bepaald door een stafafdeling, maar het meten gericht op inzicht in de complexiteit. Metingen aan het proces, de software (bijvoorbeeld gericht op reductie technische schuld) en gebruikersgedrag [zie kader]. Bij verdere opkomst van servicegericht werken wordt het meten van de kwaliteit van dienstverlening en de feitelijk efficiëntie van bedrijfsprocessen van belang.

5. Reductie en beheersbaarheid van complexiteit zijn gebaat bij een pragmatische benadering. Een hele simpele regel, die het beste clean en consistent doorgevoerd kan worden: start met wat overzichtelijk, urgent en goedkoop is (zie kader). De bekende ‘Minimum Viable Product’-benadering van Eric Ries sluit hierop aan.

6. Koester tevens het omvangrijke legacy-systeem. Dit maatwerk is vrijwel altijd drager van unieke kennis van het bedrijf of de organisatie en draagt de primaire processen. De flexibiliteit laat wellicht te wensen over, maar over het algemeen zijn ze robuust, betrouwbaar en doen het gewoon. De praktijk leert dat vervanging van dit soort systemen of mislukt of een lange doorlooptijd in beslag neemt. Indien mogelijk, combineer de legacy met flexibele beperkte applicaties voor bijvoorbeeld ontsluiting voor nieuwe doelgroepen.

Lees meer over
Zie ook Development op AG Connect Intelligence
1
Reacties
Atilla Vigh 20 april 2017 12:41

Heel interessant artikel. Dank daarvoor.
Of een organisatie nu wel of geen moderne ontwikkelmethodieken gebruikt, noem mij een organisatie waar op elk domein (ICT, Finance, Logistiek, een of meerdere primaire bedrijfsprocessen, etc..) de verschillende abstracties dusdanig zijn gevisualiseerd, dat vanaf het strategisch management met zijn visie, missie en doelstellingen elke denkbare inbreuk op de inrichting van de organisatie zichtbaar wordt?
Het is al enorm moeilijk om überhaupt een organisatie te vinden waar de missie, visie en doelstellingen van een organisatie zuivere relaties heeft met de inrichting. De architectuurprincipes van elk domein zouden directe afgeleiden moeten zijn van die missie, visie en doelstellingen.

Het andere aspect uit dit artikel dat bij mij naar voren komt is "wat is complex". Voor mij is complex niet alleen iets met veel abstractieniveaus. Dat is te eenvoudig. Er zijn enkelvoudige "dingen" die heeeeeeel complex zijn: ik begrijp ze dan ook niet. Voorbeeld: ik gok zo dat de wetenschappers (en dan praten we over materiaaldeskundigen, elektrotechnici, etc....) bij ASML onderling op een andere manier onderling communiceren, dan dat er een zuivere vertaalslag naar boven gemaakt kan worden. Het verlies aan concrete informatie en subjectieve meningen in een dergelijk landschap kunnen alleen door inhoudsdeskundigen worden gewaarborgd. Iedereen zal het toch eens zijn, dat een administratieve organisaties van een gemeente een stuk eenvoudiger is. Zonder de medewerkers op een gemeentehuis te beledigen, maar je zult echt meer kennis en kunde nodig hebben op een topniveau bij ASML, als dat bij een gemeente. Maar is een gemeente organisatie qua inrichting dan niet complex? Niet op inhoud, maar juist op besluitvorming. Het idee dat veel mensen denken dat besluiten genomen worden op puur inhoudelijke gronden is naïef. Wat wel maatgevend is voor de kwaliteit van besluiten is de missie, visie en doelstellingen van een organisatie. Zo zal het besluitvormingsproces bij ASML een stuk een eenvoudiger zijn: hun ultieme doel is winst, winst en winst. Vermoedelijk nog een paar andere dingen, maar die zullen een ondergeschikt belang hebben. De belangen bij een gemeente of welk ander politiek orgaan, zijn gigantisch. Juist door die ondoorzichtige besluitvorming, is het ook veel lastiger om een relatief eenvoudige administratieve organisatie als een gemeente in te richten. Het zijn niet de banale processen, ICT en andere zaken die vaak lastig zijn, maar de meerdere belangen die de uitvoerders "stuur"loos maken.

Een van de aspecten die ik bij dit onderwerp vaak nooit hoor of lees is de wens van transparantie. Dat willen de uitvoerders graag, omdat ze dan weten waar ze aan toe zijn. Maar besluitvormers hebben het vaak zo vaag mogelijk. Zodra daar weer een architect, business consultant of andere externe adviseur naar binnen wandelt en probeert zichtbaar te maken hoe de besluitvorming en/of organisatie inrichting daadwerkelijk in elkaar zit, wordt deze op een zijspoor gezet. Een organisatie (lees top) moet het ook willen. Zodra dat niet het geval is, stop er maar mee, want dan vecht je tegen windmolens.

Reactie toevoegen