Tenk som en arkitekt
Finnes også på 28 språk
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 · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 1 av 7 i kapitlet Tenk som en dataarkitekt, kapittel 1 i kurset Data Architect. Hver modul står på egne ben. Forrige: kapitteloversikten · Neste: Datamodellen er skjelettet
Spørsmålet denne modulen besvarer: Hva er forskjellen på å bygge og å arkitekte, og hva gjør en arkitekt egentlig?
Mesteparten av karrieren min har jeg vært en bygger.
Jeg startet som utvikler. Jeg jobbet med Java og .NET før jeg gikk over til Salesforce, og jeg har brukt mange år på å designe systemer, skrive kode, integrere plattformer, undervise arkitekter og gjennomgå arkitekturer.
Men en av de viktigste lærdommene jeg har gjort underveis, er at å være en god bygger og å være en god arkitekt ikke alltid er det samme.
En bygger spør:
Hvordan bygger jeg dette?
En arkitekt må stille andre spørsmål:
Bør vi bygge dette?
Hvorfor bygger vi det på denne måten?
Hvilke alternativer finnes?
Hva skjer når dette blir større?
Hva skjer når det feiler?
Og hvilken beslutning tar vi i dag som vi om tre år kommer til å ønske at vi hadde tenkt grundigere gjennom?
Jeg husker et prosjekt for en detaljhandelsbedrift med timeavtaler. Jeg spurte: hvor mange avtaler per butikk per dag? Så: hvor mange butikker har dere? Og hvor mange dager i uka har dere åpent? Ganske raskt skjønte jeg at vi kom til å ha millioner av avtaler bare det første året. Det er de spørsmålene en arkitekt stiller i starten av et prosjekt.
Den endringen i tankegang er det dette kurset egentlig handler om.
Personen som holder tegningen
Section titled “Personen som holder tegningen ”Jeg har brukt denne analogien mange ganger når jeg underviser arkitekter.
Tenk deg en byggeplass. Der er det folk som støper betong, trekker strøm, legger rør, reiser vegger og gjør dusinvis av andre spesialiserte jobber. De må være veldig gode på det de gjør.
Men noen må også holde tegningen.
Den personen må forstå hvordan alle bitene henger sammen. Personen må legge merke til når noe som skjer i én del av prosjektet, skaper et problem et annet sted.
Det er arkitektur.
I teknologi gjør vi noen ganger den feilen å tro at arkitekten bare er den som vet mest. Det er ikke helt det. Å kunne plattformen er viktig. Du trenger teknisk dybde. Men arkitektur er ingen quiz.
Arkitektens jobb er å ta gode beslutninger, noen ganger med ufullstendig informasjon og krav som trekker i hver sin retning, og forstå konsekvensene av de beslutningene.
Det er en helt annen ferdighet.
Ikke bare ta imot kravet
Section titled “Ikke bare ta imot kravet ”En av de første vanene jeg vil at arkitekter skal utvikle, er enkel:
Spør hvorfor.
Noen sier til deg:
Vi trenger et nytt objekt.
Hvorfor?
Vi trenger at dette feltet kopieres over til kontoen (Account).
Hvorfor?
Vi trenger at alle disse dataene lagres i Salesforce.
Hvorfor?
Det betyr ikke å være vanskelig. Det betyr å forstå det faktiske forretningskravet i stedet for å implementere den foreslåtte løsningen med en gang.
Et krav kommer ofte forkledd som et design.
«Vi trenger et nytt egendefinert objekt» er ikke nødvendigvis et krav. Kravet kan egentlig være «vi må kunne følge med på denne informasjonen for seg». Det er ikke det samme.
Når du forstår det egentlige kravet, kan du begynne å utforske alternativer. Kanskje er et nytt objekt akkurat det rette svaret. Kanskje hører informasjonen hjemme et sted som allerede finnes. Kanskje bør ikke Salesforce eie de dataene i det hele tatt.
Arkitekten må skille det virksomheten trenger fra én foreslått måte å levere det på.
Vi jobbet med en salgsapplikasjon, og kunden hadde flere godkjenninger, hver med en godkjenner og en dato. Det første de ba om, var å legge til Godkjenner 2 og Godkjenner 3, hver med en dato, som felt på salgsmuligheten (Opportunity). Da vi gravde dypere, skjønte vi at det kunne bli flere enn to eller tre. Så vi flyttet godkjenningene til et underordnet objekt. Ønsket var flere felt; kravet var å følge med på hver eneste godkjenning, uansett hvor mange det ble.
Tenk lenger enn kravet
Section titled “Tenk lenger enn kravet ”To vaner følger av å spørre hvorfor, og hver av dem får sin egen modul senere i kapitlet.
Det finnes som regel mer enn ett svar. Salesforce gir oss mange måter å løse et problem på, og noen av dem er feil nesten med en gang. Å velge mellom dem som fungerer, er kunsten å avveie (modul 4).
Og kravene du får, er ikke alle kravene du har. Ingen sier «sørg for at dette fungerer når den nattlige innlastingen bare lykkes halvveis», men det er likevel et krav. Jeg ser på hvert design gjennom tre linser: bygg for i dag, planlegg for i morgen, planlegg for feil (modul 5).
Tenk på noen som hyrer en arkitekt for å tegne et bygg. De ber ikke om brannalarm eller sprinkleranlegg, eller om at bygget skal tåle et jordskjelv. Det forventer de som en del av jobben, uten å be om det. Vår verden fungerer på samme måte. Ingen ber om god feilhåndtering, om logger eller om en måte å komme seg på beina igjen når noe feiler. Det er arkitektens jobb å vite hvilke av de systemene som hører hjemme i designet, og å legge dem inn.
Gjør resonnementet ditt synlig
Section titled “Gjør resonnementet ditt synlig ”En arkitekt bør ikke bare gå inn i et rom og kunngjøre: «Det er dette vi gjør.»
Jobben din er også å forklare hvorfor. Jeg vil at interessentene skal forstå alternativene vi vurderte og avveiningene det innebærer. Det betyr ikke å gi en leder et designdokument på 40 sider. Det betyr å kunne forklare den samme arkitekturen for en utvikler, for virksomheten og for en leder: ulike samtaler om den samme beslutningen.
Og måten å gjøre det på er med tydelige tegninger og instruksjoner, som personen som holder tegningen på byggeplassen. For en dataarkitekt er datamodellen en av de viktigste av disse tegningene.
Hvis ingen forstår hvorfor en beslutning ble tatt, er det stor sjanse for at noen etter hvert reverserer den. Og de kan ha helt fornuftige grunner til det, fordi ingen noen gang forklarte den opprinnelige beslutningen.
Arkitekten trenger ikke å bygge alt
Section titled “Arkitekten trenger ikke å bygge alt ”Det finnes en annen overgang som kan være vanskelig, særlig for dem som kommer inn i arkitektur fra utvikling.
Du trenger ikke å bygge alt selv.
Jeg liker fortsatt å forstå hvordan ting fungerer på et veldig teknisk nivå, og det grunnlaget betyr noe. Men som arkitekt blir ansvaret ditt større enn din egen implementering. Du trenger ikke å bygge alt; du må vite hvordan du gir dem som faktisk bygger, riktig retning og riktige rammer. Det betyr å forstå nok til å veilede arbeidet deres, til å se når en foreslått implementering skaper et arkitektonisk problem, og til å bevege deg mellom detaljene og det store bildet.
Noen ganger betyr det å gå i dybden på en spørring, et API eller en datamodell.
Noen ganger betyr det å ta et skritt tilbake og spørre om vi i det hele tatt bør gjøre noe av det.
Og i stadig større grad er det ikke bare mennesker som bygger. Med KI kan arkitekten jobbe direkte med verktøyet som genererer objektene, koden og skjermbildene. Da går retningen, rammene og retningslinjene til KI-en, og å gi dem godt blir i stadig større grad arkitektens ansvar. Vi kommer tilbake til det i modul 7.
Det er en del av reisen fra bygger til arkitekt.
Jobben din er å ta beslutninger
Section titled “Jobben din er å ta beslutninger ”Til syvende og sist handler arkitektur om beslutninger.
Noen beslutninger er enkle å endre. Andre er det ikke.
Et sideoppsett kan endres. En etikett kan få nytt navn.
Men velg feil grunnleggende datamodell, publiser identifikatorer som dusinvis av systemer begynner å være avhengige av, eller legg hovedkopien av kritiske data på feil sted, og da blir det mye dyrere å ombestemme seg.
Det er arkitektoniske beslutninger. Og det er akkurat den typen beslutninger dette kurset konsentrerer seg om.
Som dataarkitekt kommer du til å ta beslutninger om hvordan informasjon struktureres, hvor den bor, hvordan den vokser, hvordan den flyttes, hvem som har tilgang til den, og hvordan resten av virksomheten forstår den.
Teknologien betyr noe.
Men å kunne hver eneste funksjon i Salesforce er ikke målet.
Målet er å utvikle skjønnet til å vite hvilket verktøy du skal bruke, når du skal bruke det, hva du gir avkall på, og hva som skjer etterpå.
Det er å tenke som en arkitekt.
Og nå kan vi begynne å tenke som en dataarkitekt.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Om en forespørsel er et reelt krav, eller ett foreslått design for det.
- Hvilke spørsmål du skal stille før noe bygges: bør vi, hvorfor på denne måten, hva annet kan vi gjøre, hva skjer når det vokser eller feiler.
- Hvilke beslutninger som er arkitektens, og hvilke som tilhører dem som bygger; og hvilken retning og hvilke rammer byggerne skal få, enten det er mennesker eller KI.
- Hvordan du forklarer en beslutning slik at en utvikler, virksomheten og en leder hver for seg forstår den.