IT-architectuur belangrijk is. Laat me je vertellen waarom

We houden van tekenen !!

(Miguel Angel Coll) (2 juli 2020)

Ik heb de afgelopen 5 jaar in mijn carrière geïnvesteerd in de IT-architectuurfunctie. Al die jaren moest ik het loutere bestaan ​​van architectuurfunctie zelfs voor mezelf rechtvaardigen. Soms ook het gevoel dat we indringers waren, omringd door de mensen die het werk echt doen (ontwikkelaars en sys-ops).

Na 5 jaar ben ik er nog steeds van overtuigd dat architectuur belangrijk is, laat me je wat argumenten geven voor bewijs het.

Beste prijs-kwaliteitverhouding

Als ik slechts één missie voor IT-architectuur moet kiezen, zal ik deze kiezen. IT-afdelingen en platforms groeien doorgaans alleen maar. Sommigen van hen omdat het bedrijf groeit, anderen omdat het bedrijf midden in een digitale transformatie zit. Het resultaat is in ieder geval hetzelfde, jaar na jaar heb je meer systemen, meer teams, meer complexiteit.

Ik hou ervan een IT-platform hyper-over-simpel te maken als volgt:

De belangrijkste architectuurfunctie is om de relatie met de IT-platformkosten en de waarde die het oplevert in een goede vorm.

Een tijdje geleden werkte ik in een reisbureau met een bedrijfsmodel gebaseerd op online productdistributie via APIs. Die APIs waren sterk gekoppeld aan een enorm monolithisch systeem gebaseerd op Oracle Exadata. Dat betekent dat elke keer dat we groeien in API-verkeer (en het verkeer groeide meer dan de conversieratio), we onze database verticaal moeten schalen.

Architectuur stimuleert de efficiëntie van het IT-platform

Architectuurvoorstel was destijds om API-services te ontkoppelen om een ​​nieuwe microdienstenlaag te creëren op de cloud om al het verkeer tegen lagere kosten af ​​te handelen terwijl de database-infrastructuur alleen voor de boeking en bewerkingen behouden blijft (die helaas niet exponentieel groeien). Het resultaat was dat er de volgende jaren geen nieuwe infrastructuur meer nodig was voor de DB en een betere relatie tussen verkeer en IT-kosten.

Gebruik dezelfde taal

Maak je geen zorgen, ik ben niet praten over programmeertalen (java, python, enz.). Als architect sta ik meer dan open voor diversiteit met enige controle (geen chaos). Hier verwijs ik naar Conceptual Integrity , term die ik voor het eerst las op Mythical Man Month and Other Essays on Software Engineering van Frederick P Brooks Jr.

In het boek legt Fred Brooks uit hoe IT-teams groeien en hoe die groeiende impact op hun productiviteit heeft. Voor Fred is de communicatie tussen teams een van de grootste problemen die je moet aanpakken als je een IT-team probeert op te schalen. Om taken te parallelliseren, moeten teams zo onafhankelijk mogelijk zijn. Maar zodra alle teams op een onderling verbonden platform werken, hebben we wat communicatie tussen teams nodig. Is in die scenarios wanneer het hebben van een gemeenschappelijke taal de sleutel tot succes is.

Ik herinner me nog steeds eindeloze gesprekken met mijn voormalige teamgenoten die bespraken wat een systeem, een technologiecomponent, een interface of een bouwsteen is. Als je op een grote IT-afdeling werkt, weet je waarschijnlijk hoe frustrerend het is dat de dingen door teams anders worden genoemd. Soms is het zelfs het ergst als ze dezelfde naam voor verschillende dingen gebruiken.

Een bekend voorbeeld van die laatste is het benoemen van een monoliettoepassing met slechts één naam. Zelfs als het logisch is (want het is een monoliet), als je die monoliet wilt breken, heb je meer details nodig. Het introduceren van verschillende namen voor de database, de frontend, het datamodel, enz. Zal helpen bij het proces.

Zelfs als u zich op een kleine IT-afdeling of een grotere bevindt, is het altijd een goed moment om te beginnen met een naamgevingsconventie, een service / systeem / oplossingscatalogus, enz. Je weet nooit hoe groot je in de toekomst zult zijn.

Over conceptuele integriteit, blijf bij me, hoe eerder hoe beter.

Forceer ontwerpgesprekken

In mijn gedachten begint elke oplossing voor een probleem altijd met een analyse van de situatie en het ontwerp van de oplossing voordat deze wordt geïmplementeerd. De realiteit voor een ontwikkelteam is dat we elke week nieuwe problemen op tafel hebben om op te lossen. Na enkele maanden van Business as Usual-routines, beginnen de teams te draaien op de automatische piloot en vinden ze oplossingen voor problemen zonder al te veel na te denken over de implicaties op middellange en lange termijn.

