Det här är del 2 i en serie artiklar om hur Archify ser på IT-arkitektur. Med värderingar och reflektioner om hur vi bygger bra IT-system som är följsam med förändringar.

Förändring är ett allt viktigare icke-funktionellt krav. Bra IT-system handlar då mycket om förmågan att klara förändring. Där anser jag att arkitekturen är avgörande för att kunna leverera den förmågan. Arkitekturen behöver vara agil och omfamna förändring.

Icke-funktionella krav

En av IT-arkitektens viktigaste uppgifter är att klargöra och möta de icke-funktionella kraven. Här brukar vi kunna anpassa IT-arkitekturen i förmågan att hantera säkerhet, spårbarhet, kompabilitet, portabilitet, skalbarhet, prestanda, osv.

Förändring har blivit allt viktigare att ta hänsyn till i våra IT-system. Jag tycker dock det är sällan man lyfter fram det icke-funktionella kravet förändring, och hur vi ska möta det medvetet. Vi kan dock se att det finns konkreta exempel på att hantera förändring. Microservices är ett svar på det, anser jag. Att bli mer lättrörlig, och förändringsbar, genom att bryta upp systemet i små autonoma delar som ska kunna vara utbytbara. Återigen tycker jag, precis som jag skrev i min tidigare artikel, att man ofta ogrundat följer strömmen och praxis då man gör sitt val, t ex microservices. Vi måste förstå och ha förmågan att implementera microservices på ”korrekt” sätt som svarar upp mot just förändring.  Förmågan att klara förändring är också mycket svårare än att enbart IT-arkitektur är hela lösningen. För det första tror jag vi behöver ta en ansats som integrerar sig även över arbetssätt och organisation (minns Conway) och som med annat synsätt också kan påverka livscykeln av ett IT-system.

En föränderlig värld

Idag när vi ska bygga IT-system är det mer eller mindre praxis att välja ett agilt arbetssätt. Det är ju inte säkert att det alltid passar med ett agilt arbetssätt. Men det är ju ett sätt vi försöker hantera förändring på. Det kan vara lämpligt att poängtera, att en av grundprinciperna bakom agila manifestet är just att omfamna förändring. Vi människor utvecklar våra liv och vårt samhälle genom förändring. Och vi gör det i allt snabbare takt. Nu pratar vi om digitalisering och det genomsyrar många verksamheters behov av förändring. Hela tiden någon ny orsak att förändras. Vi försöker hitta arbetssätt som gör att vi kan hantera denna förändringstakt.

“Responding to change over following a plan”

-         Agila manifestet

När vi bygger IT-system så kan jag se att det finns huvudsakligen två kategorier av förändringar.

Dels har vi en verksamhet som vi bygger systemet för. Verksamhetens krav och behov förändras över tid. Vissa verksamheter snabbare än andra. Viktigt att anmärka på här är att det inte är säkert att behovet i sig förändras, utan bara kraven. Med det vill jag säga att många verksamheter inte vet vad de vill ha från ett IT-system, initialt. Behovet är inte känt. Det behöver vi vara medveten om.

“Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.”

-         Agila manifestet

Sedan har vi även en teknisk förändring. Vi får nya verktyg, plattformar och tekniska möjligheter. Nya best-practices. Dessa kan drivas av stora leverantörer i branschen tillsammans med community-rörelser. Kanske i svar mot vad verksamheter i stort har behov av. Kanske för att tjäna pengar. Kanske för att det enbart har blivit möjligt, efter nya insikter och tekniksprång.

Som parentes kan det vara intressant att reflektera över vad som är hönan och ägget. Vem driver vem här? Är det tekniken som driver verksamheten, eller verksamheten som driver tekniken? Där tror jag mer på ett samspel, en komplex spiral där det studsar möjligheter och utmaningar i en förhoppning om att göra bättre saker. Och det bottnar ofta i att tjäna mer pengar. Rent krasst. Men förändring blir det ju vilket som.

Livscykeln

“Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.”

Vi vill skapa bra IT-system. Bra IT-system kan vara något som möter eller väcker behov som finns hos den som ska använda det, det ska bidra till affärsnytta i en verksamhet. Men att bygga IT-system är dyrt. Det kostar pengar och resurser, och det tar tid. Detta är ofta en begränsande faktor. Man skulle kunna säga att ett bra IT-system då också kan vara ett system som inte kostar så mycket? Något som går fort att utveckla? Något som inte kräver så många resurser?

Vad är det vi ser händer ofta med våra IT-system? Hur ser livscykeln ut? Vi kravar. Vi utvecklar. Vi kvalitetssäkrar. Vi levererar. Verksamheten använder systemet. Klart. Eller? Ja, vissa vill nog gärna se det så, åtminstone ur ett investeringsperspektiv. Stor investering initialt, räkna hem det över tid. Men det som slår tillbaka på oss är ju: förändring. Nya behov, nya krav, ny teknik. Med nya behov, krav och teknik så inkluderar jag mycket, även sådana aspekter såsom kostnadsbesparing och effektivisering. För om inte verksamhetens funktionella behov förändras så kommer det andra saker som man inte är nöjd med. Systemet kostar för mycket. Systemet är för långsamt. Systemet är besvärligt.

Vad gör vi? Vi bygger om systemet! Version X + 1.Vi börjar om på nytt. Nya färska krav, och ny teknik som är bättre och snabbare Kanske en ny metod, t ex Scrum, Lean, SAFe? Kanske ny teknik, t ex BPM, standardsystem/SaaS, molnet, .NET Core? Men vad är det som händer med tiden? Jag vill mena att vi återupprepar oss själva i mångt och mycket. Måndag hela veckan.

Är det önskvärt att göra så? Att bygga om systemet varje gång? Blir inte det väldigt dyrt? Är det inte många risker förknippad med ett IT-projekt som man helst vill undvika eller åtminstone minska?

Jag vill mena att detta är något som vi borde kunna hantera bättre. Det finns många viktiga aspekter att ta hänsyn till för att undvika detta. Jag vill gärna ta utgångspunkt i den IT-arkitektur som ligger till grund för systemet, eftersom det är mitt expertområde. Naturligtvis är jag medveten om att andra kompetenser och perspektiv är relevanta för att uppnå en bättre hantering av förändring. Där är inte alltid IT i centrum. Men! Min utgångspunkt är att vi kan omfamna förändring i vår IT-arkitektur. Vi bygger för förändring. Vi höjer blicken och ser långsiktigt på vårt IT-systems livscykel.

Många frågor och inte så många svar i denna artikel. Det ger dock en bakgrund till nästa del i serien där vi kommer berätta om hur Archify tycker IT-arkitektur ska utformas för att hantera förändring och ge en bättre livscykel.