Hvad er IT-arkitektur?

IT-arkitektur er disciplinen at designe sammenhængen mellem hardware, software, data og processer. Hvor et enkelt system løser én opgave, beskriver arkitekturen, hvordan alle systemer arbejder sammen, og hvordan de kan skaleres, sikres og vedligeholdes uden at bryde sammen.

En brugbar tommelfingerregel: hvis beslutningen er svær at rulle tilbage om to år, er den arkitektur. Valget af databasemodel, hvordan systemerne integreres, og hvordan netværket er segmenteret, er arkitektur. Valget af skrifttype på en knap er det ikke.

• 1. Infrastruktur: Servere, netværk, routere, firewalls og backup-forbindelser. Fundamentet, alt andet hviler på.
• 2. Data: Databaser, datamodeller og hvordan information flyder mellem systemer. Bestemmer hvad I kan måle og automatisere.
• 3. Applikationer: De programmer og webplatforme jeres medarbejdere og kunder bruger til daglig.
• 4. Integration: API'er og workflow-automatisering, der binder alt sammen, så data ikke skal flyttes manuelt.

Hos OLSync arbejder vi med alle fire lag: netværksdrift, hjemmesider, workflow-optimering og automatisering. Lagene hænger sammen: en hurtig hjemmeside hjælper ikke, hvis netværket bag den mangler failover.

Forestil jer en dansk produktionsvirksomhed med 40 medarbejdere, to lokationer, et ERP-system, en webshop og et lagerstyringssystem. Ordrer kommer ind i webshoppen, bliver tastet manuelt i ERP'et, og lagerstatus opdateres i et regneark hver morgen. Der er én internetforbindelse pr. lokation og backup på en ekstern harddisk.

Hvert enkelt system fungerer. Arkitekturen gør ikke. Dobbeltindtastning giver fejl i ordrer, lagertal er altid en dag bagud, og en enkelt afbrudt fiberforbindelse stopper produktionen. Løsningen er sjældent nye systemer, men et arkitekturarbejde: integration mellem webshop og ERP, ét autoritativt datalager for lagerbeholdning, redundant internet med automatisk failover og overvåget backup.

Resultatet er målbart: færre fejlordrer, lagertal i realtid og en driftsstabilitet, der ikke afhænger af, at én person husker at kopiere et regneark.

Dårlig arkitektur viser sig sjældent som ét stort nedbrud. Den viser sig som langsomme hjemmesider, systemer der ikke taler sammen, manuelle Excel-ark mellem afdelinger, og en mistanke om at "noget brænder hele tiden". Gennemtænkt arkitektur fjerner de flaskehalse, og gør jer i stand til at vokse uden at jeres it-omkostninger eksploderer.

Konkret betyder god IT-arkitektur:

• Færre nedbrud, fordi failover er tænkt ind fra start.
• Hurtigere hjemmesider og applikationer, fordi koden er let og målrettet.
• Lavere driftsomkostninger, fordi I ikke betaler for unødvendige lag.
• Mulighed for automatisering, fordi data flyder fejlfrit mellem systemer.
• Bedre sikkerhed, fordi adgang, backup og overvågning er designet, ikke lappet på.

• 1. Integrationer bygget ad hoc. Hver ny forbindelse laves som en engangsløsning, indtil ingen kan overskue, hvad der sker, hvis ét system opdateres.
• 2. Ingen autoritativ datakilde. Når tre systemer hver har deres version af kundedata, er ingen af dem korrekt.
• 3. Backup uden test. Backup, der aldrig er gendannet i en test, er en antagelse, ikke en sikkerhed.
• 4. Enkelte fejlpunkter. Én forbindelse, én switch eller én server, hvor et nedbrud stopper hele driften.
• 5. Manuelle led i kritiske processer. Alt der kopieres i hånden, bliver på et tidspunkt kopieret forkert. Det er præcis her workflow-automatisering giver hurtigst afkast.

