Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Jeg må indrømme at det er sjældent (som i aldrig), at jeg har spurgt min mor eller far til råds omkring en væsentlig beslutning under afklaring eller udvikling af en ny it-løsning.
API-versionering eller event-platforme er ligesom bare aldrig kommet op som emner i vores snakke.
Medmindre at din far og mor hedder Bill og Melinda, gætter jeg på, at det samme gør sig gældende for dig.
Alligevel vil jeg påstå, at de fleste af os har fået nogle vigtige formaninger i barndommen, som vi kan have stor glæde af at huske på, når vi i dag arbejder med at afklare og udvikle it-løsninger.
Når din mor sagde, at du ikke skal spise i sofaen, eller når din far bad dig om at tage skoene af, før du går indenfor, så var det i virkeligheden et par gode lektioner i, hvorfor “separation of concerns” er vigtigt. (I mangel af en god dansk oversættelse har jeg valgt at bruge den engelske formulering her.)
Din mor havde nemlig forudset de store risici der ville følge med, hvis du skulle balancere din ketchupfyldte tallerken på kanten af sofaen med det lyse betræk og de bløde hynder, som langt fra er egnet til at understøtte den grad af tallerkenkontrol, som der var behov for.
Og det gode alternativ fandtes jo: at bruge køkkenet eller spisepladsen, som i øvrigt er en del af huset der er særligt optimeret til at understøtte aktiviteten at indtage føde.
Tilsvarende vil de effektive processer omkring at holde huset rent lide et voldsomt tilbageslag, hvis dine beskidte sko fik lov til at fordele den medbragte jord rundt i huset, som i øvrigt er indrettet til og påtænkt brug uden fodtøj.
Bortset fra bryggerset, som netop er bygget til at tage hånd om særlige udfordringer omkring for eksempel beskidt fodtøj.
separation of concerns
Længe før du selv vidste, at du i dag ville sidde i it-branchen og forsøge at finde hoved og hale i komplekse problemstillinger, lærte dine forældre dig således, at “separation of concerns” er et vigtigt element i at opnå effektive processer og løsninger. En viden, du med stor fordel kan gøre brug af i mange aspekter af dit daglige arbejde.
Den klassiske brug er som et designprincip, du forfølger, når du afklarer arkitekturen for en ny løsning eller komponent.
Målet er typisk at opnå en opskæring af den nødvendige funktionalitet i et antal enkeltdele med en passende ansvarsfordeling, som både understøtter en stærk sammenhæng indenfor de enkelte komponenter, og samtidig en løs kobling imellem dem.
Og ikke mindst når ny funktionalitet skal tilføjes en eksisterende løsning, er det vigtigt at have et klart billede af, hvilket ansvar de enkelte komponenter er tildelt, så det kan afgøres i hvilke komponenter den nye funktionalitet skal tilføjes, og/eller om der eventuelt er behov for nye komponenter med nye ansvarsområder.
I den slags afklaringer er analogien med huset og rummenes indretning nærliggende.
Rummene i huset har hvert sit ansvar og er indrettet derefter, og de indvendige døre udgør en tilpas løs kobling imellem dem.
Selvom døre er dyrere og tillader mere lyd at passere end en væg, så opvejes ulemperne så rigeligt af, at de er nemmere at åbne og lukke på daglig basis end en væg.
Og man kan stadig tænde lys, skrue op for varmen og åbne vinduer i ét rum, uden at det behøver at påvirke de andre rum i særlig grad. Virkelig smart.
Er der brug for mere bordplads til madlavningen, er en god løsning at kigge på, om køkkenet kunne indrettes anderledes.
En dårlig løsning er at tage bordpladen på badeværelset i brug, nu den er der alligevel.
Og hvis et nyt behov tilsiger tag over bilen, vil de fleste være enige i, at det er bedre at tilbygge en dedikeret garage eller carport, end at udvide stuen til formålet - selv om en fuldautomatisk hejseport ved siden af fladskærmen alligevel også kan et eller andet.
Forskellen på behov og løsning
De fleste af jer har formodentligt også oplevet at tilsvarende uheldige forslag af og til huserer, når mulige it-løsninger bliver diskuteret og afklaret rundt omkring.
Heldigvis kommer de sjældent fra de involverede udviklere og arkitekter, som er og skal være eksperterne her.
Et andet område hvor “separation of concerns” bør få opmærksomhed, er når vi taler om forskellen på behov og løsning.
Det kan meget let ske, at en dialog om nye krav til en løsning kommer til at tage for meget udgangspunkt i, hvordan den eksisterende løsning fungerer, frem for at fokusere på de egentlige behov bag ønskerne.
Der vil ofte være bedre måder at løse behovene på end de første umiddelbare tanker om en løsning. Her kunne eksemplet med garageporten ovenfor også gøre sig gældende.
Når diskussionen ender i løsningssnak for tidligt og før de reelle behov og mål er belyst tilstrækkeligt, indsnævres det løsningsrum, der diskuteres, så den måske bedste løsning aldrig får mulighed for at komme op til overfladen.
Det er dog en udfordring, som nok ikke kan fjernes.
Det er naturligt for de fleste af os at tilgå ønsker til forandringer ud fra den konkrete virkelighed, vi kender, og ikke altid have overblikket til at træde et skridt tilbage og skabe overblik over de reelle behov, og se de mulige tiltag i et bredere perspektiv. Det er vel bl.a. derfor der findes psykologer.
Så den tilgang gælder selvfølgelig også for de brugere og kunder som lever en del af deres liv i de systemer vi bygger til dem.
Vi kan dog stadig gøre noget ved det. Kuren er at være opmærksom på hvornår vi snakker om behov og hvornår vi snakker om mulige løsninger, så vi sammen bliver mere bevidste om forskellen.
En tommelfingerregel er, at et behov skal kunne udtrykkes uden at referere til løsningen.
Det kræver lidt øvelse, men tvinger os til at fokusere på den forretning eller de processer vi skal understøtte med systemet, så vi får hævet diskussionen op over den kendte systemverden eller måske fastlåste forestillinger i hovedet om hvordan løsningen kunne se ud.
Fokuser på den information, der skal behandles
Et andet fif er i første omgang at fokusere på den information, der skal behandles eller skabes, frem for på tanker om hvilke komponenter og teknologier der skal gøre det.
Derved kan afklaringen af behovene holdes ren og give det bedst mulige grundlag for en åben diskussion af de mulige løsninger.
Så opnå bedre løsninger ved at øge din bevidsthed om “separation of concerns” - både når du afklarer behov og designer de tilhørende løsninger.
Og send så en venlig tanke til dine forældre - de har lært dig meget.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
