Ga naar inhoud

De data-architect in het tijdperk van AI

Ook beschikbaar in 28 talen

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

A construction 3D printer lays the curved concrete walls of a small house, with the plan it is building from unrolled on a table in front.
Afbeelding gegenereerd met AI

Module 7 van 7 in het hoofdstuk Denken als een data-architect, het eerste hoofdstuk van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Ken je gereedschap: de negen vragen · Volgende: het volgende hoofdstuk: datamodellering

De vraag die deze module beantwoordt: Wat verandert AI voor de data-architect, en wat verandert het niet?

AI verandert architectuur, maar misschien niet zoals mensen eerst denken.

Weet je nog waar dit hoofdstuk begon: ik ben het grootste deel van mijn loopbaan een bouwer geweest. Het grootste deel van die tijd was software bouwen duur. Je had mensen met specialistische vaardigheden nodig, en code schrijven, integraties bouwen, applicaties maken en testen kostte allemaal tijd; zelfs met een idee experimenteren was een serieuze investering. AI verandert die rekensom. Vandaag kan ik beschrijven wat ik wil en AI opmerkelijk snel een datamodel, Apex, een Flow, een Lightning-component, een integratie, tests of documentatie laten genereren, en morgen doet het nog meer.

Dus het is redelijk om te vragen: als AI zoveel van het bouwen kan doen, wat gebeurt er dan met de architect? Ik denk dat het antwoord is dat architectuur belangrijker wordt, niet minder belangrijk.

Ik heb deze vergelijking in mijn presentaties gebruikt:

AI is de raketaanjager. Architectuur is het geleidingssysteem.

AI geeft ons een buitengewone versnelling. We kunnen applicaties, datamodellen, integraties, tests en documentatie sneller genereren dan ooit. Maar een raketaanjager beslist niet waar de raket heen moet. Hij levert stuwkracht. Het geleidingssysteem bepaalt de koers en stuurt onderweg bij.

Zonder goede geleiding helpt meer stuwkracht niet. Je komt er alleen sneller mee op de verkeerde bestemming. De taak van de architect is niet alles vertragen; het is zorgen dat we in de juiste richting versnellen.

Een raketmodel in Saturnus V-stijl ligt horizontaal op architectuurtekeningen, met rode aanduidingen voor stuwkracht van AI en blauwe aanduidingen voor architecturale geleiding en koerscorrectie

Afbeelding gegenereerd met AI.

Stel je een AI-tool voor die een applicatie tien keer sneller bouwt dan we vroeger konden. Prima als het de juiste applicatie is. Maar wat als het datamodel verkeerd is, of we het verkeerde standaardobject kozen, of verkeerd begrepen waar de stamgegevens horen, of het ontwerp werkt op het volume van vandaag en bezwijkt bij nog een nul? AI heeft de fout niet weggenomen. Het heeft ons geholpen de fout sneller te bouwen, en er veel meer bovenop te bouwen voordat iemand het merkt.

Goedkope implementatie verplaatst de waarde

Section titled “Goedkope implementatie verplaatst de waarde ”

Als implementatie duur is, gaat de aandacht vanzelf naar de implementatie: wie kan het bouwen, hoe lang gaat het duren, kan het überhaupt werkend gemaakt worden? Naarmate implementatie goedkoper wordt, wordt een andere vraag belangrijker: wat moeten we bouwen? Dat is een architectuurvraag.

AI kan twintig objecten genereren; de data-architect beslist of we er vijf zouden moeten hebben. AI kan een integratie genereren; de architect beslist of de data überhaupt gekopieerd moet worden. AI kan in seconden een veld maken; de architect vraagt of het een duidelijke betekenis, een eigenaar en een reden van bestaan heeft. AI bouwt waar we om vragen, dus de kwaliteit van waar we om vragen is belangrijker dan ooit.

