Gæstebloggen

Software skal ses som en levende organisme

I de første årtier af softwareudvikling designede man software, som man bygger broer: man planlagde grundigt forud, hvilket gjorde det svært og dyrt at ændre noget, når man først var begyndt at bygge.

I dag bygger man ovenpå nuværende komponenter og kombinerer forskellige komponenter, som skal hænge sammen i nye infrastrukturer og produkter.

Det gør softwareudvikling langt mere komplekst, fordi man skal forholde sig til langt flere integrationer, aktører og parametre end tidligere.

Konstantinos Manikas er ekstern lektor og underviser på kurset Softwarearkitektur på IT-Universitetet, og enterprise architect hos DHI Group.

Nutidens softwareprodukter består af forskellige komponenter og gør brug af andre systemer. De forskellige komponenter og systemer bliver afhængige af og relaterer tæt til hinanden, men har også til en vis grad deres eget system forstået på den måde, at komponenternes videre udvikling afhænger af den videre udvikling af hele gruppen af komponenter.

Software bliver således ikke længere bygger fra bunden, men skal betragtes som en levende størrelse, som har mange liv i forskellige sammenhænge, hvilket gør, at det ikke længere muligt at udvikle, som man gjorde for 20-30 år siden.

Softwaresystemer er levende organismer, der er afhængige af hinanden

Det er derfor mere rigtigt at sammenligne softwaresystemer med forskellige arter i et økosystem, hvor den ene arts overlevelse og trivsel afhænger af overlevelsen af hele økosystemet.

Ligesom levende organismer, integrerer moderne softwaresystemer til og integreres i mange andre systemer, hvilket gør softwareudvikling til en organtransplantation, hvor organerne skal fungerer sammen for at organisme kan overleve.

Et eksempel er mobiltelefoner, hvor man i starten byggede telefoner som selvstændige enheder, bygger man i dag en platform, hvor andre udviklere udvider telefonens funktionalitet med apps. En vigtig faktor i valget af smartphones er derfor blevet antallet af apps, som understøttes af telefonens styresystem.

Hvis morgendagens iPhone kun understøtter halvdelen af de apps, som den gør i dag, vil jeg derfor ikke blive overrasket, hvis de fleste brugere ville skifte platform. Dermed har systemet evne til at indeholde og integrere til andre systemer bevæget sig fra tidligere at være nice-to-have til nu at være helt essentielt.

Hastigheden stiller store krav til arkitekter og udviklere

Udover systemernes gensidige afhængighed og den stigende hastighed i udviklingen, er time-to-market også blevet et afgørende parameter, som aldrig har været vigtigere for konkurrencen, end det er nu. Det betyder, at beslutninger skal tages meget hurtigere end tidligere.

Det stiller høje krav til softwarearkitekten, som både skal tage hensyn til tidligere krav som en ordentlig kravspecifikation, ordentligt design, passende udvikling mht. kvalitet og parametre, teknisk begrænsning, software deployment og vedligeholdelse.

Men hastigheden i udviklingen har også medført, at forandring er i fokus, og evnen til at omstrukturere et system hurtigt med lave omkostninger er blevet en konkurrencefordel.

Når man designer arkitektur bør man derfor også medtænker, hvordan systemet forventes at udvikle sig i fremtiden.

Det vil også sige, at man som softwarearkitekt bør undgå at indføre for meget arkitektonisk gæld, som er en betegnelse for de tekniske kompromiser, der foretages i et system og som kan giver kortsigtede fordele, men svække systemet samlet set på den lange bane.

Endelig skal systemet tage hensyn til de mange eksterne aktører, der interagerer med systemet, hvilket medfører et socialt aspekt af softwareudvikling. Vil man have succes, må man ikke træde på eksterne aktører.

Det betyder, at systemet skal kunne understøtte integrationen af stadigt flere eksterne systemer, og evnen til at gøre dette ”by design” kan være afgørende for et systems succes.

Større fokus på forretningen

Men øget hastighed presser også systemudviklingen, fordi design- og arkitekturbeslutninger skal tages på langt kortere tid end tidligere. Samtidig er disse beslutninger er ikke blevet mindre afgørende for forretningen og produktets succes. It bliver en stadigt mere afgørende del af forretningen i flere og flere brancher, og virksomheders forretningsanalyse og strategi er i stadig højere grad baseret på it.

