IT-arkitektur betyder något. Låt mig berätta varför

Vi älskar att rita !!

(Miguel Angel Coll) (2 jul 2020)

Jag investerade de senaste 5 åren på min karriär som arbetar med IT-arkitekturfunktion. Under alla dessa år var jag tvungen att rättfärdiga enbart existensen av arkitekturfunktion även för mig själv. Ibland känns det också som om vi var inkräktare omgivna av människor som verkligen gör jobbet (utvecklare och sys-ops).

Efter fem år är jag fortfarande övertygad om att arkitektur spelar roll, låt mig ge er några argument till bevisa det.

Bästa valuta för pengarna

Om jag bara behöver välja ett uppdrag för IT-arkitektur väljer jag det här. IT-avdelningar och plattformar växer vanligtvis bara. Några av dem för att företaget växer, andra för att företaget befinner sig mitt i en digital omvandling. Hur som helst är resultatet detsamma, år efter år har du fler system, fler team, mer komplexitet.

Jag gillar att hyper-över-förenkla en IT-plattform enligt följande:

Huvudarkitekturfunktionen är att behålla förhållandet till IT-plattformskostnad och värdet den levererar i god form.

För ett tag sedan arbetade jag i ett reseföretag med en affärsmodell baserad på online produktdistribution via API: er. Dessa API: er kopplades starkt till ett enormt monolitsystem baserat på Oracle Exadata. Det betyder att varje gång vi växer på API-trafik (och trafiken växte mer än omvandlingsfrekvensen) måste vi skala vår databas vertikalt.

Arkitektur driver IT-plattformens effektivitet

Arkitekturförslaget vid den tiden var att koppla från API-tjänster och skapa ett nytt mikrotjänstlager på molnet för att hantera all trafik till lägre kostnader samtidigt som databasinfrastrukturen behålls bara för bokning och drift (som tyvärr inte växer exponentiellt). Resultatet var att ingen ny infrastruktur behövdes för DB de följande åren och ett bättre samband mellan trafik och IT-kostnader.

Använd samma språk

Oroa dig inte jag är inte prata om programmeringsspråk (java, python, etc). Som arkitekt är jag mer än öppen för mångfald med viss kontroll (inte kaos). Här hänvisar jag till Conceptual Integrity, term som jag läste första gången på Mythical Man Month och andra uppsatser om programvaruteknik från Frederick P Brooks Jr.

I boken förklarar Fred Brooks hur IT-team växer och hur den växande inverkan på deras produktivitet. För Fred är kommunikationen mellan team ett av de största problemen att ta itu med när du försöker skala ett IT-team. För att parallellisera uppgifter behöver du team vara så oberoende som möjligt. Men så snart alla team arbetar på en sammankopplad plattform behöver vi lite kommunikation mellan team. Finns det i dessa scenarier när ett gemensamt språk är nyckeln till framgång.

Jag minns fortfarande oändliga samtal med mina tidigare lagkamrater som diskuterar om vad som är ett system, en teknikkomponent, ett gränssnitt eller en byggsten. Om du arbetar på en stor IT-avdelning vet du förmodligen hur frustrerande det är att sakerna heter olika av team. Ibland är till och med värst när de använder samma namn för olika saker.

Ett vanligt exempel på den sista är att namnge en monolitapplikation med bara ett namn. Även det är vettigt (eftersom det är en monolit), när du vill bryta den monoliten behöver du mer detaljer. Introduktion av olika namn för databasen, frontend, datamodell etc. hjälper till med processen.

Även om du befinner dig i en liten IT-avdelning eller en större, är det alltid en bra tid att börja med en namngivning, en katalog för tjänster / system / lösningar etc. Du vet aldrig hur stor du kommer att bli i framtiden.

Om konceptuell integritet, ju mer desto bättre desto bättre.

Tvinga designkonversationer

I mina tankar börjar varje lösning på ett problem alltid med en analys av situationen och utformningen av lösningen innan den implementeras. Verkligheten för ett utvecklingsteam är att vi varje vecka har nya problem på bordet att lösa. Efter några månaders Business as Usual-rutiner börjar lagen köras på autopilot och hittar bara lösningar på problem utan att tänka på konsekvenserna på medellång och lång sikt.

