IT-arkitektur betyder noget. Lad mig fortælle dig hvorfor

Vi elsker at tegne !!

(Miguel Angel Coll) (2. jul 2020)

Jeg investerede de sidste 5 år på min karriere, der arbejdede omkring it-arkitekturfunktionen. I alle disse år var jeg nødt til at retfærdiggøre den blotte eksistens af arkitekturfunktion selv for mig selv. Nogle gange føler jeg også, at vi var ubudne gæster omgivet af de mennesker, der virkelig gør jobbet (Udviklere og sys-ops).

Efter 5 år er jeg stadig overbevist om, at arkitektur betyder noget, lad mig give dig nogle argumenter til bevis det.

Bedste værdi for pengene

Hvis jeg kun skal vælge en mission til it-arkitektur, vælger jeg denne. IT-afdelinger og platforme vokser typisk bare. Nogle af dem fordi virksomheden vokser, andre fordi virksomheden er midt i en digital transformation. Under alle omstændigheder er resultatet det samme, år over år har du flere systemer, flere teams, mere kompleksitet.

Jeg kan godt lide at hyper-over-forenkle en IT-platform som følger:

Hovedarkitekturfunktionen er at bevare forholdet til IT-platformens omkostninger og den værdi, de leverer i god form.

For et stykke tid siden arbejdede jeg i et rejsefirma med en forretningsmodel baseret på online produktdistribution gennem APIer. Disse APIer var stærkt koblet med et kæmpe monolit-system baseret på Oracle Exadata. Det betyder, at hver gang vi vokser med API-trafik (og trafikken voksede mere end konverteringsfrekvensen), skal vi lodrette skalaen af ​​vores database.

Arkitektur driver IT-platformens effektivitet

Arkitekturforslaget på det tidspunkt var at afkoble API-tjenester, der skabte et nyt mikrotjenestelag på skyen til at håndtere al trafik med lavere omkostninger, mens databasens infrastruktur kun holdes til reservation og drift (som desværre ikke vokser eksponentielt). Resultatet var, at der ikke længere var behov for ny infrastruktur til DB de følgende år og et bedre forhold mellem trafik og it-omkostninger.

Brug det samme sprog

Bare rolig, jeg er ikke taler om programmeringssprog (java, python osv.). Som arkitekt er jeg mere end åben for mangfoldighed med en vis kontrol (ikke kaos). Her henviser jeg til Conceptual Integrity udtryk, som jeg læste første gang på Mythical Man Month og andre essays om software engineering fra Frederick P Brooks Jr.

I bogen forklarer Fred Brooks, hvordan it-teams vokser, og hvordan den voksende indvirkning på deres produktivitet. For Fred er kommunikationen mellem teams et af de største problemer, du skal tackle, når du prøver at skalere et IT-team. For at parallelisere opgaver har du brug for hold til at være så uafhængige som muligt. Men så snart alle holdene arbejder på en sammenkoblet platform, har vi brug for kommunikation mellem holdene. Er det i disse scenarier, når det at have et fælles sprog er nøglen til succes.

Jeg kan stadig huske endeløse samtaler med mine tidligere holdkammerater, der diskuterede om, hvad der er et system, en teknologikomponent, en grænseflade eller en byggesten. Hvis du arbejder i en stor IT-afdeling, ved du sandsynligvis, hvor frustrerende det er, at ting navngives forskelligt af teams. Nogle gange er det endog værst, når de bruger det samme navn til forskellige ting.

Et almindeligt eksempel på den sidste er at navngive en monolit-applikation med kun ét navn. Selv det giver mening (da det er en monolit), når du vil bryde den monolit, har du brug for flere detaljer. Introduktion af forskellige navne til databasen, frontend, datamodel osv. Hjælper med processen.

Selv om du er i en lille IT-afdeling eller en større, er det altid et godt tidspunkt at starte med en navngivningskonvention, et service / system / løsningskatalog osv. Du ved aldrig, hvor stor du bliver i fremtiden.

Om konceptuel integritet, bare med mig, jo hurtigere jo bedre.

Tving designsamtaler

Efter min mening starter enhver løsning på et problem altid med en analyse af situationen og designet af løsningen inden implementering. Virkeligheden for et udviklingsteam er, at vi hver uge har nye problemer på bordet at løse. Efter nogle måneder med Business as Usual-rutiner begynder holdene at køre på autopilot og finder bare løsninger på problemer uden for meget at tænke på mellem- og langsigtede implikationer.

