Teknologiblogg

Altfor mange bedrifter tenker i dag for kortsiktig og lite strategisk når de utvikler sine egne rammeverk. En undersøkelse utført av Matt Raible viser at det mest populære og utbredte rammeverket for selvutviklede webapplikasjoner på Java-plattformen fortsatt er ”det hjemmelage rammeverket.”

Jeg blir stadig overrasket over at dette rammeverket ikke ser ut til å gå av moten.

Begrepet rammeverk er noe upresist og har mange definisjoner – her er en fra Wikipedia:

A software framework, in computer programming, is an abstraction in which common code providing generic functionality can be selectively overridden or specialized by user code providing specific functionality. Frameworks are similar to software libraries in that they are reusable abstractions of code wrapped in a well-defined API. Unlike libraries, however, the overall program's flow of control is not dictated by the caller, but by the framework. This inversion of control is the distinguishing feature of software frameworks.

Kort oppsummert – et rammeverk legger som regel føringer på hvordan programkoden generelt sett skal struktureres, mens biblioteker er moduler som lenkes inn i programkoden der hvor man trenger funksjonalitet som noen andre har pønsket ut, implementert og testet. Når jeg sier ”som regel” så er det variasjoner i hvor invaderende et rammeverk er – noen gode rammeverk er svært fleksible, mens andre ser ut til å være bygget for å få utviklere til å marsjere i takt.

Hva er så problemet?
Man skal en være forsiktig med å skjære alle over en kam, men som regel er ett eller flere av utsagnene under sanne når det gjelder hjemmelagde rammeverk:

•    liten fleksibilitet
•    svakt design og høy grad av lock-in
•    dårlig dokumentert
•    liten erfaringsbase og begrenset tilgang til kompetanse
•    blander ofte tekniske og funksjonelle (domene spesifikke) aspekter
•    ofte designet av og for ett spesifikt prosjekt og har derav et begrenset omfang
•    en eller flere utviklere har et sterkt personlig forhold til koden

Rammeverket som startet som en veldig god idé i forbindelse med et gitt prosjekt, kan raskt utvikle seg til en rimelig kompleks og kostbar affære. Når rammeverket skal (gjen)brukes i nye prosjekter oppstår det utfordringer rundt:

•    Kompetanse og sikring av korrekt bruk av rammeverket
•    Nye krav og forutsetninger krever endringer og dermed en strukturert forvaltning av rammeverket
•    Verden går videre, og rammeverket blir ofte en hindring for å kunne ta i bruk nye trender og teknologier
•    Nødvendig forvaltning av rammeverket kan forårsake forsinkelser i prosjekter
•    De som står bak koden i rammeverket blir kritiske resurser for forvaltningen og til dels nye prosjekter som skal bruke rammeverket
•    Politikk og byråkrati i forhold til framtidsplaner for rammeverket

Summa summarum – det koster mer enn det smaker…

Hva kan vi gjøre annerledes?
Jo – vi bør enkelt og greit investere mindre i å designe og implementere hjemmelagde rammeverk. Det vi sparer inn bør vi bruke til å investere mer i å definere generiske løsningsarkitekturer som skal benyttes i prosjektene. Slike arkitekturer bør beskrive hvilke open-source og eventuelle kommersielle rammeverk som skal benyttes i løsningene, samt føringer og begrensninger i forhold til hvordan disse skal brukes.

Merk at jeg sier også løsningsarkitekturer i flertall – altfor mange interne systemer for å reservere firmahytte er bygget med samme løsningsarkitektur som de virksomhetskritiske systemene. Dette er å skyte spurv med kanoner.

Ved å differensiere mellom ulike behov, og definere ulike løsningsarkitekturer i forhold til disse behovene, så oppnår man både riktig løsningsarkitektur og kontroll med hvordan systemer av ulike kategorier implementeres.

Pr. i dag er det et rimelig bra utvalg av open-source rammeverk for de aller fleste behov og bruksområder. Ved å gjenbruke rammeverk som forvaltes av open-source samfunnet får man en stor kompetansebase og en aktiv og engasjert forvaltning med på kjøpet. Populære åpne rammeverk gjennomgår som regel en langt grundigere testing enn hva man får til hjemme.

I boken The Laws of Software Process definerer Phillip G. Armour programvare som det femte medium for lagring av kunnskap, og sier at produktet som utvikles ikke er selve programvaren - men heller kunnskapen som er lagret i form av kildekode. I stedet for å investere i hjemmelagde rammeverk som i stor grad lagrer teknisk kompetanse og erfaring, bør foretak fokusere på å lagre domenespesifikk kunnskap – det er der verdien ligger.

Dette kan gjøres ved å etablere og vedlikeholde gjenbrukbare biblioteker med forretningsorientert funksjonalitet. For foretak som har eller er i ferd med å etablere SOA infrastruktur kan tjenestekomponenter for gjenbruk på tvers av systemplattformer være en god tanke.

Ingen som passer for meg?
Noen foretak har visjoner, krav og behov som gjør at man kanskje ikke finner et open-source (eller kommersielt) rammeverk som passer. Hvis man er tvunget til å ta opp ekstremsport og bygge rammeverk selv, så bør design prioriteres høyt – svært høyt.

Erfaringene viser at rammeverket bør designes for å kunne tas bort og erstattes med noe annet – med minst mulig resursbruk.

Hvis man virkelig mener at et hjemmelaget rammeverk har livets rett, så bør man også vurdere om det finnes andre aktører med samme behov. Hvis dette er tilfellet kan rammeverket kanskje utvikles i felleskap med andre?

Kanskje kan nettopp dette rammeverket bli neste generasjons open-source de facto standard innefor domenet til din virksomhet…