Når man kjører flere slike prosjekter samtidig og over lengre tid med betydelig antall ressurser blir det aktuelt å tenke litt større og legge en strategi for hvordan informasjon skal flyte og behandles på tvers av organisasjonen.

Med modulbasert utvikling kan man utføre prosjekter med mange personer, gjerne delt i flere grupper. Det kan gjerne sees på som et bestiller- og leverandør-forhold, eller “klient og tjener”, hvor klienten definerer hva som forventes av den andre modulen å ta i mot og returnere av data og på hvilke formater utvekslingen skal foregå.

Moduler kan integreres i systemer via kompilatorlenking mot definerte grensesnitt, som funksjonssignaturer i et “interface” fra objektorientert programmering eller en “header”-fil, eller med meldinger som sendes på en meldingsbuss. Å binde seg til et definert grensesnitt har fordeler med at man kan få en kompilator til å sjekke gyldigheten av kontrakten, at man snakkes felles språk, men det gjør det vanskeligere dersom en av partene har andre behov og trenger å endre en funksjonssignatur.

Meldingsbasert integrasjon defineres på et høyere nivå enn ved funksjonssignaturer, for eksempel at grensesnittet bare definerer hvordan meldingen kan sendes og hvordan svaret kan mottas. Ulempen med meldingsbasert kommunikasjon er at det stiller høyere krav til validering, versjonering og bakoverkompatiblitet, siden en av partene kan oppgraderes til nyere versjon mens det finnes andre systemer som fremdeles snakker det gamle språket. Ved meldingsbasert kommunikasjon bør det skrives en spesifikasjon for formatet på meldingene, for eksempel i form av et XSD-skjemadokument dersom kommunikasjonen pakkes som XML-meldinger, eller Protocol Buffers hvis meldingene er mindre og tydelig definerte.

For enklere systemer holder det kanskje med et format på forespørsler ala: customer search 'ola normann' hvor “customer” kan være navnet på modulen, “search” kan være funksjonen i modulens grensesnitt og “ola normann” er parameteren til funksjonen. Responsen kan for eksempel være kolonne- og radbasert, som et regneark.
Mange muligheter!

Internett kan sees på som et modulbasert system. Veldig forenklet så kan nettleseren, altså klienten i vårt tilfelle, sende en forespørsel mot en adresse eller filsti til en webserver, altså tjeneren, som kan svare med et HTML-dokument. Det ligger en kontrakt til grunn om et felles grensesnitt som gjør at denne kommunikasjonen fungerer, og en slik kontrakt er HTTP-spesifikasjonen. Det er mulig å basere internkommunikasjon i sitt modulbaserte system over HTTP med for eksempel SOAP, Corba, REST, Thrift, for å nevne noen teknikker. Denne type meldingsbasert kommunikasjon har noen svakheter, blant annet krever det ekstra dataprosessering for å oversette objekter og datastrukturer til og fra meldinger som kan sendes over HTTP. Dette er også dens store fordel, da modulene kan lager i forskjellige programmeringsspråk og kjøre på forskjellige plattformer.

For å oppnå en smidig integrasjon mellom modulene trengs det presis og hyppig koordinering på tvers av utviklingsgruppene. Man må ta et steg tilbake for å få et overblikk over systemet som helhet.

Dette er i hovedsak en liten rant jeg skrev i 2011, og jeg mener den fortsatt holder vann – men ta den gjerne med en klype salt…

CSS og Javascript er også programmeringsspråk og bør behandles således.

Kode kjører i forskjellige miljøer, enten det er på en web-server, i en virtuell maskin, en applikasjonsserver, i nettleseren eller instruksjoner som dynamisk bygges opp og sendes til eksekveringsmotorer som gjør en jobb og sender ferdig prosessert data tilbake. Det kan være preprosessorer som ved kompilering skriver om deler av programkoden.

