Tänk som en arkitekt
Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 1 av 7 i kapitlet Tänk som en dataarkitekt, kapitel 1 i kursen Data Architect. Varje modul står på egna ben. Föregående: kapitelöversikten · Nästa: Datamodellen är skelettet
Frågan den här modulen besvarar: Vad är skillnaden mellan att bygga och att arkitekta, och vad gör en arkitekt egentligen?
Under större delen av min karriär har jag varit en byggare.
Jag började som utvecklare. Jag arbetade med Java och .NET innan jag gick över till Salesforce, och jag har ägnat år åt att designa system, skriva kod, integrera plattformar, undervisa arkitekter och granska arkitekturer.
Men en av de viktigaste lärdomarna jag har fått på vägen är att att vara en riktigt bra byggare och att vara en riktigt bra arkitekt inte alltid är samma sak.
En byggare frågar:
Hur bygger jag det här?
En arkitekt måste ställa en annan uppsättning frågor:
Borde vi bygga det här?
Varför bygger vi det på det här sättet?
Vilka är alternativen?
Vad händer när det här blir större?
Vad händer när det går sönder?
Och vilket beslut fattar vi i dag som vi om tre år kommer att önska att vi hade tänkt igenom bättre?
Jag minns ett projekt för en detaljhandelsverksamhet med bokade besök. Jag frågade: hur många besök per dag och butik? Sedan: hur många butiker har ni? Och hur många dagar i veckan har ni öppet? Ganska snabbt insåg jag att vi skulle få miljontals besök bara under det första året. Det är de frågorna en arkitekt ställer i början av ett projekt.
Det skiftet i tänkandet är vad den här kursen egentligen handlar om.
Personen som håller i ritningen
Section titled “Personen som håller i ritningen ”Jag har använt den här liknelsen många gånger när jag undervisar arkitekter.
Tänk dig en byggarbetsplats. Där finns folk som gjuter betong, drar el, installerar rör, reser väggar och gör dussintals andra specialiserade jobb. De måste vara väldigt bra på det de gör.
Men någon måste också hålla i ritningen.
Den personen måste förstå hur alla delarna passar ihop. Den måste märka när något som händer i en del av projektet skapar ett problem någon annanstans.
Det är arkitektur.
Inom tekniken gör vi ibland misstaget att tro att arkitekten helt enkelt är den som kan mest. Det är inte riktigt det. Att kunna plattformen spelar roll. Du behöver teknisk djup. Men arkitektur är ingen frågesport.
Arkitektens jobb är att fatta bra beslut, ibland med ofullständig information och krav som drar åt olika håll, och att förstå konsekvenserna av de besluten.
Det är en helt annan färdighet.
Ta inte bara emot kravet
Section titled “Ta inte bara emot kravet ”En av de första vanorna jag vill att arkitekter ska utveckla är enkel:
Fråga varför.
Någon säger till dig:
Vi behöver ett objekt till.
Varför?
Vi behöver det här fältet kopierat till kontot (Account).
Varför?
Vi behöver alla de här data lagrade i Salesforce.
Varför?
Det betyder inte att du ska vara besvärlig. Det betyder att du förstår det faktiska affärskravet i stället för att direkt implementera den föreslagna lösningen.
Ett krav kommer ofta förklätt till en design.
”Vi behöver ett nytt anpassat objekt” är inte nödvändigtvis ett krav. Kravet kanske egentligen är ”vi behöver följa den här informationen separat”. Det är inte samma sak.
När du väl förstår det verkliga kravet kan du börja utforska alternativ. Kanske är ett nytt objekt precis rätt svar. Kanske hör informationen hemma någonstans som redan finns. Kanske borde Salesforce inte äga de data alls.
Arkitekten måste skilja det verksamheten behöver från ett föreslaget sätt att leverera det.
Vi arbetade med en säljapplikation, och kunden hade flera godkännanden, vart och ett med en godkännare och ett datum. Deras första önskemål var att lägga till Godkännare 2 och Godkännare 3, var och en med ett datum, som fält på affärsmöjligheten (Opportunity). När vi grävde djupare insåg vi att det kunde bli fler än två eller tre. Så vi flyttade godkännandena till ett underordnat objekt. Önskemålet var fler fält; kravet var att följa varje godkännande, hur många det än visade sig bli.
Tänk bortom kravet
Section titled “Tänk bortom kravet ”Två vanor följer av att fråga varför, och var och en får en egen modul längre fram i det här kapitlet.
Det finns oftast mer än ett svar. Salesforce ger oss många sätt att lösa ett problem, och en del av dem är fel nästan direkt. Att välja mellan dem som fungerar är konsten att göra avvägningar (modul 4).
Och kraven du får är inte alla krav du har. Ingen säger ”se till att det här fungerar när nattens laddning bara lyckas till hälften”, men det är ändå ett krav. Jag ser på varje design genom tre linser, bygg för i dag, planera för i morgon, planera för fel (modul 5).
Tänk på någon som anlitar en arkitekt för att rita en byggnad. De ber inte om ett brandlarm eller ett sprinklersystem, eller om att byggnaden ska stå kvar vid en jordbävning. De förväntar sig det som en del av jobbet, utan att be om det. Vår värld fungerar på samma sätt. Ingen ber om smidig felhantering, om loggar eller om ett sätt att återhämta sig när något går fel. Det är arkitektens sak att veta vilka av de systemen som hör hemma i designen, och att lägga in dem.
Gör ditt resonemang synligt
Section titled “Gör ditt resonemang synligt ”En arkitekt ska inte bara kliva in i ett rum och meddela: ”Så här gör vi.”
Ditt jobb är också att förklara varför. Jag vill att intressenterna förstår vilka alternativ vi övervägde och vilka avvägningar som ingår. Det betyder inte att ge en chef ett designdokument på 40 sidor. Det betyder att kunna förklara samma arkitektur för en utvecklare, för verksamheten och för en chef: olika samtal om samma beslut.
Och sättet att göra det är med tydliga ritningar och instruktioner, som personen som håller i ritningen på byggarbetsplatsen. För en dataarkitekt är datamodellen en av de viktigaste av de ritningarna.
Om ingen förstår varför ett beslut fattades är chansen stor att någon till slut gör om det. Och de kan ha helt rimliga skäl för det, eftersom ingen någonsin förklarade det ursprungliga beslutet.
Arkitekten behöver inte bygga allt
Section titled “Arkitekten behöver inte bygga allt ”Det finns en annan övergång som kan vara svår, särskilt för den som kommer in i arkitekturen via utveckling.
Du behöver inte bygga allt själv.
Jag gillar fortfarande att förstå hur saker fungerar på en mycket teknisk nivå, och den grunden spelar roll. Men som arkitekt blir ditt ansvar större än din egen implementation. Du behöver inte bygga allt; du behöver veta hur du ger dem som faktiskt bygger rätt riktning och rätt ramar. Det betyder att förstå tillräckligt för att vägleda deras arbete, känna igen när en föreslagen implementation skapar ett arkitektoniskt problem och röra dig mellan detaljerna och helheten.
Ibland betyder det att gå på djupet i en fråga (query), ett API eller en datamodell.
Ibland betyder det att ta ett steg tillbaka och fråga om vi alls borde göra något av det.
Och allt oftare är det inte bara människor som bygger. Med AI kan arkitekten arbeta direkt med verktyget som genererar objekten, koden och skärmarna. Då går riktningen, ramarna och riktlinjerna till AI:n, och att ge dem väl blir mer och mer arkitektens ansvar. Vi återkommer till det i modul 7.
Det är en del av resan från byggare till arkitekt.
Ditt jobb är att fatta beslut
Section titled “Ditt jobb är att fatta beslut ”I grunden handlar arkitektur om beslut.
En del beslut är lätta att ändra. Andra är det inte.
En sidlayout kan ändras. En etikett kan döpas om.
Men välj fel grundläggande datamodell, publicera identifierare som dussintals system börjar bero på, eller lägg huvudkopian av kritiska data på fel ställe, så blir det mycket dyrare att ändra sig.
Det är arkitektoniska beslut. Och det är precis den sortens beslut som den här kursen koncentrerar sig på.
Som dataarkitekt kommer du att fatta beslut om hur information struktureras, var den bor, hur den växer, hur den rör sig, vem som kommer åt den och hur resten av företaget förstår den.
Tekniken spelar roll.
Men att kunna varje funktion i Salesforce är inte målet.
Målet är att utveckla omdömet att veta vilket verktyg du ska använda, när du ska använda det, vad du ger upp och vad som händer sedan.
Det är att tänka som en arkitekt.
Och nu kan vi börja tänka som en dataarkitekt.
Vad en arkitekt bestämmer här
Section titled “Vad en arkitekt bestämmer här ”- Om en begäran är ett verkligt krav, eller en föreslagen design för det.
- Vilka frågor som ska ställas innan något byggs: borde vi, varför på det här sättet, vad mer kan vi göra, vad händer när det växer eller går sönder.
- Vilka beslut som är arkitektens att fatta och vilka som tillhör dem som bygger; och vilken riktning och vilka ramar byggarna ska få, människor eller AI.
- Hur ett beslut ska förklaras så att en utvecklare, verksamheten och en chef var och en förstår det.