Tænk som en arkitekt

🌐 Findes også på 28 sprog

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 1 af 7 i kapitlet Tænk som en dataarkitekt, kapitel 1 i kurset Data Architect. Hvert modul står på egne ben. Forrige: kapiteloversigten · Næste: Datamodellen er skelettet

Spørgsmålet, dette modul besvarer: Hvad er forskellen på at bygge og at lave arkitektur, og hvad laver en arkitekt egentlig?

Det meste af min karriere har jeg været bygger.

Jeg startede som udvikler. Jeg arbejdede i Java og .NET, før jeg gik over til Salesforce, og jeg har brugt mange år på at designe systemer, skrive kode, integrere platforme, undervise arkitekter og gennemgå arkitekturer.

Men en af de vigtigste lektier, jeg har lært undervejs, er, at det at være en dygtig bygger og det at være en dygtig arkitekt ikke altid er det samme.

En bygger spørger:

Hvordan bygger jeg det her?

En arkitekt er nødt til at stille nogle andre spørgsmål:

Skal vi bygge det her?

Hvorfor bygger vi det på denne måde?

Hvilke alternativer er der?

Hvad sker der, når det her bliver større?

Hvad sker der, når det fejler?

Og hvilken beslutning træffer vi i dag, som vi om tre år kommer til at ønske, at vi havde tænkt grundigere over?

Jeg kan huske et projekt for en detailvirksomhed med aftaler. Jeg spurgte: hvor mange aftaler om dagen pr. butik? Så: hvor mange butikker har I? Og hvor mange dage om ugen har I åbent? Jeg indså hurtigt, at vi ville få millioner af aftaler alene det første år. Det er den slags spørgsmål, en arkitekt stiller i starten af et projekt.

Det skifte i tankegangen er det, kurset her i virkeligheden handler om.

Click to enlarge

Personen, der holder tegningen

Jeg har brugt denne sammenligning mange gange, når jeg underviser arkitekter.

Forestil dig en byggeplads. Der er folk, der støber beton, trækker el, lægger rør, rejser vægge og laver snesevis af andre specialiserede opgaver. De skal være rigtig dygtige til det, de laver.

Men nogen skal også holde tegningen.

Den person skal forstå, hvordan alle brikkerne passer sammen. Personen skal opdage, når noget, der sker i én del af projektet, skaber et problem et andet sted.

Det er arkitektur.

Inden for teknologi begår vi nogle gange den fejl at tro, at arkitekten bare er den, der ved mest. Det er ikke rigtig det. Det betyder noget at kende platformen. Du har brug for teknisk dybde. Men arkitektur er ikke en quiz.

Arkitektens job er at træffe gode beslutninger, nogle gange med ufuldstændig information og krav, der trækker i hver sin retning, og at forstå konsekvenserne af de beslutninger.

Det er en helt anden færdighed.

Tag ikke bare imod kravet

En af de første vaner, jeg gerne vil have arkitekter til at udvikle, er enkel:

Spørg hvorfor.

Nogen siger til dig:

Vi har brug for et objekt mere.

Hvorfor?

Vi skal have det her felt kopieret over på kontoen (Account).

Hvorfor?

Vi skal have alle de her data gemt i Salesforce.

Hvorfor?

Det betyder ikke, at du skal være besværlig. Det betyder, at du forstår det egentlige forretningskrav i stedet for straks at implementere den foreslåede løsning.

Et krav kommer ofte forklædt som et design.

»Vi har brug for et nyt brugerdefineret objekt« er ikke nødvendigvis et krav. Kravet kan i virkeligheden være »vi skal kunne registrere de her oplysninger for sig«. Det er ikke det samme.

Når du har forstået det egentlige krav, kan du begynde at undersøge alternativer. Måske er et nyt objekt præcis det rigtige svar. Måske hører oplysningerne hjemme et sted, der allerede findes. Måske skal Salesforce slet ikke eje de data.

Arkitekten skal skille det, forretningen har brug for, fra én foreslået måde at levere det på.

Vi arbejdede på en salgsapplikation, og kunden havde flere godkendelser, hver med en godkender og en dato. Deres første ønske var at tilføje Godkender 2 og Godkender 3, hver med en dato, som felter på salgsmuligheden (Opportunity). Da vi gravede dybere, fandt vi ud af, at der kunne være flere end to eller tre. Så vi flyttede godkendelserne til et underordnet objekt. Ønsket var flere felter; kravet var at registrere hver eneste godkendelse, uanset hvor mange der viste sig at være.

Tænk ud over kravet

To vaner følger af at spørge hvorfor, og hver af dem får sit eget modul senere i kapitlet.

Der er som regel mere end ét svar. Salesforce giver os mange måder at løse et problem på, og nogle af dem er forkerte næsten med det samme. At vælge mellem dem, der virker, er kunsten at afveje (modul 4).

