Pas på afhængighederne

Jeg har igennem min karriere primært arbejdet med større systemer, ofte i form af portaler, hvor der har været en del integrationer til andre systemer. I mange tilfælde har disse andre systemer været under udvikling samtidig med det system som jeg har været involveret i.

Dette betyder med andre ord, at jeg ofte har været involveret i projekter med afhængighed til andre projekter.

Følgende figuren er et forsimplet eksempel på hvordan dette kunne se ud.

Illustration af afhængigheder mellem systemer

Afhængigheder mellem systemer

Hvert element i figuren er et selvstændigt system, som udvikles i sit eget projekt, mens pilene imellem dem angiver integrationspunkter.

Figuren er som sagt meget forsimplet, men det giver forhåbentligt et indtryk af konceptet.

Der er ofte nogle krav til hvornår de forskellige integrationer skal være klar, således at den tværgående integration og test af denne kan foregå i tide til at systemerne kan nå i produktion til den valgte deadline.

Problemet er at der desværre alt for ofte ikke bliver aftalt i hvilken rækkefølge integrationerne skal implementeres i. Dette gør at hvert projekt ofte kommer til at sub-optimere rækkefølgende af opgaver i forhold til deres eget projekt, men ikke får tænkt på helheden på tværs af projekter.

Det betyder at hvis man ser på status på projekterne på et givet tidspunkt, kunne det se således ud:

Implementeret

Implementeret funktionalitet i hvert projekt

De grå-skalerede områder angiver implementeret funktionalitet.

Som det kan ses, betyder det at projekterne ikke har fokus på de samme områder i forhold til funktionalitet.

Hvis man vil skitsere det lidt tydeligere, kan følgende figur måske give et indtryk.

Reelt implementeret

Implementeret funktionalitet på tværs af projekter

Her er de grå-skalerede områder stadigvæk den implementerede funktionalitet, mens de rødskalerede områder er den funktionalitet som reelt er implementeret på tværs af systemerne.

Det er et markant mindre område, hvilket betyder at det er en meget lille del af den samlede integration mellem systemerne som kan testes, selv når hvert projekt har implementeret forholdsvist meget funktionalitet i deres eget system.

Det er den slags manglende koordinering som leder til ”big bang” integrationstest, hvor den samlede integration først kan testes til sidst, med al den smerte som den slags giver til de involverede projekter og personer.

Hvis man i stedet sørgede for at få koordineret arbejdsindsatsen mellem projekterne, vil det gøre det muligt løbende at teste implementeringer, med løbende tilretninger som følge.

Igen er dette forsimplet, men hvis man antager at arbejdet i projekterne var blevet koordineret, ville det, alt andet lige, kunne betyde at figuren for implementeringen kunne have set sådanne ud:

Potentiel implementeret

Potentielt implementeret funktionalitet på tværs af projekter

Her er der stadigvæk funktionalitet som er implementeret i de enkelte projekter som ikke kan testes på tværs af systemerne, men det er meget færre, og det vil faktisk være muligt at afslutte arbejdet med det ene system (det øverste, til højre), da testen på tværs af systemerne kan gennemføres.

Så, hvis man er projektleder, arkitekt eller på anden vis har indflydelse i et projekt som skal implementere et system, og som har afhængigheder til andre projekter, vil jeg anbefale at man sørger for at koordinere ikke blot datoer for deadlines, men også rækkefølgende af arbejdet. Dette gør at det bliver meget nemmere at løbende teste systemerne, i stedet for man skal igennem en ”big bang” integrationstest til sidst.

1 comment for “Pas på afhængighederne

  1. Det er nogle rigtig gode pointer du har. En af mine kæpheste mht. system/service afhængigheder er at man bliver nød til både at kigge på hvordan system/service ansvarområderne (boundaries) SAMT ens arkitekturelle tilgang (f.eks. er valget af lagdelt integration – tit med en ESB i midten – virkelig det bedste?) – alt sammen med det mål for øje at skabe så lav kobling mellem services – se f.eks. https://qed.dk/jeppe-cramon/2014/02/01/soa-synkron-kommunikation-data-ejerskab-og-kobling/

    Portaler(ne) er tit der hvor dækket for alvor møder asfalten og der hvor de skæve ansvarsområder og den medfølgende feature envy viser sig. Lige som du, har jeg også set min del af portal projekter og min erfaring er at den klassiske tilgang, hvor et portal team som står i pølseenden og skal integrere X antal services til en sammenhængende helhed, oftest er en kamp der tabes fordi integrationerne altid bliver færdige forsent og oftest ikke matcher med behovene. Resultatet bliver spaghetti integration.

    Et godt gammelt citat fra Einstein siger, at definitionen på galskab er “at blive ved med gøre det samme, men forvente et anderledes udfald”. Så næste gang nogen står overfor at skulle lave en ny “portal” kunne det være en kærkommen anledning til at prøve nogle alternative mønstre/løsninger, så som consumer driven contracts eller composite applications (nogle gange også kaldet Composite UI’s). Jeg planlægger at skrive mere om Composite applications i den næste blogpost i min microservice serie.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *