Hvorfor diversitet er vigtig i din arkitektur

I enterprise arkitektur vil man normalt tilskynde, at man kun har en måde at gøre tingene på: en slags databaser, et operativ system, et kodesprog. Årsagen er, at det er mere rationelt og mere “Lean”, men der kan være gode grunde til at denne anbefaling ikke altid er optimal. Måske skal vi faktisk in nogle situationer anbefale, at der skal være flere måder at gøre den samme ting på en gang imellem.

Kan biologien hjælpe os til at bygge mere robuste informationssystemer?
I en interessant artikel publiceret i Januar i Harvard Business Review undersøger forfatterne om man ud fra at betragte firmaer som biologiske systemer kan opnå indsigter, der gør dem mere robuste i vores moderne omskiftelige verden.

Deres analyse viser at børsnoterede firmaer i dag i højere grad end tidligere går under. Helt præcist 6 gange hurtigere end for 40 år siden. Det kan også ses på, at den gennemsnitlige alder, som firmaer har når de bliver afnoteret på børsen ned er faldet fra 55 år i 1970 til 31år i 2010.

Det betyder altså at virksomheder er mere udsatte end tidligere. Derfor er det nærliggende at kigge på, hvad man kan gøre for at gøre sit firma mere robust. Her har de to konsulenter fra Boston Consulting Group Martine Reeves og Daichi Ueda allieret sig med professor i biologi fra Princeton University Simon Levin. Udgangspunktet er at kigge på et firma som en biologisk organisme bestående af ansatte og alt, hvad firmaet nu indeholder. Dette individ indgår i interaktion med en population af konkurrenter og samarbejdspartnere. Disse eksisterer i et større økosystem af andre økosystemer med hvilke de indgår i en interaktion, f.eks. staten, NGOer og det bredere samfund. Ved at kigge på, hvad der gør nogle individer, arter og økosystemer mere robuste end andre kan man få indsigt i faktorer, som potentielt kan kopieres i virksomheder.

De peger på tre strukturelle faktorer, som er kendte for at fremme robusthed og overlevelse indenfor biologien, men særligt en er interessant i denne sammenhæng: diversitet. Artiklen forholder sig ikke specifikt til informationssystemer og arkitektur, hvilket er ærgerligt da informationssystemer i høj grad i dag er skelettet i enhver virksomhed. Men diversitet kan være en vigtig strategi til at at fremme enterprise arkitekturens robusthed. Man skal dog huske på at det kommer med en omkostning, ligesom det gør i den biologiske verden. Derfor skal man selv reflektere over hvilken grad af robusthed man går efter. Det kan være man er en startup, der går efter at være en døgnflue, der bliver opkøbt om et år eller to. De kan roligt springe til en anden artikel, medmindre det er en del af deres kerne at være robuste. Omvendt kan det være at større virksomheder, der gerne vil være sikre på at blive i markedet også til næste år, kunne overveje at kigge på nogle af disse anbefalinger.

Oprethold diversitet

Diversitet er vigtigt på mange niveauer. Biologiske arter bruger diversitet til at undgå kollaps af arten. Influenza muterer og derfor er der altid en vis diversitet i arten, som gør at når vi endelig har fundet en vaccine mod de fremherskende form, er der en anden, som er en smule anderledes, der ikke påvirkes af vaccinen. Denne vinder så frem og vi starter forfra. Den risiko som diversitetsstrategien adresserer er derfor risikoen for kollaps.

Et godt eksempel fra erhvervslivet, der illustrer dette er forskellen i hvordan Fuji film og Kodak reagerede i 1990’erne, hvor det digitale kamera truede deres industri. Fuji film gik amok i opkøb af forskellige andre typer af firmaer, der dog havde noget at gøre med kemi og materialer. De opkøbte f.eks. kosmetik og farmaceutiske firmaer. Hvor industrien faldt med 90% efter år 2000, voksede Fuji film. Kodak gjorde intet udover, hvad de plejede at gøre. De gik konkurs i 2012. Fuji film omfavnede således diversiteten, som en influenza virus og overlevede industriens kollaps.

For en virksomhed handler det om at have en diversitet i folk, ideer og innovationer. Hvis vi snakker om informationssystemer er diversitet normalt ikke noget man tilråder. Vi vil normalt gerne have en platform, en leverandør, et kodesprog og generelt bare så få måder at gøre tingene på. Grunden er at jo flere forskellige måder, der er at gøre tingene på, jo flere forskellige specialister skal der ansættes. Man skal også finde flere forskellige måder at gøre det samme på for hver teknologi platform.

Lad mig give et eksempel. I forhold til databaser, så er der væsentlig forskel på hvordan Microsoft SQL server, Oracle og MySQL fungerer på i detaljen. Hvis man f.eks. skal lave en guide til at lave stored procedures. Skal man lave den tre gange i stedet for en, hvis man har alle tre. Man skal have minimum tre specialister ansat, for det er sjældent at de samme personer har dybt kendskab til alle database systemer. Dernæst skal man opgradere tre gange i stedet for en. Det er altså klart at der er en hel del overhead forbundet med diversitet på database anvendelsen. Det ville være bedre hvis man kun havde en, lad os sige f.eks. Oracle.

Hvis nu vores fiktive virksomhed der er glade og omkostningsbevidste Oracle kunder pludselig får et sagsanlæg fra Oracle fordi de mener at licensaftalen ikke er overholdt, eller at Oracle bliver ved med at skrue prisen op, så er der ikke så meget at gøre. Det kan være at denne øgede udgift kan underminere firmaet. Hvis man ikke tror, at det kan ske, kan jeg forsikre, at jeg ved selvsyn har set dette ske.

I sådan en situation er man meget bedre stillet, hvis man har andre database systemer i anvendelse. Man kan migrere til disse andre databaser og lukke alt man har af Oracle. Om ikke andet kan selve truslen hjælpe til at give en bedre pris.

Diversificer din arkitektur

Det man her skal overveje ud fra en enterprise arkitektur synsvinkel er hvilken grad af diversitet man vil have. Jo højere diversitet, jo mere robust vil arkitekturen være overfor ændringer i miljøet eller økosystemet, som man nogle gange kalder det. For at lave principper for det, bør man beslutte sig for sin diversitetsgrad, det vil sige, hvor meget diversitet man vil have. Som udgangspunkt kan man dele diversitetsgrad op i lav, middel og høj. Hvis man har en lav diversitetsgrad tilstræber man kun at have en måde at gøre noget på, f.eks. et database system. Hvis den er middel, så skal man måske tilbyde 2 forskellige måder at gøre det på og hvis den er høj kan det være 3 måder at gøre det på.

Dernæst bør man opdele sin arkitektur i områder. Disse områder skal være klart distingverbare og på et tilstrækkeligt højt niveau for at give mening. Det kunne være en traditionel trelags struktur med data, applikation og User Interface. På data laget kan en middel diversitetsgrad betyde, at man opererer med to databasesystemer, på applikationslaget kan det være to kodesprog og i brugergrænsefladen to typer af bruger grænseflader.

Risiko vurder din arkitektur

Det er vigtigt at beslutte sig for diversitetsgraden i stedet for at fokusere blindt på det, som normalt er det anbefalede, nemlig kun at have en ting af hver. For at finde den rigtige diversitetsgrad bør man lave en risikoanalyse. Den kan se forskellig ud per lag og per område. Hvis risikoen er høj kan det naturligvis betale sig at have en høj diversitetsgrad. Det kan være at man som kodesprog mener, at der sker så meget at det er meget godt at have flere forskellige måder at kode på. Hvis man nu er gået all in på ALGOL, kan det godt være man i dag ønskede sig, at man havde opdyrket en anden mulighed.

Det kan også være at man finder det usandsynligt, at der vil ske noget på et område, så skal man naturligvis vælge en lav diversitetsgrad. Det vil typisk være områder, der ikke er vitale eller, som har en etableret standard. Man behøver f.eks. nok ikke at bekymre sig om hvorvidt TCP/IP protokollen er kommet for at blive og satse på andre, just in case.

Omvendt kan der være helt nye områder, hvor der ikke er nogen etableret standard. Det kunne være på NoSQL database området, hvor der er mange leverandører. Her er der fare for at den man satser på ikke er der om et par år, eller at leverandøren blot vil være en nichespiller.

Anbefalingen er derfor at dele arkitekturen op i områder. Lave en risikoanalyse per område og tilpasse diversitetsgraden efter denne analyse. Den kan være lav, men du bør i det mindste vide, hvorfor den er lav i stedet for blot at følge den traditionelle anbefaling.