”Software skal ses som en levende organisme”

Den tid er for længst forbi, hvor man kunne udvikle software, som man bygger broer. Softwareudvikling skal ikke ses som legoklodser, der sættes sammen. Derimod skal software ses som en levende organisme, og softwareudvikling som en organtransplantation, mener underviser på kurset Softwarearkitektur, Konstantinos Manikas.

Efteruddannelseforretningsoftware

Skrevet 3. august 2017 09:32 af Ninna Gandrup

Software er blevet en levende størrelse, som har mange liv i forskellige sammenhænge.

Konstantinos Manikas, ekstern lektor og underviser på kurset Softwarearkitektur

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.

- Software er blevet en levende størrelse, som har mange liv i forskellige sammenhænge. I dag er der kun enkelte systemer, som er bygget fra bunden af et team, men i bund og grund er det ikke længere muligt at udvikle, som man gjorde for 20-30 år siden. 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, siger Konstantinos Manikas.

Softwaresystemer er levende organismer, der er afhængige af hinanden
Softwaresystemer kan således sammenlignes med forskellige arter i et økosystem, hvor den ene arts overlevelse og trivsel afhænger af overlevelsen af hele økosystemet.

Moderne softwaresystemer kan sammenlignes med levende organismer, der integrerer til og integreres i mange andre systemer. Lidt ligesom en organtransplantation, hvor organerne skal fungerer sammen for at organisme kan overleve.

Konstantinos Manikas, ekstern lektor og underviser på kurset Softwarearkitektur

- Moderne softwaresystemer kan sammenlignes med levende organismer, der integrerer til og integreres i mange andre systemer. Lidt ligesom en organtransplantation, hvor organerne skal fungerer sammen for at organisme kan overleve, fortæller Konstantinos Manikas.

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. Derfor er en vigtig faktor i valget af smartphones også antallet af apps, som understøttes af telefonens styresystem.

- Hvis morgendagens iPhone kun kunne understøtte halvdelen af de apps, som den kan i dag, ville jeg 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, siger Konstantinos Manikas.

Hastigheden stiller store krav til arkitekter og udviklere
Time-to-market er blevet et afgørende parameter, som aldrig har været vigtigere for konkurrencen, end det er nu. Det betyder også, at beslutninger skal tages meget hurtigere end tidligere. Som softwarearkitekt skal man både 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 man skal også designe systemer til forandring.

Design af arkitektur bør også omfatte et tidsaspekt, hvilket vil sige, hvordan systemet forventes at udvikle sig i fremtiden.

Konstantinos Manikas, ekstern lektor og underviser på kurset Softwarearkitektur

- Hastigheden i udviklingen har medført, at forandring er i fokus, og evnen til at omstrukturere et system hurtigt med lave omkostninger er blevet en konkurrencefordel, fortæller Konstantinos Manikas.

- Design af arkitektur bør også omfatte et tidsaspekt, hvilket vil sige, 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. Arkitektonisk gæld 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, fortæller Konstantinos Manikas.

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, skal man ikke træde på eksterne aktører. Det vil sige, at systemet skal kunne understøtte integrationen af stadigt flere eksterne systemer, og evnen til at understøtte dette ”by design” kan være afgørende for et systems succes.

Større fokus på forretningen
Den øget hastighed i systemudviklingen gør, at design- og arkitekturbeslutninger skal tages på langt kortere tid end tidligere, og disse beslutninger er ikke blevet mindre afgørende for forretningen og produktets succes. Softwareudvikling er dermed ikke længere er et bestillingsarbejde, men derimod noget der udvikles i tæt sammenhæng med forretning og praksis. Det betyder også, at softwarearkitekten bliver en aktiv del af at skabe forretning.

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.

Konstantinos Manikas, ekstern lektor og underviser på kurset Softwarearkitektur

- It bliver en stadigt mere afgørende del af forretningen i flere og flere brancher i stedet for blot at være et værktøj. Virksomhedens 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, forklarer Konstantinos Manikas.

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.

- 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. Dertil kommer, at softwarearkitektens arbejde også er reguleret af fx lovgivning, som ændrer sig løbende og skal overholdes i forskellige sammenhænge, fortsætter Konstantinos Manikas.

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 har betydning for softwarearkitektens arbejde.

Softwarearkitekten skal derfor kommunikere til fremtiden og ikke kun til kollegaerne på det tidspunkt, hvor beslutningerne blev taget.

Konstantinos Manikas, ekstern lektor og underviser på kurset Softwarearkitektur

- Når softwarearkitekten fx skal tage stilling til integrationen til eksterne systemer og vurdere, hvilken metode der passer bedst, er det vigtigt at få input og informationer med på en systematisk måde, så man kan evaluere det igen, når det bliver relevant. Som regel har systemerne 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, siger Konstantinos Manikas.

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 således 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, slutter Konstantinos Manikas.