Att ha en integrerad arkitekturfunktion i utvecklingsgruppen hjälper alltid om att öka designkonversationerna för att hitta de bästa lösningarna på problemen vi möter.

Jag vill också utmana den gamla modeprocessen där designen ses som något som ska göras precis i början av projekt.I artikeln The Architect Elevator – Besöker de övre våningarna , Gregor Hohpe beskriver min förståelse för arkitekturrollen perfekt:

“… Så istället för att anförtro alla viktiga beslut till en person kan projektrisken minskas med Minimera antalet beslut som är irreversibla .”

Arkitektur måste finnas där i hela utvecklingsprocessen . Om du arbetar med Agile kommer du att fatta beslut om varje iteration.

Strategidiskussioner

Som IT-kille kommer jag att älska att vara i styrelsen med mycket specifika och detaljerade tekniska diskussioner. Verkligheten för medelstora och stora företag är att styrelseledamöter inte har råd att gå för djupt in i detaljerna. Men ska företagets styrelse fatta beslut om strategi utan att förstå IT-situationen?

I den nuvarande världen finns det bara ett fåtal företag som kan säga att IT inte är i centrum för deras strategi. Vem är då ansvarig för att översätta strategin till IT och vice versa? – du vet redan svaret.

Ett av våra största bidrag i TUI Destination Experiences-arkitekturteamet var att rita en Target Architecture Model. TAM tillåter icke-IT-personer att förstå våra huvudlösningar och system och hur de är kopplade till våra företags värdeströmmar. Efter att ha distribuerat TAM började de flesta av våra strategikonversationer med att se hur vår arkitektur ser ut och hur vi ska anpassa oss till en ny situation.

Men var försiktig, en målarkitekturmodell är inte tänkt att vara en statisk bild av arkitekturen ”som den är” och ”att vara”. Att försöka göra den här typen av övning kommer att sluta med något kortvarigt som bara passar för ett specifikt projekt. Enligt min mening är det bättre att fokusera på att rita huvudkomponenterna i din arkitektur och välja de saker du vill bevara (eftersom de är kärnan i ditt företag) och peka på saker som du kommer att behöva ändra eller utveckla.

Första bilden i TAM-presentationen

Kom alltid ihåg vad Dee Hock, Visa Founder sa:

Enkla, tydliga syften och principer ger upphov till komplexa intelligenta beteenden. Komplexa regler och förordningar ger upphov till enkelt dumt beteende.

Till oändligheten och bortom

Besattheten för att vara smidig förvandlar ibland IT-team till kortsiktiga beslutsfattare . Som vi redan har diskuterat måste vi vara säkra på att de beslut vi fattar idag är framtidssäkra. Ibland betyder det att ha en tydlig syn på strategin på lång sikt. Ibland betyder det att vara försiktig med att inte låsa fast en lösning som inte passar din framtid. För det mesta innebär det att säkerställa en standardnivå för kvalitet och att kunna anpassa sig till vad som kom.

Som vi redan kommenterade måste arkitektur också arbeta på en strategisk nivå. Det betyder att det förmodligen kommer att ha ny information om framtida möjligheter som kan påverka IT-plattformen. Ibland är dessa strategiska förändringar till och med konfidentiella. Att kunna påverka vissa beslut som försöker undvika ångerrörelser är ibland en svår uppgift eftersom okunniga människor aldrig förstår den verkliga orsaken bakom.

Vid någon tidpunkt var vi mitt i diskussion om förbättring av B2C-plattformens arkitektur. Det är verkligen meningsfullt att förbättra arkitekturen mycket. Men några av oss visste att vi var i konversationer för att förvärva ett företag som kommer att ersätta vår B2C-plattform.

Lita på mig, det är inte alltid lätt att vara arkitekt, men du måste alltid tänka på vad som är bäst för företaget.

Och också …

… Vi älskar också att rita och vi kommer att göra kontoret mycket coolare.

Utvecklingsteam som har diskussioner med hjälp av ett arkitekturdiagram

Hoppas det här blygsamma inlägget bidra i framtiden för att förstå ett så vackert jobb.

Migue Coll, chef för teknikdomän vid Tui Destination Experiences.