Bygg in stöd för förändring

Systemdesign och systemarkitektur handlar om att förutse framtiden och skapa ett ramverk som stöder dagens verksamhet och dess behov för att kunna växa och utvecklas.

Vanliga fallgropar

När man analyserar verksamhetens behov och designar ett system brukar visionerna vara extrema, målen orealistiska och resultatet sällan lyckat. Man försöker få med allt man behöver och vill ha, plus lite till. Det brukar resultera i två vägval eller en kombination av dessa vägar.

Den ena vägen är att man kan ignorera komplexiteten, dela upp projektet i hanterbara delar och kalla projektmetodiken för agil, inte för att agila projektmodeller är fel, men det ska inte vara en ursäkt för att försöka få med allt som står på önskelistan.

En annan väg man kan välja är att låta budgeten styra, stryka allt som är önskemål och nytt jämfört med dagens processer. Att kanske helt enkelt bara göra analoga processer digitala utan att ge verksamheten mervärde genom förbättringar. Visst kan man vinna på detta, men samtidigt kan man måla in sig i ett hörn som gör att det blir svårt att förändra processer längre fram.
 

Avgränsa utan att begränsa

När man designar ett system, vare sig det handlar om nyproduktion eller förändring så är det viktigt att man i analysfasen identifierar framtida behov och önskemål. För att projektet inte ska bli övermäktigt, dels ekonomiskt och dels för användarna så kan det krävas avgränsningar i funktionalitet. Genom att ta med framtida behov i designen kan man i ett tidigt skede bygga in stöd för att kunna förändra systemet längre fram.

Det är viktigt att hålla framtida förändringar i åtanke både för att hålla nere framtida kostnader men också för att få en genomtänkt och framtidssäker struktur. Att göra detta kan även ge fördelar när man bygger ett system efter en agil process i flera iterationer. Genom att hela tiden planera för nästa steg kan man avgränsa projekt, delprojekt, moduler och iterationer utan att begränsa möjligheterna.

Man kan inte förutse alla framtida behov. Förändringar i organisationen, driftmiljöer, lagar och regler kan ändra förutsättningarna. Därför är det också viktigt att man håller sig inom överskådliga och rimliga ramar.
 

Snabbt + flexibelt = agilt

När man arbetar efter agila projektmodeller så gör man det för att snabbare kunna leverera ny funktionalitet, ändringar och rättningar till verksamheten. Att arbeta agilt inom ett projekt innebär att man lätt ska kunna ändra både design och processer samtidigt som man delar upp utvecklingen i mindre fristående delar som kan driftsättas stegvis.

Målsättningen är att undvika att stora delar av arbetet förblir halvfärdigt och att investeringar inte levererar verksamhetsnytta under en längre tid. Genom att arbeta agilt kan man stegvis övergå från ett system till ett annat. Man kan ersätta delar av en process och låta verksamheten och systemen utvecklas mer organiskt, istället för att investera stora summor pengar och arbetskraft i att byta ut ett helt system mot ett annat över en natt långt fram i tiden.

Att försöka implementera ett stort och komplext system i sin helhet brukar många gånger orsaka stora störningar i produktionen även om allt har testats omsorgsfullt. Förutsättningarna kan också ha ändrats så mycket att man helt enkelt måste börja förändra systemet innan det ens är driftsatt. Inget tar ut det andra, ibland finns det inga alternativ. Man kan också jobba iterativt för att leverera delar från utveckling till test för att så småningom ha ett färdigt system som kan driftsättas i sin helhet. Utvecklar man ett helt nytt system är det viktigt att man har god framförhållning och är beredd att göra justeringar på vägen.
 

Två sidor av samma projekt

Nu var inte tanken att hylla eller dissa agila projektmodeller utan att förklara varför man bör planera för framtida förändringar. Idén till artikeln kom efter att vi infört vissa ändringar i en kunds projekt, ett system som befinner sig i själva förvaltningsfasen.

Vi har infört ändringar i en webbapplikation, byggt enligt principen Model-View-Control (MVC) dock utan särskild hänsyn till framtida förändringar. Utöver detta har vi infört likvärdiga ändringar i det backofficesystem där data behandlas och exporteras till ett affärssystem. Denna del är fristående från själva webbapplikationen men använder samma datalager och kommunicerar via samma API:er.

Genom att backofficesystemet är designat med åtanke att det ska vara enkelt att förändra så implementerades samma ändringar i den delen av systemet på en bråkdel av tiden som ändringarna i webbapplikationen trots att båda lösningarna är objektorienterade och designade efter en trelagersprincip med användargränssnitts-, logik- och kommunikationslager. Detta visar på hur viktigt det är att ta hänsyn till framtida behov vid systemdesign och systemutveckling.
 

Vill du veta mer?

Langate är experter på drift och underhåll av lokala system samt molntjänster som Office 365, Azure m.fl. Vi kan erbjuda rådgivning, automation och effektiva supportlösningar. Vi jobbar också med verksamhetsutveckling och systemanpassningar inom SharePoint, Dynamics CRM, Dynamics 365 samt utveckling i Microsoft .NET.

Ni är alltid välkomna att kontakta oss, så ska vi berätta mer. Läs mer om våra tjänster på vår webbsida: http://langate.se/utveckling