Dette er noe å tenke på når man strukturerer opp prosjektet i kataloger og filer.

Forskjellige programmeringsspråk krever forskjellige strategier

Noe man kanskje ikke tenker så mye på mens man forsøker å konfigurere opp prosjektet til å kjøre Java-testene eller kompilere C-fila, er at en løsning ofte består av flere enn ett programmeringspråk. Om man utvikler web-løsninger er CSS og Javascript blitt en selvfølge. CSS og Javascript er programmeringsspråk og bør behandles således.

Javascript er et nesten like gammelt språk som Java, men det er først de siste årene at tradisjelle utviklere har fått øynene opp for hva som er mulig med Javascript. Desto mer man gjør i Javascript desto større er behovet for å teste funksjonaliteten. Det er fullt mulig å kjøre automatiserte enhetstester mot Javascript-kode, og det finnes verktøy for å detektere typiske feil og påpeke klassiske fallgruver. Det finnes også verktøy for å minifisere Javascript slik at filene blir mindre og legger mindre beslag på båndbredden til brukerne av systemet, og ikke minst like viktig er at det kan spare kostnader ved å senke krav til båndbredde fra systemet. Tilsvarende finnes det verktøy for CSS som minifiserer filene og som kan analysere filene og detektere ineffektive regler og duplikate regler som aldri inntreffer.

Retningslinjer

Mange programmeringsspråk har anbefalinger til hvordan programkode skal struktureres. Om systemet som skal lages hovedsaklig skal skrives i ett programmeringsspråk kan man følge dette språkets retningslinjer. I retningslinjene defineres gjerne hva en typisk fil skal inneholde, navngiving, indentering, kontrollkode, feilhåndtering, hvordan filene plasseres i en katalogstruktur og mye annet. Perl-prosjekter struktureres ofte etter CPAN sine retningslinjer, PHP-prosjekter struktureres ofte etter PEAR sine retningslinjer og Java har sine retningslinjer.

En by bygger seg ikke selv. Foto: Flickr/Science Museum London (CC)

Det har de siste årene blitt populært å bruke Maven som kontrollsystem for prosjekter, spesielt for Java-prosjekter, men kan også brukes til andre programmeringsspråk som PHP og Javascript. Man bruker gjerne Maven som en innpakking av prosjektet, til bygging av systemet, kjøre tester, pakketere og rulle ut nye versjoner. Det legger ingen føringer for hvordan man strukturerer innholdet av filer i prosjektet.

Det er ingen fasit når det kommer til struktur av prosjekter, men dersom man er flere som arbeider på samme prosjekt kan det være smart å bli enige om hvilke retningslinjer man skal følge.

Ikke all kode er programkode

Tester skal støtte oppunder løsningen og gi en god og stabil leveranse.

Den viktigste delen av løsningen er det kjørbare systemet, og det er dette som skal gi merverdi til bedriften. Dokumentasjon, tester, byggerammeverk og utviklingsmiljø er biprodukter; støttefunksjoner som skal bidra til å gi et godt og kjørende system.

Maven brukes, som nevnt ovenfor, gjerne til bygging av løsningen og til å kjøre opp web-server under utvikling, men Maven er ikke en del av det kjørbare systemet i leveransen.

Tester, som enhetstester og funksjonstester, er ikke programkode og trenger ikke behandles som det. Tester skal støtte oppunder løsningen og gi en god og stabil leveranse. Tester bør holdes utenfor katalogstrukturen til programkoden. Det kan være løsere retningslinjer til testene, for eksempel friere navngiving av tester, ingen maksimal linjelengde eller flatere katalogstruktur.

Testene dine er viktige fordet!

En god test er en verifikator om at en funksjon fungerer. En god test er presis på hva den tester og er lett å lese og forstå.

En god praksis er å navngi testene etter hva de tester. Et eksempel kan være en test som skal teste at en kunde som heter “Ola” har adresse “Drammensveien”, og denne testen kan da hete test_kunden_ola_har_adresse_drammensveien, selv om dette ikke stemmer overens med for eksempel Java’s camelcase.

