IT-arkitektur betyr noe. La meg fortelle deg hvorfor

Vi elsker å tegne !!

(Miguel Angel Coll) (2. jul 2020)

Jeg investerte de siste 5 årene på karrieren min med å jobbe rundt IT Architecture-funksjonen. I alle disse årene måtte jeg rettferdiggjøre den eneste eksistensen av arkitekturfunksjon til og med for meg selv. Noen ganger føler jeg også at vi var inntrengere omgitt av menneskene som virkelig gjør jobben (utviklere og sys-ops).

Etter 5 år er jeg fortsatt overbevist om at arkitektur er viktig, la meg gi deg noen argumenter for bevis det.

Beste valuta for pengene

Hvis jeg bare må velge ett oppdrag for IT-arkitektur, vil jeg velge dette. IT-avdelinger og plattformer vokser vanligvis bare. Noen av dem fordi selskapet vokser, andre fordi selskapet er midt i en digital transformasjon. Uansett er resultatet det samme, år over år har du flere systemer, flere team, mer kompleksitet.

Jeg liker å hyperforenkle en IT-plattform som følger:

Hovedarkitekturfunksjonen er å beholde forholdet til IT-plattformskostnad og verdien den leverer i god form.

For en stund siden jobbet jeg i et reiseselskap med en forretningsmodell basert på online produktdistribusjon gjennom API-er. Disse API-ene var sterkt kombinert med et stort monolit-system basert på Oracle Exadata. Det betyr at hver gang vi vokser på API-trafikk (og trafikken vokste mer enn konverteringsfrekvensen), må vi vertikal skalere databasen vår.

Arkitektur driver effektiviteten av IT-plattformen

Arkitekturforslaget på den tiden var å frakoble API-tjenester og skape et nytt mikrotjenestelag på skyen for å håndtere all trafikken med lavere kostnader, mens databasens infrastruktur holdes bare for bestilling og drift (som dessverre ikke vokser eksponentielt). Resultatet var ikke mer ny infrastruktur som var nødvendig for DB de neste årene, og et bedre forhold mellom trafikk og IT-kostnader.

Bruk samme språk

Ikke bekymre deg, jeg er ikke snakker om programmeringsspråk (java, python osv.). Som arkitekt er jeg mer enn åpen for mangfold med litt kontroll (ikke kaos). Her refererer jeg til Conceptual Integrity, begrep som jeg leste første gang på Mythical Man Month og Other Essays on Software Engineering fra Frederick P Brooks Jr.

I boken forklarer Fred Brooks hvordan IT-team vokser og hvordan den økende innvirkningen på produktiviteten deres. For Fred er kommunikasjonen mellom teamene et av de største problemene du skal takle når du prøver å skalere et IT-team. For å parallellisere oppgaver trenger du team for å være så uavhengige som mulig. Men så snart alle lagene jobber på en sammenkoblet plattform, trenger vi litt kommunikasjon mellom teamene. Er det i disse scenariene når det å ha et felles språk er nøkkelen til suksess.

Jeg husker fortsatt endeløse samtaler med mine tidligere lagkamerater som diskuterte om hva som er et system, en teknologikomponent, et grensesnitt eller en byggestein. Hvis du jobber på en stor IT-avdeling, vet du sannsynligvis hvor frustrerende det er at ting blir navngitt annerledes av team. Noen ganger er det til og med verst når de bruker samme navn til forskjellige ting.

Et vanlig eksempel på den siste er å navngi en monolit-applikasjon med bare ett navn. Selv det er fornuftig (da det er en monolit), når du vil bryte den monolitten, trenger du mer detaljer. Å introdusere forskjellige navn på databasen, frontend, datamodell osv. Vil hjelpe på prosessen.

Selv om du er i en liten IT-avdeling eller en større, er det alltid en god tid å starte med en navngivningskonvensjon, en tjeneste / system / løsningskatalog osv. Du vet aldri hvor stor du vil bli i fremtiden.

Om konseptuell integritet, bare med meg, jo raskere jo bedre.

Tving designsamtaler

I mine tanker starter alltid en løsning på et problem med en analyse av situasjonen og utformingen av løsningen før implementering. Virkeligheten for et utviklingsteam er at vi hver uke har nye problemer på bordet å løse. Etter noen måneder med Business as Usual-rutiner, begynner teamene å kjøre på autopilot og bare finne løsninger på problemer uten for mye å tenke på implikasjoner på mellomlang og lang sikt.