Een architectuurfunctie geïntegreerd in de ontwikkelingsteams helpen altijd over het vergroten van de ontwerpgesprekken om de beste oplossingen te vinden voor de problemen waarmee we worden geconfronteerd.

Ik daag ook graag het ouderwetse ontwikkelingsproces uit, waarbij het ontwerp wordt gezien als iets dat moet worden gedaan aan het begin van een project.In het artikel The Architect Elevator – Visiting the upper verdiepingen , Gregor Hohpe beschrijft mijn begrip van de architectuurrol perfect:

“… Dus in plaats van alle cruciale beslissingen aan één persoon toe te vertrouwen, kan het projectrisico worden verminderd met minimaliseren van het aantal beslissingen dat onomkeerbaar is .”

Architectuur moet aanwezig zijn tijdens het hele ontwikkelingsproces . Inderdaad, als je aan Agile werkt, zul je bij elke iteratie beslissingen nemen.

Strategiediscussies

Als IT-man zal ik het heerlijk vinden om in het bestuur van het bedrijf te zitten met zeer specifieke en gedetailleerde technische discussies. De realiteit voor middelgrote en grote bedrijven is dat bestuursleden het zich niet kunnen veroorloven om al te diep in de details te gaan. Maar moet de directie van het bedrijf beslissingen nemen over de strategie zonder de IT-situatie te begrijpen?

In de huidige wereld zijn er maar een paar bedrijven die kunnen zeggen dat IT niet in het centrum van hun strategie staat. Wie is er dan verantwoordelijk voor het vertalen van de strategie naar IT en vice versa? – je weet het antwoord al.

Een van onze grootste bijdragen aan het TUI Destination Experiences-architectuurteam was het tekenen van een Target Architecture Model. De TAM stelt niet-IT-mensen in staat onze belangrijkste oplossingen en systemen te begrijpen en te begrijpen hoe deze verbonden zijn met de waardestromen van ons bedrijf. Na het verspreiden van de TAM, begonnen de meeste van onze strategiegesprekken door te kijken hoe onze architectuur eruitziet en hoe we ons aan een nieuwe situatie zouden moeten aanpassen.

Maar wees voorzichtig, een Target Architecture Model is niet bedoeld als statisch beeld van de “as-is” en “to-be” architectuur. Als je dat soort oefeningen probeert te doen, krijg je iets kortstondigs dat precies past bij een specifiek project. Naar mijn mening is het beter om je te concentreren op het tekenen van de belangrijkste componenten van je architectuur en het selecteren van de dingen die je wilt behouden (omdat ze de kern van je bedrijf zijn) en dingen aan te wijzen die je nodig hebt om te veranderen of te evolueren.

Eerste dia van de TAM-presentatie

Onthoud altijd wat Dee Hock, oprichter van Visa zei:

Een eenvoudig, duidelijk doel en principes leiden tot complex intelligent gedrag. Complexe regels en voorschriften leiden tot simpel dom gedrag.

Tot in het oneindige en verder

De obsessie om agile te zijn, is dat IT-teams soms transformeren tot besluitvormers op korte termijn . Zoals we al hebben besproken, moeten we er zeker van zijn dat de beslissingen die we vandaag nemen toekomstbestendig zijn. Soms betekent het om een ​​duidelijk beeld te hebben van de strategie voor de lange termijn. Soms betekent het dat je moet oppassen dat je niet vastzit aan een oplossing die niet bij je toekomst past. Meestal betekent het verzekeren van een standaard kwaliteitsniveau en het kunnen aanpassen aan wat er ook kwam.

Zoals we al opmerkten, moet architectuur ook op strategisch niveau werken. Dat betekent dat er waarschijnlijk nieuwe informatie beschikbaar is over toekomstige mogelijkheden die van invloed kunnen zijn op het IT-platform. Soms zijn die strategische veranderingen zelfs vertrouwelijk. In staat zijn om invloed uit te oefenen op sommige beslissingen om spijtbewegingen te vermijden, is soms een moeilijke taak omdat niet-geïnformeerde mensen nooit de echte reden erachter zullen begrijpen.

Op een bepaald moment zaten we midden in de discussie over het verbeteren van de architectuur van het B2C-platform. Het is echt logisch om de architectuur veel te verbeteren. Maar sommigen van ons wisten dat we in gesprek waren om een ​​bedrijf over te nemen dat ons B2C-platform zou vervangen.

Vertrouw me, het is niet altijd gemakkelijk om architect te zijn, maar je moet altijd nadenken over wat het is het beste voor het bedrijf.

En ook …

… We houden ook van tekenen en we zullen het kantoor een stuk cooler maken.

Ontwikkelteam met discussies met behulp van een architectuurdiagram

Ik hoop dat dit bescheiden bericht in de toekomst bijdragen om zon mooie baan te begrijpen.

Migue Coll, hoofd Technology Domain bij Tui Destination Experiences.