Og de krav, du får, er ikke alle de krav, du har. Ingen siger »sørg for, at det virker, når den natlige indlæsning kun halvt lykkes«, men det er stadig et krav. Jeg ser på ethvert design gennem tre linser: byg til i dag, planlæg for i morgen, planlæg for fejl (modul 5).

Tænk på en, der hyrer en arkitekt til at tegne en bygning. Vedkommende beder ikke om en brandalarm eller et sprinkleranlæg, eller om at bygningen bliver stående under et jordskælv. Det forventes som en del af jobbet, uden at nogen spørger. Vores verden fungerer på samme måde. Ingen beder om pæn fejlhåndtering, om logning eller om en måde at komme på fode igen, når noget fejler. Det er op til arkitekten at vide, hvilke af de systemer der hører hjemme i designet, og at sætte dem ind.

Click to enlarge

Gør din begrundelse synlig

En arkitekt skal ikke bare gå ind i et lokale og meddele: »Det her er det, vi gør.«

Dit job er også at forklare hvorfor. Jeg vil have, at interessenterne forstår de alternativer, vi overvejede, og de afvejninger, der er involveret. Det betyder ikke, at du skal give en direktør et designdokument på 40 sider. Det betyder, at du kan forklare den samme arkitektur for en udvikler, for forretningen og for en direktør: forskellige samtaler om den samme beslutning.

Og måden at gøre det på er med klare tegninger og instruktioner, ligesom personen, der holder tegningen på byggepladsen. For en dataarkitekt er datamodellen en af de vigtigste af de tegninger.

Hvis ingen forstår, hvorfor en beslutning blev truffet, er der en god chance for, at nogen på et tidspunkt laver den om. Og de kan have helt fornuftige grunde til det, for ingen har nogensinde forklaret den oprindelige beslutning.

Arkitekten behøver ikke bygge det hele

Der er et andet skifte, som kan være svært, især for dem, der kommer til arkitektur fra udvikling.

Du behøver ikke selv at bygge det hele.

Jeg kan stadig godt lide at forstå, hvordan tingene virker på et meget teknisk niveau, og det fundament betyder noget. Men som arkitekt bliver dit ansvar større end din egen implementering. Du behøver ikke bygge det hele; du skal vide, hvordan du giver dem, der bygger, den rigtige retning og de rigtige rammer. Det betyder, at du forstår nok til at guide deres arbejde, til at genkende, når en foreslået implementering skaber et arkitektonisk problem, og til at bevæge dig mellem detaljerne og det store billede.

Nogle gange betyder det, at du går i dybden med en forespørgsel, et API eller en datamodel.

Andre gange betyder det, at du træder et skridt tilbage og spørger, om vi overhovedet skal lave noget af det.

Og i stigende grad er det ikke kun mennesker, der bygger. Med AI arbejder arkitekten måske direkte med det værktøj, der genererer objekterne, koden og skærmbillederne. Så går retningen, rammerne og retningslinjerne til AI’en, og at give dem godt bliver mere og mere arkitektens ansvar. Det vender vi tilbage til i modul 7.

Det er en del af rejsen fra bygger til arkitekt.

Dit job er at træffe beslutninger

I sidste ende handler arkitektur om beslutninger.

Nogle beslutninger er nemme at ændre. Andre er ikke.

Et sidelayout kan ændres. En etiket kan omdøbes.

Men vælg den forkerte grundlæggende datamodel, udgiv id’er, som snesevis af systemer begynder at afhænge af, eller placér masterkopien af kritiske data det forkerte sted, og så bliver det meget dyrere at ombestemme sig.

Det er arkitektoniske beslutninger. Og det er præcis den slags beslutninger, kurset her koncentrerer sig om.

Som dataarkitekt kommer du til at træffe beslutninger om, hvordan information er struktureret, hvor den bor, hvordan den vokser, hvordan den bevæger sig, hvem der har adgang til den, og hvordan resten af virksomheden forstår den.

Teknologien betyder noget.

Men målet er ikke at kende alle funktioner i Salesforce.

Målet er at udvikle dømmekraften til at vide, hvilket værktøj du skal bruge, hvornår du skal bruge det, hvad du giver afkald på, og hvad der sker bagefter.

Det er at tænke som en arkitekt.

Og nu kan vi begynde at tænke som en dataarkitekt.

Hvad en arkitekt beslutter her

• Om en anmodning er et egentligt krav eller ét foreslået design for det.
• Hvilke spørgsmål der skal stilles, før noget bygges: skal vi, hvorfor på denne måde, hvad kunne vi ellers gøre, hvad sker der, når det vokser eller fejler.
• Hvilke beslutninger der er arkitektens, og hvilke der tilhører dem, der bygger; og hvilken retning og hvilke rammer byggerne skal have, hvad enten de er mennesker eller AI.
• Hvordan en beslutning forklares, så en udvikler, forretningen og en direktør hver især forstår den.