En testfunksjon skal teste en ting, og kun én ting. Du trenger ikke å teste at du har korrekt brukernavn og passord i konfigurasjonen for hver eneste test du skriver. Hvis navnet på testen indikerer at en brukers adresse skal kontrolleres så skal testen gjøre det, og lite annet. Samme testen kan gjerne teste forskjellig input dersom det virker hensiktsmessig. For eksempel kan en e-postadresse-validator kontrollere flere godkjente e-postadresser, men kanskje bør det være en egen testfunksjon for verdier som skal feile valideringen.

Samhandling med andre arkitekturprinsipper

Det er mulig å kombinere struktur på utviklingsmiljøet med andre arkitekturvalg. For enkle web-løsninger er trelagsarkitekturen MVC (model-view-controller) populær, hvor man skiller applikasjonslogikk fra datamodell og presentasjon, og man kan plasserer filer i en katalog navngitt etter laget hvor de hører hjemme.

Hvis prosjektet setter domenedrevet design høyt så kan det være smart å segmentere ut filene som utgjør domenemodellene i egne kataloger, for å holde domenet samlet uten for mye støy fra annen kode.

En felles hverdag

Det er smart å ha orden i prosjektet sitt. Kildekoden til prosjektet kan sees på som skrivebordet ditt; hvis det er vanskelig å finne det du leter etter så er ikke arbeidsmiljøet optimalt. I et prosjekt med mange utviklere betyr dette at alle deler “felles skrivebord”. Å sette retningslinjer som alle i prosjektgruppen enes om å følge kan bidra til en ryddigere hverdag for alle, men retningslinjene bør ikke blir detaljerende og vanskelige å følge. Alle skal føle seg komfortable med disse.

Det er en felles hverdag. En god struktur bidrar til raskere utvikling, enklere feilsøking, og etterhvert til bedre kode med færre feil.

Puslespill (Puzzle). Foto: Flickr/create_joy (CC)

Utenfra fungerer en modul som en sort boks; man gir beskjeder inn og man får svar tilbake. Man vet ikke hvordan den sorte boksen kommer frem til svaret. Det gjør det enklere å forholde seg til støttefunksjoner, så man kan fokusere på den funksjonaliteten man skal lage. Jeg kaller det støttefunksjoner fordi disse funksjonene ikke er viktige; eller rettere sagt så er funksjonaliteten man arbeider med for øyeblikket mye viktigere enn en hvilken som helst annen annen modul.

Vedlikeholdbarhet

Behovet for modulbasert arkitektur oppstår når systemer blir for store til at én eller to personer kan ha oversikt over hele systemet. Da blir det viktig med vedlikeholdbare moduler av håndterbare mengder med kode.

Vedlikeholdbarhet betyr ikke at koden til stadighet må endres, noe som faktisk fungerer mot sin hensikt. Dersom modulen endres for ofte med for store endringer kan det innføre feil. Mye ny funksjonalitet kan gjøre modulen uoversiktlig og mindre vedlikeholdbar. En vedlikeholdbar modul bidrar til at resten av systemet får en tydelig måte å kommunisere med modulen på, og dersom man støter på feil så skal man klare å fikse feilen.

Eksempel på modulbasert løsning

Et svært enkelt og overordnet eksempel på en modulbasert nettbutikkløsning

Kjernen av MyWebShop kommuniserer mot eksterne komponenter over definerte grensesnitt. Det er ikke sikkert at alle komponenter har grensesnitt basert på åpne standarder, som SQL, SMTP og HTTP. Det kan være behov for å definere nye grensesnitt i bedriften. For eksempel kan kommunikasjon mot et CMS-system skje via et nytt grensesnitt vi kaller ProductService som tilbyr funksjoner som er nyttige for vår nettbutikk. På denne måten definerer vi tydelig hvilke funksjoner nettbutikken har behov for, samtidig som vi skjuler andre funksjoner som CMS-systemet tilbyr som ikke er viktige for vårt system.