At have arkitekturfunktion integreret i udviklingsteamene hjælper altid om at øge designsamtalerne for at finde de bedste løsninger på de problemer, vi står overfor.

Jeg vil også gerne udfordre den gamle modeudviklingsproces, hvor designet ses som noget, der skal gøres lige i starten af ​​en projekt.I artiklen The Architect Elevator – Besøg de øverste etager , Gregor Hohpe beskriver min forståelse af Arkitektur-rollen perfekt:

“… Så i stedet for at overlade alle afgørende beslutninger til en person, kan projektrisikoen reduceres med minimering af antallet af beslutninger, der er irreversible .”

Arkitektur skal være der under hele udviklingsprocessen . Faktisk, hvis du arbejder på Agile, vil du tage beslutninger om hver iteration.

Strategidiskussioner

Som IT-fyr vil jeg elske at være i selskabsstyrelsen med meget specifikke og detaljerede tekniske diskussioner. Virkeligheden for mellemstore og store virksomheder er, at bestyrelsesmedlemmer ikke har råd til at gå for dybt i detaljerne. Men skal virksomhedsstyrelsen træffe beslutninger om strategi uden at forstå it-situationen?

I den nuværende verden er der kun få virksomheder, der kan sige, at it ikke er i centrum for deres strategi. Hvem er så ansvarlig for at oversætte strategien til IT og omvendt? – du kender allerede svaret.

Et af vores største bidrag i TUI Destination Experiences-arkitekturteamet var at tegne en Target Architecture Model. TAM tillader ikke-it-folk at forstå vores vigtigste løsninger og systemer, og hvordan de er forbundet med vores virksomheds værdistrømme. Efter distributionen af ​​TAM startede de fleste af vores strategisamtaler med at se, hvordan vores arkitektur ser ud, og hvordan vi skal tilpasse os en ny situation.

Men pas på, en målarkitekturmodel er ikke beregnet til at være en statisk billede af “som det er” og “at være” -arkitekturen. At prøve at udføre den slags øvelse vil ende med noget kortvarigt, der bare passer til et specifikt projekt. Efter min mening er det bedre at fokusere på at tegne hovedkomponenterne i din arkitektur og vælge de ting, du vil bevare (fordi de er kernen i din virksomhed) og pege på ting, som du bliver nødt til at ændre eller udvikle.

Første dias i TAM-præsentationen

Husk altid, hvad Dee Hock, Visa-grundlægger sagde:

Enkle, klare formål og principper giver anledning til kompleks intelligent adfærd. Komplekse regler og forskrifter giver anledning til simpel dum opførsel.

Til uendeligt og udover

Besættelsen for at være smidig forvandler undertiden it-teams til en kortsigtet beslutningstager . Som vi allerede har diskuteret, skal vi være sikre på, at de beslutninger, vi tager i dag, er fremtidssikrede. Nogle gange betyder det at have et klart overblik over strategien på lang sigt. Nogle gange betyder det at være forsigtig med ikke at være låst i en løsning, der ikke passer til din fremtid. De fleste gange betyder det at sikre et standardkvalitetsniveau og være i stand til at tilpasse sig det, der kom.

Som vi allerede har kommenteret, skal arkitektur også arbejde på et strategisk niveau. Det betyder, at der sandsynligvis vil have nye oplysninger om fremtidige muligheder, der kan påvirke IT-platformen. Nogle gange er disse strategiske ændringer endda fortrolige. At være i stand til at påvirke nogle beslutninger, der forsøger at undgå fortrydelsesbevægelser, er undertiden en vanskelig opgave, fordi ikke-informerede mennesker aldrig vil forstå den virkelige årsag.

På et eller andet tidspunkt var vi midt i diskussion om forbedring af B2C-platformens arkitektur. Det giver virkelig mening at forbedre arkitekturen meget. Men nogle af os vidste, at vi var i samtaler for at erhverve en virksomhed, der ville erstatte vores B2C-platform.

Tro mig, det er ikke altid let at være arkitekt, men du skal altid tænke på, hvad der er bedst for virksomheden.

Og også…

… Vi elsker også at tegne, og vi vil gøre kontoret meget mere sejt.

Udviklingsteam, der har diskussioner ved hjælp af et arkitekturdiagram

Håber dette beskedne indlæg bidrage i fremtiden til at forstå et så smukt job.

Migue Coll, leder af teknologidomæne ved Tui Destination Experiences.