AI is heel goed in het genereren van opties, en dat is enorm nuttig. Ik vraag het om drie manieren om iets te modelleren, om de afwegingen, om een architectuur uit te dagen, om me te vertellen wat er gebeurt bij 100 miljoen records of waar een ontwerp kan falen, of om een alternatief waarin Salesforce niet het bronsysteem is. Ik wil dat architecten dit doen.

Maar opties genereren en ze beoordelen zijn verschillende dingen. AI kan me vertellen wat optie A en optie B elk bieden. Iemand moet de business nog steeds goed genoeg begrijpen om te weten welke voordelen ertoe doen, welke beperkingen echt zijn, welk risico acceptabel is, en wanneer een antwoord technisch plausibel is maar verkeerd voor deze organisatie. Dat is oordeelsvermogen, en dat is architectuur.

Zo zie ik dat in mijn eigen werk. Het afgelopen jaar ben ik gestopt met het zelf schrijven van de meeste code. Ik geef AI de details en vraag het de schermen en de back-endcode te genereren, en het is daar opmerkelijk goed in.

Maar het doet geen stap terug om er dieper analytisch naar te kijken. Als er een fout in het datamodel of het ontwerp zit, trekt het die niet in twijfel. Het behandelt wat er al is als aanname en bouwt erop voort, snel en bekwaam. Het stopt zelden om te zeggen: “Voordat ik dit toevoeg, is het misschien de moeite waard het model dat je al hebt te veranderen.” Kijken naar wat er is en vragen of het klopt, niet alleen of we er het volgende op kunnen bouwen, is nog steeds de taak van de architect. Wil je dat AI een aanname in twijfel trekt, dan moet je erom vragen.

Ga terug naar de vraag uit module 3: hoe moeilijk wordt het om deze beslissing terug te draaien? AI verandert de kosten van software genereren en veranderen. Het verandert de kosten van het veranderen van de werkelijkheid niet. Zodra 100 miljoen records geladen zijn, bestaan ze. Zodra twaalf systemen van een identificator afhangen, bestaan die afhankelijkheden. Zodra klanten een proces gebruiken, of analyses afhangen van wat een veld betekent, heeft het veranderen ervan gevolgen. En zodra data gedeeld is waar dat niet had gemogen, haalt geen enkele nieuwe code haar terug.

Onomkeerbaar is nog steeds onomkeerbaar.

Agents zijn een nieuw soort datagebruiker

Section titled “Agents zijn een nieuw soort datagebruiker ”

Vroeger ontwierpen we data voor twee soorten gebruikers: mensen en software. Een persoon leest een record; een rapport, een integratie of een applicatie leest de data. Nu is er een derde: agents. Een agent kan data ophalen, interpreteren, combineren met andere informatie, beslissen en handelen, soms zonder mens ertussen.

Dat verhoogt de inzet. Wat een veld betekent, wie er eigenaar van is, hoe actueel en betrouwbaar het is, of het gevoelig is, of een agent het kan en mag zien, wat er gebeurt als twee bronnen het oneens zijn: dat was vroeger documentatie. Nu is het hoe een intelligent systeem de business begrijpt.

En slechte data wordt niet slimmer omdat AI haar leest. Garbage in, garbage out geldt nog steeds. Dubbele klanten, onduidelijk eigenaarschap, inconsistente identificatoren en conflicterende bronsystemen verdwijnen niet als je een agent aansluit; de gevolgen worden alleen zichtbaarder. Een persoon kijkt naar een veld en weet dat niemand het in drie jaar heeft bijgewerkt. De agent heeft die kennis van de organisatie niet, en handelt misschien met grote stelligheid op data die iedereen stilletjes wist niet te vertrouwen. Data-architectuur wordt een deel van AI-architectuur.

AI maakt het ook ongelooflijk makkelijk om dingen te maken. Nog een object nodig, zes velden extra, nog een automatisering? Genereer ze. Elke beslissing lijkt goedkoop, maar denk aan de architecturale zwaartekracht uit module 3: die objecten en velden verzamelen afhankelijkheden (automatisering, integraties, rapporten, agents), en voor je het weet heb je een datamodel dat niemand ontworpen heeft. Het is gewoon gegroeid.

