Dataarkitekten i AI:s tid

🌐 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)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 7 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: Känn dina verktyg: de nio frågorna · Nästa: nästa kapitel: Modellera data för mening

Frågan den här modulen besvarar: Vad ändrar AI för dataarkitekten, och vad ändrar den inte?

AI förändrar arkitekturen, men kanske inte på det sätt folk först tror.

Kom ihåg var det här kapitlet började: jag har varit byggare under större delen av min karriär. Under det mesta av den tiden var det dyrt att bygga mjukvara. Du behövde folk med specialistkompetens, och att skriva kod, bygga integrationer, skapa applikationer och testa tog tid; till och med att experimentera med en idé var en betydande investering. AI förändrar den ekvationen. I dag kan jag beskriva vad jag vill ha och låta AI generera en datamodell, Apex, ett Flow, en Lightning-komponent, en integration, tester eller dokumentation anmärkningsvärt snabbt, och i morgon kommer den att göra ännu mer.

Så det är rimligt att fråga: om AI kan göra så mycket av byggandet, vad händer då med arkitekten? Jag tror att svaret är att arkitekturen blir viktigare, inte mindre viktig.

AI är en raketbooster

Jag har använt den här liknelsen i mina föredrag:

AI är raketboostern. Arkitekturen är styrsystemet.

AI ger oss en extraordinär acceleration. Vi kan generera applikationer, datamodeller, integrationer, tester och dokumentation snabbare än någonsin. Men en raketbooster bestämmer inte vart raketen ska. Den ger dragkraft. Styrsystemet bestämmer kursen och gör korrigeringar på vägen.

Utan ett bra styrsystem hjälper inte mer dragkraft. Den tar dig bara snabbare till fel mål. Arkitektens jobb är inte att bromsa allt; det är att se till att vi accelererar åt rätt håll.

Bilden är genererad med AI.

Tänk dig ett AI-verktyg som bygger en applikation tio gånger snabbare än vi kunde förut. Utmärkt, om det är rätt applikation. Men tänk om datamodellen är fel, eller vi valde fel standardobjekt, eller missförstod var masterdata hör hemma, eller designen fungerar med dagens volym och kollapsar med en nolla till? AI har inte tagit bort misstaget. Den har hjälpt oss att bygga misstaget snabbare, och bygga mycket mer ovanpå det innan någon märker något.

Billig implementation flyttar värdet

När implementation är dyr hamnar uppmärksamheten naturligt på implementationen: vem som kan bygga det, hur lång tid det tar, om det alls går att få att fungera. När implementationen blir billigare spelar en annan fråga större roll: vad ska vi bygga? Det är en arkitekturfråga.

AI kan generera tjugo objekt; dataarkitekten avgör om vi borde ha fem. AI kan generera en integration; arkitekten avgör om data alls ska kopieras. AI kan skapa ett fält på några sekunder; arkitekten frågar om det har en tydlig betydelse, en ägare och ett skäl att finnas. AI bygger det vi ber om, så kvaliteten på det vi ber om spelar större roll än någonsin.

Att generera är inte att bedöma

AI är väldigt bra på att generera alternativ, och det är enormt användbart. Jag ber den om tre sätt att modellera något, om avvägningarna, att utmana en arkitektur, att berätta vad som händer vid 100 miljoner poster eller var en design kan fallera, eller att ge mig ett alternativ där Salesforce inte är system of record. Jag vill att arkitekter gör det här.

Men att generera alternativ och att bedöma dem är olika saker. AI kan berätta vad alternativ A och alternativ B erbjuder. Någon måste fortfarande förstå verksamheten tillräckligt väl för att veta vilka fördelar som spelar roll, vilka begränsningar som är verkliga, vilken risk som är acceptabel, och när ett svar är tekniskt rimligt men fel för just den här organisationen. Det är omdöme, och det är arkitektur.

Så här syns det i mitt eget arbete. Under det senaste året har jag slutat skriva det mesta av koden själv. Jag ger AI detaljerna och ber den generera skärmarna och backend-koden, och den är anmärkningsvärt bra på det.

Men den tar inte ett steg tillbaka för att göra en djupare analys. Om det finns en brist i datamodellen eller designen ifrågasätter den den inte. Den behandlar det som redan finns som ett antagande och bygger ovanpå det, snabbt och kompetent. Den stannar sällan upp och säger: ”Innan jag lägger till det här kan modellen du redan har vara värd att ändra.” Att titta på det som finns och fråga om det är rätt, inte bara om vi kan bygga nästa sak på det, är fortfarande arkitektens jobb. Om du vill att AI ska ifrågasätta ett antagande måste du be den om det.

Reversibilitetstestet gäller fortfarande

Gå tillbaka till frågan från modul 3: hur svårt blir det att backa det här beslutet? AI ändrar kostnaden för att generera och ändra mjukvara. Den ändrar inte kostnaden för att ändra verkligheten. När 100 miljoner poster väl är laddade finns de. När tolv system väl beror på en identifierare finns de beroendena. När kunder väl använder en process, eller analyser beror på vad ett fält betyder, får en ändring konsekvenser. Och när data väl har delats någonstans där de inte borde ha delats, sätter ingen mängd ny kod tillbaka dem.