Å ha arkitekturfunksjon integrert i utviklingsteamene hjelper alltid om å øke designsamtalene for å finne de beste løsningene på problemene vi står overfor.

Jeg liker også å utfordre den gamle moteutviklingsprosessen der design blir sett på som noe som skal gjøres bare i begynnelsen av en prosjekt.I artikkelen The Architect Elevator – Visiting the upper floors , Gregor Hohpe beskriver min forståelse av arkitekturrollen perfekt:

“… Så i stedet for å overlate alle viktige avgjørelser til en person, kan prosjektrisikoen reduseres med minimering av antall beslutninger som er irreversible .”

Arkitektur må være der i hele utviklingsprosessen . Faktisk, hvis du jobber med Agile, vil du ta avgjørelser for hver iterasjon.

Strategidiskusjoner

Som IT-fyr vil jeg elske å være i selskapets styre med veldig spesifikke og detaljerte tekniske diskusjoner. Virkeligheten for mellomstore og store selskaper er at styremedlemmene ikke har råd til å gå for dypt inn i detaljene. Men burde selskapets styre ta beslutninger om strategi uten å forstå IT-situasjonen?

I den nåværende verden er det bare noen få selskaper som kan si at IT ikke er i sentrum av deres strategi. Hvem er så ansvarlig for å oversette strategien til IT og omvendt? – du vet allerede svaret.

Et av våre største bidrag i TUI Destination Experiences arkitekturteam var å tegne en Target Architecture Model. TAM lar ikke IT-folk forstå våre hovedløsninger og systemer og hvordan de er koblet til selskapets verdistrømmer. Etter distribusjon av TAM startet de fleste av strategisamtalene våre med å se hvordan arkitekturen vår ser ut og hvordan vi skal tilpasse oss en ny situasjon.

Men vær forsiktig, en målarkitekturmodell er ikke ment å være en statisk bilde av arkitekturen “som den er” og “å være”. Å prøve å gjøre den slags øvelse vil ende opp med noe kortvarig som bare passer for et bestemt prosjekt. Etter min mening er det bedre å fokusere på å tegne hovedkomponentene i arkitekturen din og velge de tingene du vil bevare (fordi de er kjernen i virksomheten din) og peke på ting du trenger for å endre eller utvikle seg.

Første lysbilde av TAM-presentasjonen

Husk alltid hva Dee Hock, Visa Founder sa:

Enkle, klare formål og prinsipper gir anledning til kompleks intelligent oppførsel. Komplekse regler og forskrifter gir grunn til enkel dum oppførsel.

Til uendelig og utenfor

Besettelsen for å være smidig forvandler noen ganger IT-teamene til kortsiktige beslutningstakere . Som vi allerede har diskutert, må vi være sikre på at beslutningene vi tar i dag er fremtidssikre. Noen ganger betyr det å ha et klart syn på strategien på lang sikt. Noen ganger betyr det å være forsiktig med å ikke være låst i en løsning som ikke passer din fremtid. For det meste betyr det å sikre et standard kvalitetsnivå og kunne tilpasse seg det som kom.

Som vi allerede har kommentert, må arkitektur også jobbe på et strategisk nivå. Det betyr at sannsynligvis vil ha fersk informasjon om fremtidige muligheter som kan påvirke IT-plattformen. Noen ganger er disse strategiske endringene til og med konfidensielle. Å være i stand til å påvirke noen avgjørelser som prøver å unngå angrende bevegelser er noen ganger en vanskelig oppgave fordi ikke-informerte mennesker aldri vil forstå den virkelige grunnen bak.

På et eller annet tidspunkt var vi midt i diskusjon om å forbedre arkitekturen til B2C-plattformen. Det er virkelig fornuftig å forbedre arkitekturen mye. Men noen av oss visste at vi var i samtaler for å skaffe oss et selskap som skal erstatte B2C-plattformen vår.

Stol på meg, det er ikke alltid lett å være arkitekt, men du må alltid tenke på hva som er best for selskapet.

Og også…

… Vi elsker også å tegne, og vi vil gjøre kontoret mye mer kult.

Utviklingsteam som har diskusjoner ved hjelp av et arkitekturdiagram

Håper dette beskjedne innlegget bidra i fremtiden til å forstå en så vakker jobb.

Migue Coll, Head of Technology Domain at Tui Destination Experiences.