De architect moet bereid zijn te vragen: “Hebben we dit echt nodig?” Soms is de waardevolste beslissing iets niet maken. Goede architectuur gaat net zo goed over wat je weglaat als over wat je erin stopt.

Als ik zeg dat een menselijke architect een door AI gegenereerd datamodel moet beoordelen, bedoel ik niet “AI maakte het, Steve keek vijf minuten naar het diagram en keurde het goed”. Dat is geen toezicht. De architect moet het model begrijpen: waarom deze objecten, waarom deze relaties, welke alternatieven zijn overwogen, waar de sleutels en de stamgegevens zitten, wat er gebeurt als het volume groeit, wat de gevolgen voor toegang zijn, en welke afwegingen gemaakt zijn. Als ik dat niet kan beantwoorden, ben ik geen eigenaar van de architectuur; dan heb ik er alleen een stempel op gezet. AI kan bijdragen aan een architectuur, haar uitdagen en documenteren, maar de menselijke architect moet haar kunnen verdedigen.

Hetzelfde geldt voor feiten. Ik gebruik AI voortdurend om te leren en onderzoek te doen, en mijn regel is vertrouw, maar controleer. Stel de vraag, vraag om de uitleg, de alternatieven en een tegenargument tegen het eigen antwoord. Volg dan, voor alles wat ertoe doet voor je architectuur, de link, lees de documentatie, kijk de limiet na, bevestig de licenties en test het gedrag. AI kan heel overtuigend zijn als het ernaast zit, en feiten van aannames onderscheiden is nu een nog groter deel van het werk.

Er is een zin die ik gebruik als ik het over architect worden heb:

AI maakt de reis niet korter. Het kan elke stap meer laten opleveren.

Je moet nog steeds data, beveiliging, integratie, het platform en de business begrijpen, en je hebt nog steeds de ervaring nodig van beslissingen nemen en met de gevolgen leven. AI kan je leren versnellen, je scenario’s laten zien die je nog niet tegenkwam, dingen uitleggen, je uitdagen, je helpen bouwen en je een tweede paar ogen geven. Gebruik het allemaal. Verwar alleen een AI die het antwoord weet niet met jij die het antwoord begrijpt.

We begonnen dit hoofdstuk met de persoon met de bouwtekening. AI geeft die persoon buitengewone nieuwe gereedschappen: een assistent die delen van de bouwtekening kan tekenen, materialen kan uitzoeken, alternatieven kan voorstellen, belastingen kan berekenen, de documentatie kan schrijven en zelfs problemen kan zien die jij miste. Gebruik het. Maar iemand moet nog steeds het hele gebouw begrijpen, vragen of het het juiste gebouw is, weten wat er gebeurt als de eisen veranderen en welke beslissingen duur zijn om terug te draaien, en verantwoordelijk zijn voor het resultaat.

Daarom heet het laatste niveau van deze cursus Direct (sturen). Misschien schrijf je niet elke regel code, maak je niet elke Flow en bouw je niet elk object. Iemand moet de oplossing nog steeds sturen, en dat is de architect. AI schaft architectuur niet af; het verandert waar architecten waarde creëren. Het is een buitengewone tijd om er een te worden.

  • Wat er überhaupt gebouwd moet worden, nu bouwen goedkoop is: welke objecten, velden en integraties hun plek verdienen.
  • Welke door AI gegenereerde opties bij deze business passen, en welke plausibel maar verkeerd zijn.
  • Welke beslissingen AI voorbijraast die duur zullen zijn om terug te draaien.
  • Wat agents mogen lezen en waarnaar ze mogen handelen, en of de data goed en duidelijk genoeg beschreven is om dat te doen.
  • Welke feiten van AI gecontroleerd moeten worden voordat ze het ontwerp vormen.

Dat is denken als een architect in het tijdperk van AI.