Oåterkalleligt är fortfarande oåterkalleligt.

Agenter är en ny sorts datakonsument

Förr designade vi data för två sorters konsumenter: människor och mjukvara. En person läser en post; en rapport, en integration eller en applikation läser data. Nu finns det en tredje: agenter. En agent kan hämta data, tolka dem, kombinera dem med annan information, besluta och agera, ibland utan någon människa emellan.

Det höjer insatserna. Vad ett fält betyder, vem som äger det, hur aktuellt och pålitligt det är, om det är känsligt, om en agent kan och bör se det, vad som händer när två källor inte är överens: förr var det dokumentation. Nu är det så ett intelligent system förstår verksamheten.

Och dåliga data blir inte smartare för att AI läser dem. Skräp in, skräp ut gäller fortfarande. Dubblettkunder, oklart ägarskap, inkonsekventa identifierare och system of record som motsäger varandra försvinner inte när du kopplar in en agent; konsekvenserna blir bara mer synliga. En person tittar på ett fält och vet att ingen har uppdaterat det på tre år. Agenten har inte den institutionella kunskapen, och den kan agera med stor säkerhet på data som alla andra i tysthet visste att man inte skulle lita på. Dataarkitektur blir en del av AI-arkitekturen.

Se upp för schemaspridning

AI gör det också otroligt lätt att skapa saker. Behöver du ett objekt till, sex fält till, en automatisering till? Generera dem. Varje beslut verkar billigt, men kom ihåg den arkitektoniska gravitationen från modul 3: de objekten och fälten samlar på sig beroenden (automatisering, integrationer, rapporter, agenter), och snart har du en datamodell som ingen har designat. Den bara växte.

Arkitekten måste vara beredd att fråga: ”Behöver vi verkligen det här?” Ibland är det mest värdefulla beslutet att inte skapa något. God arkitektur handlar lika mycket om vad du lämnar utanför som om vad du tar med.

Mänsklig granskning är ingen ceremoni

När jag säger att en mänsklig arkitekt ska granska en AI-genererad datamodell menar jag inte ”AI skapade den, och Steve tittade på diagrammet i fem minuter och godkände det”. Det är ingen tillsyn. Arkitekten måste förstå modellen: varför de här objekten, varför de här relationerna, vilka alternativ som övervägdes, var nycklarna och masterdata finns, vad som händer när volymen växer, vad det innebär för åtkomsten och vilka avvägningar som gjordes. Om jag inte kan svara på det äger jag inte arkitekturen; jag har bara stämplat den. AI kan bidra till en arkitektur, utmana den och dokumentera den, men den mänskliga arkitekten måste kunna försvara den.

Detsamma gäller fakta. Jag använder AI hela tiden för att lära mig och göra research, och min regel är lita, men kontrollera. Ställ frågan, be om förklaringen, alternativen och en utmaning av dess eget svar. Sedan, för allt som spelar roll för din arkitektur: följ länken, läs dokumentationen, kontrollera gränsen, bekräfta licenserna och testa beteendet. AI kan vara väldigt övertygande när den har fel, och att skilja fakta från antaganden är nu en ännu större del av jobbet.

AI kortar inte resan

Det finns en mening jag använder när jag pratar om att bli arkitekt:

AI kortar inte resan. Den kan göra att varje steg räknas mer.

Du behöver fortfarande förstå data, säkerhet, integration, plattformen och verksamheten, och du behöver fortfarande erfarenheten av att fatta beslut och leva med konsekvenserna. AI kan snabba upp ditt lärande, visa dig scenarier du inte har mött, förklara saker, utmana dig, hjälpa dig att bygga och ge dig ett extra par ögon. Använd allt det. Blanda bara inte ihop att en AI kan svaret med att du förstår svaret.

Arkitekten leder

Vi började det här kapitlet med personen som håller i ritningen. AI ger den personen extraordinära nya verktyg: en assistent som kan rita delar av ritningen, ta reda på material, föreslå alternativ, beräkna laster, skriva dokumentationen och till och med upptäcka problem du missat. Använd den. Men någon måste fortfarande förstå hela byggnaden, fråga om det är rätt byggnad, veta vad som händer när kraven ändras och vilka beslut som blir dyra att göra ogjorda, och stå till svars för resultatet.

Det är därför kursens sista nivå heter Direct (leda). Du kanske inte skriver varje kodrad, skapar varje Flow eller bygger varje objekt. Någon måste fortfarande leda lösningen, och det är arkitekten. AI eliminerar inte arkitekturen; den ändrar var arkitekter skapar värde. Det är en fantastisk tid att bli en.

Vad en arkitekt bestämmer här

• Vad som alls ska byggas, nu när det är billigt att bygga: vilka objekt, fält och integrationer som förtjänar sin plats.
• Vilka AI-genererade alternativ som passar den här verksamheten, och vilka som är rimliga men fel.
• Vilka beslut AI rusar förbi som kommer att bli dyra att backa.
• Vad agenter får läsa och agera på, och om data är tillräckligt bra och väl beskrivna för att de ska kunna göra det.
• Vilka fakta från AI som behöver kontrolleras innan de formar designen.

Det är att tänka som en arkitekt i AI:s tid.