Som jeg skrev i introduksjonenen til IT-arkitektur så finnes det flere innsynsvinkler til dette temaet. Hva er så mer logisk enn å starte med logisk arkitektur? Det handler om funksjonaliteten, det viktigste i et IT-system og den viktigste årsaken til at IT-prosjekter settes i gang!
Et IT-system skal løse et behov for virksomheten, eller kunden som vi kaller det. Kunden har mange behov, men man avgrenser gjerne systemet til å løse et subsett av disse behovene. Vi kaller dette for problemdomenet.
Målet med logisk arkitektur er å styrke de funksjonelle kravene, og veien til en god logisk arkitektur kan være lang. Kunden vet ikke hva det egentlige behovet er, og har ofte sin en oppfatning om hvordan løsningen skal se ut. Utviklere blir ofte veldig engasjerte og starter å lage noe de selv synes virker kult istedenfor å grave og analysere i kundens egentlige problemer.
South Park Gnomes plan
Verktøy
Det finnes flere verktøy for å analysere seg fram til en god logisk arkitektur. For å definere de funksjonelle kravene kan man skrive brukstilfeller (use cases på engelsk) som definerer hvilke brukere eller roller som skal utføre hvilke steg i en prosess for å ende opp med et ønsket resultat. Dette avdekker alternative valg som brukeren kan gjøre, for eksempel hva som skjer hvis brukeren taster en ugyldig verdi inn til systemet eller avbryter midt i prosessen. Dette dokumentet brukes for å måle om funksjonaliteten som ble avtalt er implementert og fungerer. Dette skaper en målbarhet som er viktig for at både kunde og leverandør (prosjektgruppen) skal ha felles forståelse for hva som lages og hva som er levert.
Det finnes også verktøy for å visualisere systemer, og UML er en notasjon for å visualisere systemer. Det kan visualisere brukstilfeller, flyt av data og koblinger mellom komponenter, valgmuligheter underveis i prosesser og tilstand til komponenter under gitte kriterier. Det finnes flere aspekter man kan visualiere med UML, men de nevnte er hovedsaklig de viktigste innenfor logisk arkitektur. Det handler om å modellere domenet, og komponentene navngis ofte etter begreper som brukes i virksomheten.
Domenedrevet design
En teknikk som jeg har fått sansen for er domenedrevet design (DDD), hvor fokuset rettes mot problemdomenet og det viktigste er å ha en god og dyp domenemodell på et felles språk. Dyp i at den reflekterer virksomhetens problemområde best mulig og med felles språk på tvers av programkode og de daglige funksjoner i virksomheten.
For å skape et felles språk som alle i prosjektet kjenner til og forstår betydningen av, så bør man lage en ordbok som alle gjør seg kjent med. Alle begreper fra domenemodellen bør legges inn i en slik ordbok. Ordboken skal være fri for systemtekniske begreper og skal forstås av domeneekspertene; de som kjenner virksomhetens funksjoner best.
Eksempel på domenemodell
Nedenfor vises et eksempel på en domenemodell av et bloggsystem. Det anbefales å skrive en kort tekst til figurene, da det ikke alltid er lett å forstå meningen bak en tegning. Dette er bare én av mange måter å visualisere et problem på.
Eksempel på domenemodell for en blogg
Når man får dypere forståelse av domenet lager man en ny tegning som enten erstatter en gammel tegning eller som kan supplere en eksisterende tegning. Dersom kunden fra eksempelet over også ønsker at leserne skal kunne abonnere på en strøm av blogginnlegg, så kan man lage en ny tegning som viser et søk som mates inn i en nyhetsstrømgenerator (i mangel av bedre ord).
Det finnes ingen fasit på logisk arkitektur. Alle konkurransedrevne virksomheter har særegne behov, noe de trenger for å kunne konkurrere og skille seg ut i markedet. Nettopp derfor er logisk arkitektur trolig det vanskeligste å forstå og gjennomføre innenfor IT-arkitektur.
Lykke til med neste prosjekt! Etter å ha lest dette setter du deg selvfølgelig dypere inn i kundens virksomhet og avgrenser systemets oppgaver til å løse kundens konkrete problem – ikke sant?