Organisatorische disfuncties weerspiegeld als architectonische complexiteit

We zijn de afgelopen jaren gaan erkennen dat er een sterke relatie bestaat tussen het ontwerp van een softwarearchitectuur en de vorm van de organisatie waardoor deze is ontwikkeld.

Binnen deze brede ruimte is een subonderwerp dat vaak mijn aandacht trekt de relatie tussen organisatorische disfuncties en hun invloed op softwarearchitectuur.

Vaak worden belangrijke en onnodige technische compromissen in een softwaresysteem geïntroduceerd als gevolg van politiek, slecht afgestemde prikkels of slechte communicatie.

Ik ben me ervan bewust dat voor elke redelijk grote organisatie de softwarearchitectuur zal worden gevormd om sociaal-politieke redenen, vaak gunstig. Ik beschouw disfunctioneel-gespiegelde complexiteit echter als technische complexiteit die buitengewoon kostbaar is, maar toch onnodig en vermijdbaar door verbeteringen in sociale interacties.

Een patroon dat ik heb waargenomen in grote en kleinere organisaties is The Accountability Protection Buffer . Dit patroon ontstaat wanneer een team zichzelf moet beschermen tegen problemen die worden geërfd via services waarvan ze afhankelijk zijn en die eigendom zijn van andere teams.

Buffer voor verantwoordingsbescherming

Wanneer teams verantwoordelijk zijn voor het leveren van een serviceniveau, maar ze niet volledig verantwoordelijk zijn voor het leveren van dat serviceniveau, is er een politiek risico. Hoe groter de kloof tussen verantwoordelijkheid en verantwoordelijkheid, hoe groter het risico en de ernst van politieke en technische disfuncties.

Denk eens aan dit scenario: in een grote organisatie zijn er twee afdelingen. De ene afdeling (Afdeling A) is volledig verantwoordelijk voor de website van het bedrijf, terwijl de andere afdeling (Afdeling B) API’s levert die worden gebruikt door de website en ook door derden.

Afdeling A is verantwoordelijk voor het bieden van de best mogelijke webervaring – functies, prestaties, bruikbaarheid en meer. Toch hebben ze geen volledige controle over al deze kenmerken, ze zijn gedeeltelijk afhankelijk van de API’s van Afdeling B.

Afdeling B beschouwt afdeling A als een van de vele klanten. Hun doel is niet alleen om afdeling A te bedienen, hun API’s zijn in de eerste plaats ontworpen voor andere klanten. Afdeling A stuit op problemen:

Deze problemen resulteren rechtstreeks in een langzame, onbetrouwbare en niet-innovatieve webervaring. Afdeling A heeft deze problemen geërfd als gevolg van hun afhankelijkheid van de API’s van Afdeling B.

Bijgevolg is de klanttevredenheid laag en de website-gestuurde business laag. Zowel externe klanten als interne belanghebbenden geven afdeling A de schuld – de website is traag, onbetrouwbaar en lijkt zelden verbeteringen toe te voegen. Afdeling A bezit de website, de website is niet goed genoeg, en daarom doet afdeling A het slecht en stelt het bedrijf teleur.

Als gevolg van de overgeërfde problemen raakt afdeling A confronterend met afdeling B over het gebrek aan verbeteringen of empathie. Hun relatie verslechtert tot een vete.

Confrontatie en agressie leveren geen verbeteringen op. In feite maken ze de zaken erger. Afdeling A is nu wanhopig op zoek naar een manier om hun problemen op te lossen. Ze besluiten om een ​​ Accountability Protection Buffer

te implementeren

Ze creëren een importeur die ‘s nachts draait. Het zuigt alle gegevens uit de API’s en slaat deze op in hun eigen lokale database. Dit stelt hen in staat om de prestaties, betrouwbaarheid en bruikbaarheid van de website drastisch te verbeteren en stelt hen in staat om sommige soorten functies veel gemakkelijker te implementeren.

Ten slotte zijn ze nu verantwoordelijk en aansprakelijk.

Het succes van Afdeling A was niet zonder kritiek. Het kostte hen drie maanden om de importeur goed te implementeren en te stabiliseren, gedurende welke tijd geen grote verbeteringen aan de website werden aangebracht.

Kort daarna komt er meer kritiek naar voren omdat er een nieuwe golf van problemen opduikt:

