Arkitektur
Hur bygger och levererar vi med kontroll?
Marie ska kunna få hjälp med registreringen. Teamet ska kunna bygga och leverera själva. Då behöver vi veta hur information skyddas, vilka ändringar som är tillåtna och hur en ny version når användarna.
Här går jag närmare konstruktionen. När passar ett formulär? När behövs ett API? Vilket ansvar får AI och kod? Hur bygger vi en pipeline som kontrollerar förändringar före leverans? Svaren behöver utgå från arbetet och vad som händer om något blir fel.
Från samtal till information som går att använda.
Vi använder samma exempel som på Språng: någon berättar efter ett kundmöte att kunden behöver en laddbox och har blivit lovad en offert på fredag.
En möjlig konstruktion behöver skilja mellan att tolka det som sägs, kontrollera uppgifterna, få ett beslut och spara en ändring.
När använder vi ett formulär?
Ett formulär passar när uppgifterna är tydliga och personen behöver överblick, exakta val eller jämföra flera fält. Dialog kan passa när informationen uppstår som en berättelse och det är besvärligt att översätta den till fält.
De kan arbeta tillsammans. Marie berättar med egna ord, assistenten föreslår innehåll och ett formulär visar det som ska sparas. Hon kan rätta förslaget direkt i fälten. Vi prövar gränssnittet mot uppgiften, även när tal inte passar situationen.
Saknas det en ansvarig behöver verktyget kunna fråga efter den uppgiften. Om informationen inte räcker ska luckan vara synlig.
AI tolkar. Kod prövar mot uttryckliga regler.
AI kan hjälpa till att tolka formuleringen och föreslå strukturerade uppgifter. Kod kan kontrollera exempelvis obligatoriska fält, datum och tillåtna värden. Verksamhetsregler avgör vilka ändringar som är möjliga i ett visst läge.
En uppgift kan ha rätt format och ändå vara fel i sak. Ett giltigt datum visar inte att kunden faktiskt blev lovad just det datumet. Vilka kontroller och mänskliga beslut som behövs beror på användningen och konsekvenserna.
Applikationen håller ihop ändringen.
Applikationen behöver kontrollera vem som använder den, vad personen får göra och om ändringen kan genomföras. Kod, exempelvis Python, kan hålla ihop stegen och deras felhantering.
Vi behöver bestämma vad som händer om sparandet misslyckas eller samma begäran kommer två gånger. Personen ska kunna förstå om uppgiften sparades och vad som behöver göras vid ett fel.
Databasen håller informationen kvar.
Datamodellen behöver beskriva relationen mellan kunden, behovet, löftet och den ansvariga. Databasen kan upprätthålla uttryckliga begränsningar för det som lagras.
Vi behöver också välja hur ändringar följs, hur länge informationen ska finnas kvar och vilka som får läsa den. Att något kan sparas säger inget om hur länge det bör sparas eller vilka som bör få tillgång till det.
När använder vi ett API?
Ett API ger program ett definierat sätt att utbyta information eller begära en åtgärd. Det kan låta både formuläret och assistenten använda samma kontroller för att spara kundens behov. Servern behöver kontrollera användarens behörighet och innehållet i varje begäran.
När lösningen ansluts till ett befintligt system behöver vi veta vilket system som är källa för respektive uppgift. Vi väljer vilka åtgärder som får utföras, hur åtkomst begränsas och vad som händer vid fel eller upprepade anrop. Ett API behöver samma omsorg om ansvar och felhantering som resten av systemet.
Valen börjar i användningen.
Konstruktionen behöver gå att pröva.
Vi testar viktiga beteenden och felvägar mot de krav som gäller för användningen. Vad händer om ett datum saknas, en person saknar behörighet eller ett annat system inte svarar?
Ett testat beteende ger underlag för just det beteendet. För att bedöma lösningen som helhet behöver vi också förstå täckning, begränsningar, integrationer och ansvar för drift och förändringar.
Hur sätter vi upp en pipeline?
En pipeline är en bestämd väg från en ändring i koden till en version som kan användas. Kontrollerna görs på samma sätt varje gång, och det går att se vilken ändring som levererades.
Vi börjar med en liten leveransväg som teamet förstår och kan använda:
- Spara och granska ändringen. Koden versionshanteras. Granskningen ska omfatta det ändrade beteendet, åtkomsten till information och relevanta felvägar.
- Bygg och kontrollera. Kör tester och relevanta kontroller av kod och beroenden. Ett misslyckat obligatoriskt steg ska hindra nästa leveranssteg.
- Pröva i en separat miljö. Testa viktiga arbetsmoment och integrationer med lämpliga testdata. Produktionsuppgifter och åtkomstuppgifter ska hanteras separat.
- Leverera den kontrollerade versionen. Bestäm vilka som får godkänna och genomföra leveransen. Begränsa leveransverktygets behörigheter och dokumentera vad som ändras.
- Kontrollera och kunna återställa. Kontrollera att viktiga funktioner fungerar efter leveransen. Ha en prövad väg tillbaka. Databasändringar behöver egen planering eftersom en återställd kodversion inte automatiskt återställer data.
Vi väljer kontroller efter lösningens risker. En pipeline hjälper oss att upprepa dem, men ersätter inte bedömningen av vad som måste kontrolleras. Förändringar i AI-instruktioner och modellval behöver också kunna följas och prövas när de påverkar systemets beteende.
Hur levererar teamet säkert?
Teamet behöver veta vad det får ändra själv, vilka kontroller som gäller och när någon annan ska granska. Det behöver finnas en ansvarig för systemet och en tydlig väg för att hantera fel.
Vi bygger upp förmågan genom små leveranser med riktiga kontroller. Teamet får återkoppling på både lösningen och hur den levererades. Då kan fler bidra, samtidigt som verksamhet och IT kan följa hur ändringarna hanteras.
Arkitekturen möter arbetet.
Den tekniska konstruktionen behöver stödja det människor faktiskt ska göra. När arbetssättet förändras behöver vi pröva om informationen, reglerna och systemets beteende fortfarande passar.
Vad behöver er IT kunna bedöma?
Jag bygger själv och arbetar tillsammans med verksamhet och IT kring krav, tekniska val och verifiering. Vi börjar med vad lösningen behöver göra, vilka ramar som gäller och vilket underlag ni behöver för att kunna ta nästa steg.