Når kommunikasjon mellom moduler foregår over definerte grensesnitt, så kan moduler byttes ut med ny moduler ved behov. For eksempel kan modulen My Simple CMS byttes ut med et mer avansert og bedre CMS-system dersom nettbutikken vår blir større og får nye behov som den gamle modulen ikke kan tilby. Om den nye modulen ikke støtter det samme grensesnittet som den gamle kan man lage et veldig lite oversettingslag, kalt for et adapter, som oversetter mellom vårt eget ProductService-grensesnitt og den nye modulen.

Samhandling

Et ofte brukt tilfelle av modulbasert programvare er når data skal behandles i flere ledd. Samme grensesnitt kan brukes i front av flere forskjellige moduler. For eksempel kan et spamfilter kobles på foran e-posttjeneren slik at e-post kan filtreres før det lagres i brukerens innboks, og uønsket e-post kastes uten at brukeren ser e-posten. Fordelen med modulbasert arkitektur er klar, man får et mer oversiktlig system med komponenter som kan settes sammen og byttes ut ved behov.

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?

Om å skape orden

Arkitektur er teknikker som skal hjelpe mennesker til å forstå kompliserte systemer, som igjen skal få kompliserte systemer til å virke bedre sammen, være raske, mer feiltolerante og enkle å bruke. Resultatet skal bli et enklere system. Det strømlinjeformer enkelte prosesser av systemene og skal hjelpe til med å gjøre systemene mer vedlikeholdbare.

Det er flere måter å komme fram til en arkitektur. Jeg har selv gått i fella, flere ganger – man velger en arkitektur for tidlig i prosjektet. Det er lett å gå seg blind i arkitektur når man hører at man trenger ting som Scrum, MVC, Cloud Computing, skyen, SaaS, SOA og ESB, buzzwords brukt av selgere for å selge inn produkter og tjenester. Løsningen er å ikke låse seg til en arkitektur til å begynne med, før man egentlig vet hva man skal lage.

En arkitektur utvikler seg over tid mens man arbeider målrettet med prosjektet og målrettet jobbet mot målet med prosjektet er. Det er alltid en smartere måte å løse et problem på, man bare vet ikke om det ennå.

Evolusjon (evolution) Foto: Flickr/Esthr (CC)

Innfallsvinkler

Arkitektur finnes på flere nivåer. Man ser på arkitektur fra forskjellige innfallsvinkler. Som utvikler tenker jeg gjerne på hvordan koden er strukturert, gjerne i moduler strukturert i hver sine kataloger, på objekter med arv av abstrakte klasser og grensesnitt og hvordan kommunikasjonen mellom to systemer på nettverket skal foregå. En driftsperson tenker mer i retning av hvilke servere tjenestene skal kjøre på, i hvilke nettverkssoner, regelsett i lastbalanserer, feilhåndtering og backup. Ledelsen ønsker gjerne at utviklingsteamet skal være agile og kunne snu seg raskt ved endringer, men man ønsker også stabilitet og forutsigbarhet. En optimal arkitektur koster mye, ofte mer enn man er villig til å investere i prosjektet.

Wikipedia nevner følgende innfallsvinkler til arkitektur:

• Funksjonell og logisk
• Programkode og modulbasert
• Utvikling og strukturelt
• Kjøremiljø, samtidighet, prosesser og tråder
• Komponenter, fysisk utplassering, utrulling og installering
• Brukerinteraksjon og tilbakemeldinger
• Data og datamodell

Jeg vil igjennom en serie med innlegg berøre disse arkitekturtemaene nærmere.

Dersom du bare er interessert i å lese om arkitektur kan du følge arkitekturfeeden.