Het wordt een fulltime baan voor Afdeling A om gegevensproblemen te onderzoeken en op te lossen. Vanwege de slechte relatie tussen afdelingen A en B, is de tijd en de hoeveelheid verspilde energie bij het onderzoeken van gegevensproblemen dramatisch.

Uiteindelijk zijn de klachten van klanten en interne belanghebbenden veel erger naarmate de twee systemen verder uit elkaar drijven en de problemen groter worden. Klanten zien één prijs op de website, maar wanneer ze iets proberen te kopen, krijgen ze een hogere prijs. Het merk van het bedrijf wordt beschadigd en de loyaliteit van klanten verdwijnt.

De technische kosten van organisatorische disfuncties

Er is een aanzienlijke hoeveelheid tijd geïnvesteerd om de situatie tussen Afdeling A en Afdeling B in veel opzichten erger te maken.

Niemand weet of de agressie van afdeling A of de onwil van afdeling B de hoofdoorzaak was. Hoe dan ook, het is vrij duidelijk dat het gebrek aan samenwerking resulteerde in een enorm verlies aan kansen voor het bedrijf.

In plaats van te innoveren op het gebied van zakelijke kansen, besteedt afdeling A de helft van zijn tijd aan het ontwikkelen en onderhouden van een technische muur, zodat ze geen interactie hebben met afdeling B. En toch is de klantervaring slecht.

Ik weet zeker dat je soortgelijke situaties zult tegenkomen in veel, zo niet alle, grote systemen waaraan je hebt gewerkt. Misschien heb je deel uitgemaakt van het probleem, ik weet zeker dat ik dat ooit heb gedaan.

We moeten stoppen en onszelf regelmatig afvragen: proberen we organisatorische disfuncties te omzeilen? Verergeren we het probleem?

Hoe disfunction-mirrored-complexity te voorkomen?

Ik zal niet beweren dat voorkomen dat organisatorische disfuncties technische complexiteit worden, een eenvoudig op te lossen probleem is. Het is een probleem dat elke laag in de organisatie raakt.

Ten eerste moeten incentives worden afgestemd. Als de organisatie geen duidelijke focus op portfolioniveau heeft en teams in veel verschillende richtingen worden uitgerekt, zullen ze degenen die van hen afhankelijk zijn, niet tevreden kunnen stellen. Ze moeten weten waar ze hun inspanningen op moeten richten.

Zoals altijd heeft het probleem te maken met hoe de teams worden gefinancierd. Als afdeling B niet het budget krijgt om genoeg mensen in te huren om alle teams te ondersteunen die afhankelijk zijn van hun diensten, zullen er duidelijk problemen zijn.

Als afdeling A bijvoorbeeld een budget krijgt om een ​​reeks nieuwe websitefuncties te ontwikkelen, maar afdeling B geen budget heeft gekregen om de API-wijzigingen door te voeren, heeft de organisatie een enorm conflict in het systeem ontworpen dat niet goed kan eindigen , en zal waarschijnlijk de productiviteit van alle teams verminderen als ze verwikkeld raken in politieke gevechten.

Binnen elk team moet elk individu ernaar streven om samen te werken aan wat het beste is voor de algehele softwarearchitectuur en het bedrijf in het algemeen. Dit betekent meer discussie, empathie en proberen een deal te vinden die voor alle partijen werkt.

We kunnen alleen van mensen verwachten dat ze zich zo gedragen als leiders een omgeving creëren die hen stimuleert om zich zo te gedragen. Waar veelvuldig en respectvol samenwerken in de cultuur ingebakken zit. Waar teamoverschrijdend succes wordt beloond en individuele doelen niet met elkaar in strijd zijn. Waar de schuld wordt gedeeld en gezien als een collectief probleem en waar teams vrij zijn om zichzelf te organiseren om ze op te lossen.

Een goede softwarearchitectuur die bedrijfsinnovatie stimuleert, is een artefact van een goed ontworpen sociotechnisch systeem. De rol van technisch leiderschap bij het afstemmen, versterken en stimuleren van teams is cruciaal voor het succes van uw IT-aangedreven organisatie.

Aarzel niet om contact met me op te nemen als u op zoek bent naar technisch leiderschap of domeingestuurde ontwerpexpertise, advies of training.