Tager man et forkert valg i forhold til fx teknologi, kan det have alvorlige konsekvenser. Det gør en kæmpe forskel, hvilken teknologi man vælger, og hvordan den bliver implementeret.

Samtidig er teknologi under konstant udvikling, hvilket kan gøre det svært at træffe de rigtige valg, fordi man ikke kan forudsige, hvad der vil ske om tre til fem år.

Et eksempel er en stor ingeniørvirksomhed med afdelinger i 25 lande, hvis domæne egentlig ikke er software men traditionel ingeniørarbejde. På trods af det er 80 procent af deres indtægt baseret på software. I den situation er det helt afgørende at tage de rigtig valg inden for it, hvis man vil overleve. En forkert it-beslutning på strategisk niveau kan lukke virksomheden.

Softwareudvikling er dermed ikke længere er et bestillingsarbejde, men noget der udvikles i tæt sammenhæng med forretning og praksis, hvilket gør softwarearkitekten til en aktiv del af at skabe forretning.

Traditionelt set har det været forretningen og ledelsen, der har fortalt arkitekterne, hvad de skal gøre, men de kender ikke nødvendigvis den teknologiske udvikling i detaljer. Omvendt kender arkitekten ikke forretningen. Derfor er der behov for et meget bedre samarbejde.

Softwarearkitektens rolle er ændret

Et andet aspekt af at designe til forandringer er, at nogle beslutninger godt kan være rigtige, når de bliver taget, men når økosystemet med tiden ændrer sig, er beslutningen måske ikke optimal mere. Det er derfor vigtig, når softwarearkitekten fx skal tage stilling til integrationen til eksterne systemer og vurdere, hvilken metode der passer bedst, at han få input og informationer med på en systematisk måde, så de kan evalueres igen, når det bliver relevant.

Som regel har systemerne nemlig en længere levetid end de projekter og projektteams, som designer og vedligeholder dem.

Det er derfor sandsynligt, at beslutninger, som bliver taget i dag, bliver evalueret og revideret af andre personer i fremtiden. Softwarearkitekten skal derfor kommunikere til fremtiden og ikke kun til kollegaerne på det tidspunkt, hvor beslutningerne blev taget.

Som følge af den måde, man udvikler software på i dag, er softwarearkitektens rolle således både udfordret og ændret.

En vigtig del af denne rolle er at kunne balancere mellem de rigtige tekniske beslutninger og de forretningsmæssige og organisatoriske aspekter af softwaresystemer. Det vil sige at være en teknologisk ekspert, der samtidig forstår det bredere billede og får systemerne til at repræsentere dette billede korrekt.

Kort sagt skal softwarearkitekten analysere og evaluere forskellige typer af valg og tilpasse sig begrænsninger fx i forhold til brug, integration og lovgivning. Men han skal også vurdere, om en beslutning fx kan komme til at koste mere i fremtiden og introducerer teknisk gæld.

Relateret indhold

Kommentarer (3)

Kommentarer (3)
Jesper Louis Andersen

Desværre har de sidste 20 års IT medført at vi har dræbt protokollerne til fordel for API'er. Det gør det langt sværere at bygge softwaresystemer som organismer, fordi API'er ofte tætbinder systemet i meget høj grad. Hele grundideen, at jeg kan udskifte et system bag en protokol modulært, er ligesom forsvundet.

Men jeg mener vi skal tilbage til de ideer, og jeg mener også at Manikas rammer hovedet på sømmet: software er langt tættere på biologi end brobygning.

Christoffer Kaspersen

Nu er jeg ikke just IT-ekspert, men har længe følt området var spændende set ud fra arbejdsmarkedets øjne. Og fra det synspunkt er det jo fedt med det store disruptionpotentiale (se blot på AirBnB, Uber, og sågar de danske hentpriser.dk og pricerunner.dk).

Med det sagt kommer det også konstant bag på mig hvorfor der (mere eller mindre) altid er IT-problemer rundt om i landet, det kan måske have noget med denne udvikling at gøre

Log ind eller opret en konto for at skrive kommentarer