1. Kortlæg nuværende tilstand. Alle systemer, forbindelser, integrationer og manuelle led tegnes op på ét diagram.
2. Find flaskehalse og risici. Hvor opstår fejl, hvor ventes der, og hvad vælter driften, hvis det falder ud?
3. Beskriv målbilledet. Hvordan skal data flyde, når det er løst, uafhængigt af nuværende leverandører.
4. Prioritér efter effekt. Start med det, der fjerner mest risiko eller mest manuelt arbejde pr. investeret krone.
5. Byg i etaper og mål. Hver etape skal kunne stå alene og dokumenteres med driftstal.
6. Sæt drift og overvågning på. Arkitektur er ikke et projekt, der slutter, det er noget, der vedligeholdes.

Standardplatforme og tunge skabeloner er hurtige at komme i gang med, men de skalerer sjældent med jeres forretning. På et tidspunkt tvinger de jer til at tilpasse jeres processer til softwaren, i stedet for omvendt. Skræddersyet arkitektur tager udgangspunkt i jeres specifikke workflow, integrationer og datakrav, og bygger kun det, der reelt skaber værdi.

Helst før I køber det næste system. Men i praksis er det bedste tidspunkt at kigge på arkitekturen, når noget af følgende sker: I skifter ERP, I åbner et nyt kontor, I oplever gentagne nedbrud, eller I bruger mere tid på at flytte data manuelt end på at analysere dem.

En IT-arkitekt beslutter, hvordan tingene skal hænge sammen, inden de bygges. Ikke hvilken knap der skal sidde hvor, men hvilke systemer der ejer hvilke data, hvordan de taler sammen, hvor grænserne går, og hvad der skal kunne skiftes ud senere uden at rive resten med.

I større organisationer er det en fuldtidsrolle, ofte delt op i enterprise-, løsnings- og integrationsarkitekter. I en mindre virksomhed findes rollen sjældent som en stilling. Den bliver i praksis varetaget af den, der køber systemerne, og beslutningerne bliver derfor truffet én ad gangen, uden at nogen holder øje med helheden. Det er ikke inkompetence, det er en manglende funktion.

Det praktiske arbejde ser typisk sådan ud: kortlægge det der er nu, finde de steder hvor to systemer er uenige om sandheden, udpege de enkeltpunkter der kan vælte driften, og lægge en rækkefølge for hvad der skal laves om først. Den vanskelige del er sjældent teknikken. Den er at sige nej til den løsning, der ser bedst ud på en demo, fordi den binder alt sammen i én leverandør.

De tre begreber bruges i flæng, også af folk der sælger dem, og det gør det svært at vide hvad man køber. Forskellen er niveauet:

Systemarkitektur

Hvordan ét system er bygget indeni: dets moduler, database og lag. Relevant når I får bygget noget skræddersyet, men siger intet om resten af huset.

Integrationsarkitektur

Hvordan systemerne udveksler data: hvilke integrationer der findes, hvilken vej data løber, og hvem der ejer sandheden når to systemer er uenige. Det er her de fleste smerter sidder i en mindre virksomhed.

IT-arkitektur

Niveauet ovenover begge: netværk, data, applikationer og integrationer set som ét hele, inklusive hvordan det skal kunne udvikle sig. Det er den her, der afgør om I kan skifte ét system ud om tre år uden at rive tre andre med.

"Moderne IT-arkitektur" betyder i praksis oftest to ting: at systemerne udveksler data gennem dokumenterede grænseflader frem for manuelle eksporter, og at ingen enkelt leverandør kan låse jer fast. Ikke at alt skal ligge i skyen.

API

En aftalt grænseflade, som to systemer bruger til at udveksle data automatisk.

Failover

Automatisk skift til en reserveforbindelse eller reserveserver, når den primære fejler.

Redundans

At kritiske dele findes i mere end ét eksemplar, så et nedbrud ikke stopper driften.

Segmentering

Opdeling af netværket i zoner, så en kompromitteret enhed ikke får adgang til alt.

Autoritativ datakilde

Det ene system, der altid har den korrekte version af en given oplysning.