What does it take to be a good programmer?

First, let’s talk about the teaching profession. 

What does it take to be a good teacher? 

In Norway – where I live – I think most would agree that the best teachers see the potential in their students, and find ways to bring out the best in each one.  It’s not so much about the teacher’s own knowledge of the subject they teach, as their ability to spike their students’ interest and make them understand the subject matter. 

Schools have changed dramatically over the last century.  Back in the day, children lived in fear of the teachers.  Teachers were meant to be strict authoritarians who’d happily administer painful, both physical and emotional, punishment for, say, getting your latin grammar wrong. To be a good teacher back then, it was deemed necessary to be authoritative and have superior knowledge that was not to be questioned.

How things have changed.

Some say we’ve gone too far in the other direction now a days: 

“Respect for teachers is gone! Nobody wants to be a teacher anymore. It used to be a respected profession. Now it is low pay, low status and you’re bullied by difficult kids and their parents all day.”

Maybe we have gone too far, maybe we haven’t gone far enough.  Interesting discussion, but beside the point I want to make, which is this: Things can change. 

We still have the same profession: teaching. That takes place in the same environment: schools and classrooms. Yet, how the work is done has been transformed. I don’t think teachers back in the day saw this coming – They most likely would not approve.  People are good at justifying the status quo.

Ok, now let’s talk about programming.  

What does it take to be a good programmer? 

You need to be really smart and have a scientific mindset. Most importantly you need to love learning new things.  Programming isn’t a typical 9-5 job. At least not if you want to be any good at it. You need to stay up to date with the latest changes in the field. When (if?) you get back from the office, you should spend your evenings on open source projects and/or learning new languages and frameworks.  

Right? 

I wonder how long it’ll be before we look back on this era and shake our heads and marvel at how anyone got through this with their sanity intact (did they?).

Lots has been said about how the current state of software development leads to lack of diversity.  But forget about that for a second: what does the current state of software development do to the actual software we create?

What impact does it have on the products we create, when nobody has more than a few years experience with the tools used? I got my first programming job more than 20 years ago (part time while I was studying, but still!) Yet the amount of time I spend every day searching the internet for tutorials and examples of how to use whatever “flavour of the month” framework or library or service we’re using is considerable.  I know I’m not the only one.  The time and effort spent learning these new libraries and frameworks, is time and effort not spent focusing on the actual product we’re meant to be making.

This might not be so bad, if the new services and frameworks we learn provide massive improvements in our ability to deliver value to the users.  But it rarely does.  Whether it’s the software architect who’s discovered “microservices” or “streams”, or a new programming language, or a manager who wants to impose some configurable off the shelf monstrosity, it seldom really makes an impact where it matters: to what the users of the software actually see and use. 

That’s what should matter.  That’s the whole point of programming.  The point of programming is to create software that delivers value to the users.  

I don’t care how good you are at chopping vegetables, how efficiently you handle the ingredients while cooking or how modern your kitchen appliances are – if the food tastes like crap, I’m not coming back to your restaurant! 

I don’t care how good your vocabulary is or how many languages you speak.  if your writing isn’t interesting or relevant to the audience in some way, it’s worthless.  

As a woman, I keep hearing the following justification for the lack of gender diversity in programming: 

“Women don’t choose programming, because they want to work with people, not technology”. 

Sure, absolutely.  In todays field of software development, people don’t come into it, do they? We care about the tech.  Is it “green field”? Does it use “cutting edge” technology? That’s what the programmers care about.  If you care more about people and how the product you’re making actually affects them, then you would not fit in.

Is that a good thing though?

To be a good programmer you obviously need to care about the code.  Caring about user experience doesn’t make you a good programmer.  Just like caring about people’s health is not going to make you a good doctor.  As it turns out though, caring about people, does not in fact exclude the possibility of caring about other things as well. Like medicine, or chemistry, or indeed coding. 

Which brings me to the very act of programming:  What is code, when it comes right down to it?  What kind of mental processing is actually required to write elegant and efficient code? 

Code is written instructions. Nothing more, nothing less.

Programming is writing down unambiguous instructions, and then grouping those instructions in meaningful ways.  We’re coordinating work.  It’s not rocket science. 

Is it even science?  

If you can coordinate a large social event, you have all the mental capacity required to be a good programmer. Let me illustrate:

To organise an event, you need to book a venue and send out invitations. Then you can start looking for music acts and caterers.  When the RSVPs start coming in you can narrow down how much food you’ll be needing and land a menu with the caterers.

For each of the various stages in this process, there will be more layers of increasingly detailed instructions.  The top level catering instructions are “3 course meal for 50 people: first a greek salad, then roasted lamb, followed by a crème brûlée.  For each course, there will be more layers of instructions. The most detailed of which being how one beats an egg, or how one operates the oven.  But you rarely have to dive into that level of detail.

To be able to coordinate things well, it’s important that one has a clear idea of the roles and responsibilities involved.  You typically don’t mix in table setting instructions in the crème brûlée recipe. 

This does not require Mensa-level intelligence.  

“Architectural” considerations like: Should we have one person in the kitchen be responsible for all egg-related work, and another in charge of the flour, a third person is in charge of chopping things? (“microservices”?), or should we let people be in charge of a whole dish – like “A does the salad, B does the main course” etc? Choosing between these types of strategies does not require a masters degree in a scientific subject.  And making these decisions are precisely what programming is all about.  Typing out the code is not the point or the challenge of programming.  It’s about being able to understand the flow of instructions and information.  Which roles are required to perform a task, who needs what information, and how do they get it?  

Do we need a “Chef” with the abilities “greekSalad()”, “roastedLamb()”, and “cremeBrulee()”? Or do we deal with the dishes separately, so they don’t necessarily have to be implemented by the same chef?  Do the resulting dishes get put on a queue, and then get picked up by a “waiting staff” process? How do we prevent dishes piling up with nobody there to deliver them to the diners?  

There are no “correct answers” here.  There are always any number of ways of solving these problems.  The important thing is that the instructions make sense, and that they lead to the desired outcome. 

These are the problems we work on as programmers. 

Is this “technology”?  Because I know plenty of people capable of reasoning these things out, who are not very technologically minded. The only “techy” part of the programming job, is that we have to learn new tech every couple of years to express these same ideas. But is this really necessary?

In addition to the questionable requirement to learn new tech all the time, I suspect that the reason we think programmers have to be insanely smart, is because so much of our code is organised in a horribly complex manner.  We group things together in non-productive ways to suit our technological fancies.  Like organising the kitchen staff by the tools in the kitchen.  Team A are those who work with metal utensils,  team B work with wooden utensils, C use electrical appliances and D are in charge of all food heating.  Trying to make sense of how one creates a crème brûlée with a worker grouping like that requires a lot of intelligence.  But it shouldn’t have to be that way. We need to stop admiring those smart enough to understand how the software works, and start making the software easier to understand in the first place.  But we’re not optimising for those kinds of skills at the moment. 

If we just stuck with a tech stack that works, we could focus more on user needs.  Just like in any other field, there might be new and shiny innovations that could provide some benefit or other.  But just like in all other fields, you shouldn’t have to drop everything every time someone comes out with a new product: 

“OMG! Have you seen the new kitchen appliance series from Kenwood?!?! We need to completely replace everything in the kitchen!  If we don’t, we’ll be unable to attract new staff,  morale will drop and everyone will resign!”

I feel pretty sure this is not a thing in the field of catering. Developers are such primadonnas, and it’s a self reinforcing thing.  We get away with this behaviour, because there are too few of us, we’re needed.  Why are there so few of us? Because we’re gate keeping and pretty much ensuring that anyone who isn’t this obsessive about tech won’t feel welcome or that they’re able to contribute. 

Through my years in the field, I have seen my fair share of companies and the struggles they face.  Very many are working on the same thing: “We need to move our software to the new platform”.   In other words, they have software, that works (for some definition of “works”), but they feel they need a new platform of some kind. 

“We need to move to the cloud”.  

“We need to make this ‘COTS’ system do the same thing that our old software does” 

“We need to modernise our tech stack”

A very large part of what software developers do now, is not write new functionality that users will notice and enjoy, but rather re-write something the users dislike to varying degrees, so it runs on a “modern platform”.  This “modern platform” will of course be obsolete a few years down the road, so we start again. 

Software development provides well paid work for many, so in a way I guess I can’t complain personally.  I happen to like working as a software developer, even under the current environment.  But I can’t help but asking myself: 

How are we getting away with this? Isn’t someone going to catch on soon?  How many “new platforms” do we have to make, before people start realising that rewriting everything, using “the latest tech” is not going to solve the problems that matter? 

What would the field of software development look like, if “the best programmers” were not the most mathematically inclined neophile workaholics, but rather people who are good at organising work? Good at communicating clearly.  People who care, not so much about which tools are used, but  about using whatever tools are available to maximise the value of the product being made?    

I think we’d see a different brand of developers, and much better software.  Better in a way that actually matters to the users.  

Would developers risk losing status, just like we’ve seen happen to the teaching profession? Maybe?  But is that a good enough reason to hold onto a counter productive culture that both prevents focus where it matters, and simultaneously excludes people in a time where software development is needed more than ever? I don’t think so. 

I don’t know how we’ll do it, but I think we both can, and should change.  There will be strong resistance of course, from those with the most to gain from the status quo. 

I hope we’ll manage to find a better balance between the eagerness to learn new tech, and the focus on actually delivering value. 

I hope “If you’re interested in people, you won’t be a good programmer” will bring about a good laugh all around, as we shake our heads and think about how backwards the field of software development used to be. 

I encourage you all to help make this happen. 

Advertisement

En bok til 11 milliarder

Jeg har aldri skrevet en bok.  Jeg er ikke forfatter.  Men jeg har jo lært å skrive på skolen, skriver en del på fritida, som akkurat nå for eksempel.  Så selv om jeg ikke skriver bøker, kan jeg tenke meg til mye av det som inngår i prosessen med å skrive en bok.   Det tror jeg de fleste av dere kan også.

Så la oss si det offentlige hadde behov for tekstlige beskrivelser av det norske helsevesenet og hvordan det opererer. La oss si det var bred enighet om at vi trengte disse tekstene. La oss så se for oss at politikere og byråkrater sammen med management konsulenter fra PWC hadde brukt mer enn 5 år og 100 millioner kroner på å komme frem til at arbeidet burde organiseres som ett prosjekt, der vi kjøper inn en bok som beskriver det amerikanske helsevesenet.  Så skal vi bruke 10 år og 11 milliarder kroner på å oversette denne boka, og ytterligere 11 milliarder kroner i “andre ikke-oversettelses-relaterte kostnader”.

Hadde vi syntes det var OK?

Mest sannsynligvis ikke.

“Jammen i alle dager” hadde vi sagt. “Brukte dere 5 år og 100 millioner på å komme frem til noe så tåpelig?” hadde vi sagt.  “Én bok til 11 milliarder kroner? Hvorfor ikke flere bøker som er mer rettet til de forskjellige brukergruppene som faktisk skal lese det her?”  Hadde vi kanskje spurt.
“Slapp av, slapp av, boka vil jo bli delt opp i flere kapitler!” sier ledelsen av prosjektet.  “Først kapittel 1, så kapittel 2, etterfulgt av kapittel 3 osv”

“Hvordan i alle dager tenker dere å bruke 11 milliarder kroner på oversettelses-kostnader?” er et annet nærliggende spørsmål.  “Hvor mange millioner i året er det disse forfatterene skal ha? Det går jo ikke an å skrive én sammenhengende bok med tusenvis av forfattere? Hvordan klarer dere å bruke så mye penger?”
Det spørsmålet er besvart i KS1 rapporten, men sidene er unndratt offentligheten, så noe svar på dette får du ikke.

Betryggende svar?

Dette er sånn programmerere har det når vi leser om prosjekter som det oppkommende Akson-prosjektet direktoratet for e-helse har planlagt.  Alt tyder på at de legger opp til å kjøpe inn det amerikanske helse-plattform-systemet Epic, og så få det “oversatt” til norske forhold.  Dette tenker de å bruke 11 milliarder kroner på over 10 år, pluss ytterligere 11 milliarder i kostnader som ikke er direkte knyttet til IT.

Det viser tydelig at vi virkelig trenger å få koding inn i skolen.  Folk flest må få mer kunnskap om hva det vil si å skrive programvare.  Det er skummelt å se hvor dårlige valg politikere uten IT-kompetanse kan ta.  Milliarder av våre skattepenger kastes bort på helt håpløse prosjekter som det burde være innlysende for alle at man burde holde seg langt unna.

Programmering er å skrive tekst.  Software har ingen fysisk form.  Vi konstruerer ikke broer og operaer her.  Programmerere skriver tekst som beskriver prosesser.  Så enkelt, og så vanskelig er det.  Man kan ikke prosjektstyre programmering slik man kan bygging av store nye signalbygg.  Skal du bygge en bro, må du planlegge nøye.  Du kan ikke bygge den halvveis og så finne ut at den var for smal, ikke sterk nok, eller på helt feil sted.  Skal du bygge noe fysisk, må en ha en skikkelig planleggingsfase først, også sette igang med konstruksjon.  I konstruksjonsfasen kan du pøse på med arbeidere som jobber etter nøye utarbeidede planer.  Men i software har vi jo ikke noe å konstruere.  Vi lager ikke noe fysisk.  Vi har hverken asfalt eller murstein å legge.  Vi skriver tekst.  Som vi lett kan endre på.  Vi visker ut ting og skriver det på nytt hele tiden.

Hvor mange team à 7 forfattere trenger du for å skrive en god roman?
“Team A kan begynne å jobbe på kapittel 1 – 3. Team B tar kapittel 4 og 5, team C tar kapittel 6 – 9….”  Kan du tenke deg å skrive en roman på den måten? Tenk så mye koordinering og ekstra-jobb det blir å skulle få til en sammenhengende historie på den måten! Store ekstra-kostnader, og forsvinnende liten sjanse for at boka blir særlig bra.
Men det er dessverre altfor ofte sånn vi organiserer IT-prosjekter i offentlig sektor.
Det er ikke rart det går galt.

Jeg heier på Lær Kidsa Koding . Vi trenger å få programmering inn i skolen så vi kan ta bedre valg når det gjelder bruk av våre skattepenger på utvikling av software.

 

Nei, systemene må ikke snakke sammen

Når man leser om problemene innen helse IT hører man stadig om hvor stort problem det er at systemene ikke snakker sammen.  Data som blir lagt inn på sykehuset dukker ikke opp hos fastlegen osv.  Dette bør vi helt klart fikse på.

Men det er flere måter å tenke på dette problemet.  For hva er det egentlig vi vil? Vil vi egentlig at datasystemet til fastlegen snakker med datasystemet til sykehuset? Hvordan vil dette egentlig fungere? Hvordan kan fastlegesystemet vite hvilket sykehus det skal hente data fra? Må de integrere med samtlige sykehus og helse-institusjoner i hele Norge bare for sikkerhets skyld?  Hvordan kan de ellers vite at de har all informasjon om meg?  Jeg kan jo ha skadet meg på ferie et helt annet sted i landet og fått behandling der.
Hvis vi skal nå målet om “en innbygger, en journal” ved at alle systemene snakker sammen, så må jo egentlig alle IT-systemer i Norge snakke med alle andre IT-systemer i Norge. Det medfører veldig mye kompleksitet på veldig mange nivå – og for å nå dette målet, er det helt essensielt at alle IT-systemer “snakker samme språk”. Vi må ha standardiserte datamodeller alle kan forholde seg til – og det å bli enige om et slikt felles språk på tvers av så mange forskjellige domener, det er ikke lett.

En annen løsning er å tvinge alle til å bruke samme IT-system.  Et mega-system som gjør alt for alle.  Det er heller ikke særlig populært eller effektivt. Det er så mange forskjellige brukergrupper innen helse, at å finne effektive “plattformer” som gjør absolutt alt er tilnærmet umulig.

I land som USA, så er arbeid som dette helt nødvendig, og det er masse forskjellige standarder der ute som har som formål å gjøre denne “samtalen” lettere.  Men i USA har de ikke noe statlig helsevesen slik som oss.  De har private helse-organisasjoner som alle har sine pasient-systemer.  Den eneste måten å få samlet helse-informasjon om en pasient, er ved å integrere med alle helse-institusjonene pasienten har vært innom.

Men Norge er veldig annerledes enn USA.  (Takk og lov.) I Norge har vi et statlig helsevesen.  I Norge er vi heller ikke så glade i snakke med villt fremmede.  Vi holder oss mer til oss selv.  Det kan også våre IT-systemer gjøre!  De trenger faktisk ikke snakke med hverandre i det hele tatt.  De kan bare kan få det de vil fra staten.  Vi er godt vant med dette med felles registre, som folkeregisteret, likningsregisteret, kontaktregisteret, all offentlig informasjon om oss ligger typisk i et felles register. Disse felles registrene gjør det veldig lett for oss å lage gode brukervennlige IT-løsninger, der informasjon om hvor du bor og hvem du bor sammen med kan hentes automatisk, så du slipper å fylle det inn igjen og igjen i alle offentlige skjemaer.  Det er jo egentlig dette vi også trenger i helsevesenet.  Det som er viktig for meg er jo ikke at “systemene snakker sammen”. Det som er viktig er at min informasjon er tilgjengelig der det trengs.  Vi trenger ikke at fastlegesystemet snakker med sykehus-systemet.  Vi trenger at begge to sender og henter data til et felles register.  Vi trenger ingen “integrasjonsplattformer” eller “helseplattformer” der applikasjoner “snakker sammen”.  Vi trenger kontroll på helsedataene våre.

La oss ikke importere problemer vi ikke har fra USA.  Vi trenger ikke komplekse altomspennende integrasjonsplattformer og helseplattformer der applikasjoner “snakker med hverandre med felles språk”. Vi trenger bare å sette opp registre der data lagres sentralt, og tilgjengeliggjøres på en sikker måte.

Norgeshistoriens dårligste idé

Aftenposten tok kontakt i forrige uke for å få noen innspill om Akson-prosjektet.  Resultatet ble publisert her.
Men artikkelen gjengir selvsagt ikke alt jeg sa, så jeg har fått lov til å publisere det fulle intervjuet her.

Aftenposten:
På bloggen din skriver du om “hvordan både konsulenter og fast ansatte har valgt en prosjektgjennomføring som går imot alt vi har lært om softwareutvikling og hvordan man unngår katastrofer.” Hva legger du i dette?

Svar:
Først og fremst mener jeg dette med at de har valgt å løse så mange problemer i ett stort prosjekt som skal gå over 10 år og koste flerfoldige milliarder kroner.  Vi har veldig mye erfaring nå, både i Norge og internasjonalt, både i privat og offentlig sektor, som tilsier at størrelse på prosjekt, både i omfang, kostnad, tid og antall deltakere korrelerer negativt med suksess.  Jo større prosjektet er, jo større sjanse er det for at det går dårlig. Dette har blant annet Magne Jørgensen i Simula jobbet og skrevet mye om, blant annet her.

Akson kommer til å være norgeshistoriens største IT-prosjekt, og er i så måte norgeshistoriens dårligste ide når det kommer til IT-prosjekter.

Det er bare fint at man ønsker å satse skikkelig på å forbedre helse-IT, og jeg er ikke negativ til at store summer brukes til dette formålet.  Men rent IT-teknisk er det ikke lurt å organisere arbeidet som et eneste stort prosjekt med leveranser langt frem i tid.

Aftenposten: De eksterne fagfolkene som har vurdert Akson i kvalitetssikringsrapporten skriver blant annet:

“Det er etter vår vurdering en manglende harmoni mellom overordnede uttalelser om ambisjoner og hvilke muligheter man ønsker å åpne for, og innholdet i mer operative strategier og planer som skisseres for å nå de beskrevne målbildene. Samlet er det for mange viktige problemstillinger om løsnings- og gjennomføringsstrategi som er skjøvet fremover i tid uten å gi svar som normalt skal være dekket i SSD ( Sentralt styringsdokument ). Det er ikke tilstrekkelig synliggjort hvordan de overordnede prinsippene om økosystem, plattformtilnærming og samhandling, samt en stegvis gjennomføring, skal omsettes til en planlagt, konkret og troverdig løsnings- og gjennomføringsstrategi.”

Og:

“Etter vår vurdering er den samlede risiko knyttet til løsning og gjennomføring meget høy. Forskning viser at sannsynligheten for at prosjekter mislykkes øker betydelig når omfang og kompleksitet er stort, og varigheten er lang. Det er etter vårt syn nødvendig å tydeliggjøre både den stegvise utviklingen og den fasedelte innføringen av Akson journal for å redusere den tilhørende risiko.”

Stemmer dette overens med ditt inntrykk av prosjektet?

Svar: Ja, dette er gode tilbakemeldinger.  Men jeg har lyst til å legge til at selv med tydeliggjøring av strategier og oppdelinger som de her ønsker seg, så bør man ikke gå videre med Akson. I mine øyne er det aldri en god grunn til å sette av mange milliarder kroner på ett prosjekt, uansett hvor godt “sentralt styringsdokument” det måtte ha.  Det er i IT som med alt annet at når man først har fått en sekk med penger, så blir de brukt opp.  Gullforgylte Mercedeser, håndvesker til 500 000 kr, jo mer penger man har, jo mer tull bruker man penger på.  Med så rause rammer – 22 milliarder kroner – så legges det opp til enorm sløsing.

Det som gjør det enda verre, er at innen IT, er ikke sløsing av midler bare bortkastede penger, det gjør også at leveransene blir dårligere.  Det å skrive software er ikke som å bygge et boligfelt med klart definerte tegninger.  Man kan ikke øke produktiviteten med å legge til flere håndverkere slik man kan andre steder.  Det å skrive software er mer som å skrive en bok, der kapitlene må henge sammen og historien skal gi mening.  Jo flere forfattere som skal skrive på en historie samtidig, jo vanskeligere blir det, jo mer koordineringsbehov får man, jo større er sjansene for at boka blir umulig å forstå.

Aftenposten: Folk i IT-miljøet skriver om figuren (se vedlegg) at dette må være “skoleeksempelet på scope creep”. Hva tenker du om denne figuren?

Svar: Dette illustrerer så godt hvor lett det egentlig bør være å dele Akson inn i flere prosjekter.  Her har vi masse bokser som beskriver konkrete behov man har innen helse.  Det bør være uproblematisk å finne fine avgrensede områder man kan jobbe med som gir klare gevinster hver for seg.

En ting de konsekvent ikke gjør i disse mer tekniske dokumentene om Akson-prosjektet er å ta tak i begrepet “journal”.  Når man ser på definisjonen av “Journal”  så ser vi at en journal skal inneholde alt som kan krype og gå av informasjon som kan være relevant for helsepersonell.  Bare det å snakke om å lage en “jornalplattform” som en ting, er problematisk i seg selv.  Vi må se på hva de forskjellige delene av en journal er, og finne måter å jobbe effektivt med de forskjellige delene.

Når man skal dele opp software, er det lurt å dele det inn i deler som gir en konkret brukerverdi hver for seg.  På den måten kan ledelsen mye lettere sikre at pengene blir brukt på en god måte.  Det er vanskelig for en leder uten IT-kompetanse å vite hvordan det egentlig går med utviklingen av “en IT-plattform”. Det er veldig lett å kaste bort årevis med midler på plattformutvikling uten å sitte igjen med noe som kan brukes.  Det er spesielt viktig i organisasjoner som ikke har dybdeforståelse innen IT at man alltid insisterer på å få levert noe som løser konkrete behov forløpende. Da kan alle følge med og bidra på best mulig måte inn i prosjektet.

Aftenposten:  Hvorfor tror du da Direktoratet for e-helse har valgt denne løsningen – du var selv på dialogmøte om prosjektet i desember i fjor?

Svar: Jeg tror det er mange grunner til at de velger denne fremgangsmåten. For det første er det sikkert motiverende for ledelsen å tenke at “Nå skal vi ordne opp i alle problemene innen helse! La oss ta i et skikkelig tak.”  Det er mer prestisje å lede et stort prosjekt, enn å lede et lite ett. Og for ledelsen, som sitter og ser på det hele ovenfra, som har ansvar for alt, så er det lett å tenke at alt sammen er ett problem.  Man ser på problemer og finner løsninger utifra sitt eget perspektiv.  Mitt perspektiv som utvikler, og brukernes perspektiver er ganske annerledes enn for toppledelsen.  I IT-prosjekter er det viktig å alltid minne seg selv på at det er brukernes perspektiv som er det viktigste – det er det lett å glemme.

En annen grunn til at man gjør det på denne måten er problemer rundt finansiering av IT.  Ideelt sett bør utvikling av software gjøres “i linja”, med ansatte (gjerne supplert med konsulenter ved behov).  Private foretak som driver med software, Finn.no for eksempel, legger ikke ut prosjekter på anbud når de får en idé om en forbedring eller ny funksjonalitet som skal inn i deres tjenester.  De har en etablert utviklingsorganisasjon som har stabile budsjetter og jobber kontinuerlig med både ny funksjonalitet og forbedring av gammel funksjonalitet.  Men i staten har man mange steder gått vekk ifra dette, selv om IT-systemer i aller høyeste grad er et kjerneområde flere og flere steder.  Uten egen linjeorganisasjon, er den eneste måten å få midler til utvikling å starte et prosjekt. Da virker det enklere å bare be om masse penger med en gang, istedenfor å måtte søke om nye midler i mange omganger.

Aftenposten: Du er jo selv i konsulentbransjen – skildrer konsulentbruken i “Konsulentmillionene” en kjent virkelighet for dere?

Virkeligheten dere beskriver i “Konsulentmillionene” er ikke tatt fra deler av prosjekter jeg selv typisk er involvert i, men jeg har måttet leve med konsekvensene av at “management consulting” uten IT-faglig kompetanse får holde på i årevis med planlegging før folk som meg blir involvert.  Jeg har selv erfaring fra et større konsulenthus, og har vært med på et anbuds-prosjekt i 100-millionersklassen, og det er det verste jeg noen gang har vært med på rent profesjonelt.  PWC driver ikke med software-utvikling i det hele tatt, de leverer kun “management consulting”-tjenester.  Det er tydelig i all dokumentasjon om Akson-prosjektet at man mangler IT-faglig kompetanse i beslutningene og strategiene som velges.  Her for eksempel ser vi hvordan de ser for seg å dele Akson prosjektet opp stegvis.  De ser for seg at man kan ha flere anbudsrunder med følgende rammer:

Journalplattform
Forvaltning av identiteter og rettigheter
Utvikling av grensesnitt og integrasjoner
Applikasjonsdrift og forvaltning
Driftsplattform
Kompetanse- og kapasitetsforsterkning
Tilleggsfunksjonalitet

Hvis man ikke kan noe om IT, høres sikkert dette helt greit ut.  Men for en som jobber med dette ser man umiddelbart at alle disse leveransene er gjensidig avhengig av hverandre.  Ikke en eneste av disse leverer brukerverdi.  Man kan ikke ha en journalplattform uten en forvaltning av identiteter, eller grensesnit og integrasjoner, eller driftsplattform. Ingen av leverandørene vil kunne levere noe uten å koordinere med alle de andre. Det er slik det så altfor ofte blir. Man bruker millioner på dyre management konsulenter i lange planleggingsfaser som vedtar prosjektplaner som gjør det nesten umulig å jobbe effektivt.

Aftenposten: Du reagerer ikke fordi dere må se på milliardprosjektet fra siden?

Tja, det hele kjennes kanskje som å være utdannet kokk og sitte på en kjempedyr restaurant med åpent kjøkken, og se på at de som jobber på kjøkkenet putter kjøttdeig i sjokoladesoufléen og blander salaten med tærne mens de kontinuerlig kaster bøttevis med safran opp i lufta som blir blåst ut vinduet av store vifter.  På den ene siden får en lyst til å bidra med sin kunnskap for at ting skal bli bedre, men det er ikke fristende å skulle ta del i det som skjer på kjøkkenet på noen som helst måte. Mest av alt er det utrolig provoserende at store mengder av ens egne penger skal brukes på slikt sløseri.

Markedsverdi

“Markedet er en god tjener, men en elendig herre” sa Amory Lovins.
I en markedsøkonomi settes ikke prisen etter hvor mye noe koster å lage, men etter hvor mye kunder er villige til å betale.  For at markedet skal fungere optimalt må kunder
1) ha kunnskap om det de kjøper
2) være klar over hvilke alternativer de har
3) opptre rasjonelt ved å velge det alternativet som gir best kost/nytte.

Ingen av disse tre tilstandene ser ut til å gjelde i offentlig sektor når det gjelder anskaffelse- eller utvikling av IT-systemer.

Den billige masseproduserte plast-dingsen du akkurat kjøpte til 299.90kr koster 0.20kr å produsere.  Men når leverandøren vet at du er villig til å betale 299.90, så gidder de ikke selge den til 0.50.  På akkurat samme måte kan det være veldig stor forskjell i hva det koster å produsere, og hva det koster og kjøpe inn IT-systemer.  I Akson sitt tilfelle; når leverandørene vet at du har beregnet at det vil spare 14 milliarder kroner å forbedre journal-systemene dine, så gidder de ikke foreslå at du helst bare bør ansette et knippe flinke og motiverte utviklere, sette av noen titalls millioner kroner og begynne å utvikle brukervennlige løsninger som levers fortløpende sammen med helsearbeidere.
Det er mye mer hensiktsmessig for leverandører i en markedsøkonomi å utnytte det faktum at du ikke kan noen ting som helst om IT, og si “ojojojojojo, dette er store og kompliserte greier dere ber om. Her trenger vi nok minst 10 år, og kanskje 11 milliarder kroner i rene IT-kostnader og sikkert 11 milliarder til til opplæring og utrulling”

Det er helt essensielt at folk i staten blir mer bevisste på hvordan de som lykkes med software-utvikling i privat sektor faktisk jobber selv.  Det er ingen grunn til at vi skal leve med at staten får dårligere software enn privat sektor.  Hele poenget med å ta i bruk privat sektor for å løse offentlige oppgaver er jo at det skal bli mer kostnadseffektivt, ikke mindre.  For å få til dette er vi nødt til å få ansatt folk i staten som vet hvordan software-utvikling drives idag. Dette er et fagfelt i konstant utvikling, det holder ikke å vite hva som ble undervist på BI på 80-90-tallet.  Det meste innen software har endret seg siden den gang.

De som lykkes med software idag, starter med små team med motiverte folk som jobber godt sammen. Team sentrert rundt bruker-behov.  Både brukere, fageksperter, designere og teknikere jobber tett sammen og løser reelle behov med kontinuerlig feedback og forbedring.  Software er aldri ferdig lengre.  Vi lager ikke applikasjoner som vi shipper ut på CD annenhvert år lengre.  Vi ruller ut kode fortløpende og justerer basert på feedback og reel bruk.  Vi har lært at store gigant-prosjekter med milliard-budsjetter som starter med mange team som jobber på samme produkt som skal leveres samtidig om mange år stort sett går på trynet.  Det er ingen grunn til å gå frivillig inn i slike prosjekter i 2020.

God dag Akson! Økseskaft

Fagmiljøer innen helse og IT har snakket om det lenge (jeg skrev litt om det her), men nå har omsider store generelle nyhetsmedier som Aftenposten begynt å omtale Akson-prosjektet.  De tar opp et viktig aspekt – nemlig det at konsulenter sitter på begge sider av bordet og bestemmer ting som i størst mulig grad øker inntjening for sitt eget konsulenthus. Dette er alvorlig og bra å ta tak i, men Aftenposten adresserer dessverre ikke aspektene som har gjort Akson kontroversielt ellers.  Nemlig hvordan både konsulenter og fast ansatte har valgt en prosjektgjennomføring som går imot alt vi har lært om softwareutvikling og hvordan man unngår katastrofer.

Helsedirektør Bent Høie og direktør for e-helse-direktoratet Christine Bergland har begge vært ute for å forsvare prosjektet i flere fora. Men de svarer ikke på kritikken! God dag man, økseskaft.  Personlig så jeg dem begge i et dialogmøte om Akson-prosjektet 12. desember ifjor (2019).  Det var veldig interessant.  Det jeg hadde lyst til å lære, var
1) Hva er det egentlig de skal lage? Og hva gir inntrykk av at det skal koste hele 11 milliarder kroner? Hvorfor ikke 5 milliarder? Eller 100 millioner?
2) Hvorfor de ikke vil bryte det opp i flere mindre deler, når all erfaring tilsier at mindre prosjekter har større sjanse for suksess.

Her ser vi svaret på punkt 1 slik Bergland presenterte det:

Altså… hæ? Hva er det vi ser her egentlig? Det er en grunnmur i bunn – hva denne innebærer står ikke på sliden og ble heller ikke beskrevet av Bergland.  Over grunnmuren med tittelen “Akson” – hva er det som ligger her? Det står det heller ingenting om, og ble heller ikke utdypet videre.  Det er “en plattform” – ok? Hva legges i det? Boksene på toppen, omgitt av blomster tror jeg skal illustrere alle små konkrete applikasjoner som skal kunne lages når elementene på bånn er ferdig.  Men noen eksempler på hva det kunne være, kom ikke frem.

Jeg har så mange spørsmål. Hvor ligger dataene? Hvordan er dataene strukturert? Hva er det som egentlig ligger i de fargede boksene? Hva skiller plattformen fra grunnmuren? Hva er det de forskjellige brukerne skal måtte forholde seg til av systemer?  Hva er det egentlig vi sitter igjen med etter 22 milliarder kroner? Har vi en plattform vi så kan begynne å lage faktiske brukbare applikasjoner på toppen av? Eller skal disse blomstereng-boksene også utvikles som del av Akson? Hvem har ansvaret for å lage dem?

Men viktigst av alt, hvem ser på en slik vag og intetsigende visjon og sier “Wow! Dette høres ut som en helt spektakulær idé! Hvor mye vil du ha? 22 milliarder sier du? No problem! Kjør på!

Svar på punkt 2 var også spennende.  “Vi bryter naturligvis dette opp i mindre biter! Bare se her:”

Seriøst? “Steg 1” etterfulgt av “Steg 2” fulgt av “Steg 3”?
Er dette en vits? Hva for en prosjekt-plan er dette? Dette hører hjemme i en Dilbert eller en Lunsh-stripe.  Makan til pinlig.  Jeg prøver å se for meg at jeg skal inn og overbevise sjefen om at jeg har en god idé jeg ønsker bevilgninger til:

Jo, nå skal du høre her, sjef: Jeg har en fantastisk idé til hvordan vi løser helse-utfordringene våre!  Først lager vi “en grunnmur” med en “plattform” på toppen, så kan man lage masse applikasjoner på toppen! Arbeidet tenker jeg dele opp i “steg 1”, etterfulgt av “steg 2”, “steg 3” osv, og etter “steg 5” så er vi i mål. Jeg trenger bare 22 milliarder kroner og rundt 10 år. Greit?

Det går da virkelig ikke an!  Det er faktisk ikke så vanskelig å komme med konkrete forslag. Jeg har gjort det selv her og her for eksempel, hvor jeg argumenterer for at man ikke trenger en plattform overhodet for å løse helse-utfordringer.

En annen ting som kom tydelig frem på dette dialogmøtet, og igjen her i Aftenposten, er at Høie er grunnleggende feilinformert om hva ekspertene har anbefalt når det kommer til prosjektgjennomføringen. Høie tror at man allerede har utredet muligheter for å dele opp Akson-ambisjonene i mindre deler.  Han har blitt fortalt at eksperter har kommet frem til at dagens giga-prosjekt var det beste alternativet.  Dette er ikke sant.  Når han sier at eksperter har anbefalt dagens strategi, så refererer han til KS1-utredningen, der man drøftet hvordan man løser problemene med helse-journal-samhandling i ett prosjekt.   Trenger vi erstatte alle journal-systemer, eller bare “hacke til” dagens løsninger og legge til noen små tjenester her og der? Spurte man.  Som vanlig i offentlig sektor får man altså feil svar, når man stiller feil spørsmål.  Det man burde drøftet er hvilke prosjekter som til sammen kan løse utfordringene med journal-samhandling. Det er det, såvidt meg bekjent, ikke gjort noen offentlige utredninger om.  Det er dette vi bør snakke om.  Hvordan deler vi Akson-prosjektet opp mest mulig hensiktsmessig?  (Nei, svaret er ikke “steg 1”, “steg 2” og “steg 3”).  Jeg har prøvd å være et godt eksempel ved å komme med et konkret forslag.  Ser gjerne at andre kommer med noe litt mer konkret også. Så kan vi diskutere faktiske alternativer og få et mer realistisk kostnadsbilde.

We don’t need a healthcare platform

This text was triggered by discussions on Twitter in the wake of a Norwegian blog post I published about health platforms.
I stated that we need neither Epic, nor OpenEHR, nor any other platform to solve our healthcare needs in the Norwegian public sector. Epic people have not responded, but the OpenEHR crowd have been actively contesting my statements ever since. And many of them don’t read Norwegian, so I’m writing this to them and any other English speakers out there who might be interested. I will try to explain what I believe would be a better approach to solve our needs within the Norwegian public healthcare system.

The Norwegian health department is planning several gigantic software platform projects to solve our health IT problems. And while I know very little about the healthcare domain, I do know a bit about software. I know for instance that the larger the IT project, the larger the chances are that it will fail. This is not an opinion, this has been demonstrated repeatedly. To increase chances of success, one should break projects into smaller bits, each defined by specific user needs. Then one solves one problem at a time.

I have been told that this cannot be done with healthcare, because it is so interconnected and complex. I’d say it’s the other way around. It’s precisely because it is so complex, that we need to break it into smaller pieces. That’s how one solves complex problems.

Health IT professionals keep telling me that my knowledge of software from other domains is simply not transferrable, as health IT is not like other forms of IT. Well, let’s just pretend it is comparable to other forms of IT for a bit. Let’s pretend we could use the best tools and lessons learned from the rest of the software world within healthcare. How could that work?

The fundamental problem with healthcare seems to be, that we want all our data to be accessible to us in a format that matches whatever “health context” we happen to be in at any point in time. I want my blood test results to be available to me personally, and any doctor, nurse or specialist who needs it. Yet what the clinicians need to see from my test results and what I personally get to see will most likely differ a lot. We have different contexts, yet the view will need to be based on much of the same data. How does one store common data in a way that enables its use in multiple specific contexts like this? The fact that so many applications will need access to the same data points is possibly the largest driver towards this idea that we need A PLATFORM where all this data is hosted together. In OpenEHR there is a separation between a semantic modelling layer, and a content-agnostic persistence layer. So all datapoints can be stored in the same database/s – in the same tables/collections within those databases even. The user can then query these databases and get any kind of data structures out, based on the OpenEHR archetype definitions defined in the layer on top. So, they provide one platform with all health data stored together in one place – yet the user can access data in the format that they need given their context. I can see the appeal of this. This solves the problem.

However, there are many reasons to not want a common platform. I have mentioned one already – size itself is problematic. A platform encompassing “healthcare” will be enormous. Healthcare contains everything from nurses in the dementia ward, to cancer patients, to women giving birth, orthopaedic surgeons, and family of children with special needs… the list goes on endlessly. If we succeed building a platform encompassing all of this, and the plattform needs an update – can we go ahead with the update? We’d need to re-test the entire portfolio before daring to do any changes. What happens if there is a problem with the platform (maybe after an upgrade.) Then everything goes down. The more things are connected, the more risky it is to make changes. And in an ever changing world, both within healthcare and IT, we need to be able to make changes safely. There can be no improvement without change. Large platforms quickly become outdated and hated.

In the OpenEHR case – the fact that the persistence has no semantic structure will necessarily introduce added complexity in how to optimise for context specific queries. Looking through the database for debugging purposes will be very challenging, as everything is stored in generic constructs like “data” and “event” etc. Writing queries for data is so complex, that one recommends not doing it by hand – but rather creating the queries with a dedicated query creator UI. Here is an example of a query for blood pressure for instance:

let $systolic_bp=“data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude”
let $diastolic_bp=“data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude”
SELECT
obs/$systolic_bp, obs/$diastolic_bp
FROM
EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1]
CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
WHERE
obs/$systolic_bp>= 140 OR obs/$diastolic_bp>=90

This is needless to say a very big turn-off for any experienced programmer.
The good news though, is that I don’t think we need a platform at all. We don’t need to store everything together. We don’t need services to provide our data in all sorts of context-dependent formatting. We can both split health up into smaller bits, and simultaneously have access to every data point in any kind of contextual structure we want. We can have it all. Without the plattform.

Let me explain my thoughts.

Health data has the advantage of naturally lending itself to being represented as immutable data. A blood test will be taken at a particular point in time. Its details will never change after that. Same with the test results. They do not change. One might take a new blood test of the same type, but this is another event entirely with its own attributes attached. Immutable data can be shared easily and safely between applications.

Let’s say we start with blood tests. What if we create a public registry for blood test results. Whenever someone takes a blood test, the results need to be sent to this repository. From there, any application with access, can query for the results, or they can subscribe to test results of a given type. Some might subscribe to data for a given patient, others for tests of a certain type. Any app that is interested in blood test results can receive a continuous stream of relevant events. Upon receipt of an event, they can then apply any context specific rules to it, and store it in whatever format is relevant for the given application. Every app can have its own context specific data store.

Repeat for all other types of health data.

The beauty of an approach like this, is that it enables endless functionality, and can solve enormously complex problems, without anyone needing to deal with the “total complexity”.
The blood test registry will still have plenty of complexity in it. There are many types of blood tests, many attributes that need to be handled properly, but it is still a relatively well defined concrete solution. It has only one responsibility, namely to be the “owner” of blood test results and provide that data safely to interested parties.

Each application in turn, only needs concern itself with its own context. It can subscribe to data from any registry it needs access to, and then store it in exactly the format it needs to be maximally effective for whatever usecase it is there to support. The data model in use for nurses in the dementia ward does not need to be linked in any way to the data model in use for brain-surgeons. The data stores for each application will only contain the data that application needs. Which in itself contributes to increased performance as the stores themselves are much smaller. In addition they will be much easier to work with, debug and performance tune, since it is completely dedicated for a specific purpose.

Someone asked me how I would solve an application for
“Cancer histopathology reporting, where every single cancer needs its own information model? and where imaging needs a different information model for each cancer and for each kind of image (CT, MRI, X-ray) +where genomics is going to explode that further”

Well I have no idea what kind of data is involved here. I know very little about cancer treatment. But from the description given, I would say one would create information models for each cancer, and for each type of image and so on. The application would get whatever cancer-data is needed from the appropriate registries, and then transform the data into the appropriate structures for this context and visualise the data in a useful way to the clinician.
We don’t need to optimize for storage space anymore, storage is plentiful and cheap, so the fact that the same information is stored in many places in different formats is not a problem. As long as we, in our applications can safely know that “we have all the necessary data available to us at this point in time”, we’re fine. Having common registries for the various types of data solves this. But these registries don’t need to be connected to each-other. They can be developed and maintained separately.

Healthcare is an enormous field, with enormous complexity. But this does not mean we need enormous and complex solutions. Quite the contrary. We can create complex solutions, without ever having to deal with the total complexity.

The most important thing to optimise for when building software, is the user experience. The reason we’re making the software is to help people do their job, or help them achieve some goal. Software is never an end in itself. In healthcare, there are no jobs that involve dealing with the entirety of “healthcare”. So we don’t need to create systems or platforms that do either. Nobody needs them.

Another problem in healthcare, is that one has gotten used to the idea that software development takes for ever. If you need an update to your application, you’ll have to wait for years, maybe decades to see it implemented. Platforms like OpenEHR deal with this by letting the users configure the platform continually. As the semantic information is decoupled from the underlying code and storage, users can reconfigure the platform without needing to get developers involved. While I can see the appeal of this too, I think it’s better to solve the underlying problem. Software should not take years to update. With DevOps now becoming more and more mainstream, I see no reason we can’t use this approach for health software as well. We need dedicated cross functional teams of developers, UXers, designers and clinicians working together on solutions for specific user groups. They need to write well tested (automatically tested) code that can be pushed to production continuously with changes and updates based on real feedback from the users on what they need to get their jobs done. This is possible. It is becoming more and more mainstream, and we are now getting more and more hard data that this approach not only gives better user experiences, but it also reduces bugs, and increases productivity.

The Norwegian public sector is planning on spending > 11 billion NOK on new health platform software in the next decade. We can save billions AND increase our chances of success dramatically by changing our focus – away from platforms, and on to concrete user needs and just making our health data accessible in safe ways. We can do this one step at a time. We don’t need a platform.

Vi trenger ingen helse-plattform

Som programmerer er du alltid nødt til å sette deg inn i nye fagområder. Det holder ikke å være ekspert på koding. Forstår du ikke domenet til de som skal bruke programmene du utvikler, blir produktet heller dårlig. I mine 19 år som programmerer har jeg måttet sette meg inn i alt fra risikoanalyse, seismikk, strøm-markeder, offentlige støtteordninger, kryptering av tv-signaler og panteautomater. Alle domener er forskjellige, alle har sine utfordringer. Koden vil bære preg av det domenet det er skrevet i og de spesifikke utfordringene domenet bringer med seg.

Men programmering er et fagområde i seg selv også. Jo flere IT-prosjekter man er med på, jo flere likhetstrekk begynner man å se. Det finnes gode prinsipper for software-utvikling som gjelder de fleste steder:

– Automatisert testing er lurt (og for å få gode tester, hjelper det med en funksjonell stil på koden).

– Kode bør være løst koblet, så man kan gjøre endringer isolert og trygt, uten at det involverer hele kodebasen. Jo flere ting som er koblet sammen, jo tettere de er koblet sammen, jo vanskeligere blir det å gjøre endringer trygt.

– Det å finne gode avgrensninger/inndelinger/abstraksjoner er det vanskeligste innen programmering. For ting hører jo sammen. Jeg har både epostadresser, telefonnumre, postadresse, navn, barn, biler… Skal alt dette lagres sammen? Hvilke ting hører sammen? Idag ligger epost og telefonnummer i kontaktregistret, mens adressen ligger i folkeregisteret. Er det riktig inndeling? Det finnes ingen fasit og et hvert valg har både fordeler og ulemper. Men at det er lurt å dele ting inn i mindre deler, det vet vi.

– Også når det gjelder utviklingsprosess, er det lurt å dele ting opp i mindre biter. All erfaring og forskning tyder på at jo større et IT-prosjekt er, jo større sjanse har det for å feile. Istedenfor å prøve å takle et helt økosystem med integrerte IT-systemer samtidig i parallel, lønner det seg å gjøre en ting av gangen. Det er utfordrende å finne måter å dele ting opp på, men ikke på langt nær så utfordrende som å prøve å gjøre alt samtidig i parallel.

Dette er noe de fleste er enige i.

Med noen hederlige unntak.

Som for eksempel innen helse.

Utfordringene innen helse-IT blir idag forsøkt løst med store altomspennende plattformer som gjør alt samtidig. “De store prosjekters tid er ikke over” konstaterte Christine Bergland, direktøren for e-helse-direktoratet på konferansen EHIN i Oslo i November (2019). Hun refererte kanskje til Akson-prosjektet til estimerte 11 milliarder
1 1 M I L L I A R D E R kroner
over 10 år. Mer enn en milliard i året. Hvordan de kom frem til det tallet er dessverre unndratt offentligheten.

Helse Midt-Norge vedtok nylig å investere i den Amerikanske plattformen Epic. Denne skal kunne levere omtrent ALT. Tilpassing av plattformen, og lisenser regner de med at vil koste 2.7 milliarder kroner (over 10 år). En sum som for eksempel kunne lønne 135 mennesker med 2 millioner i året i hele perioden. For en plattform som allerede er laget. Hva er det pengene skal gå til? Hvordan klarer de å bruke opp pengene? Og hva skjer når en Trønder trenger behandling i Oslo, der de ikke bruker denne plattformen? Hva skjer når Epic kommer med nye versjoner? Klarer vi å holde følge med oppgraderinger gitt alle spesialtilpasningene vi legger på (også kjent som SAP-syken)? Jeg har mange spørsmål.

De har allerede implementert det i Danmark. Sundhetsplatformen er bygget på Epic. Det gikk til helvete og alle er misfornøyde. Men, men, vi kjører på likevel. Vi er jo som kjent mye smartere enn dansker, så vi får nok til dette mye bedre skal du se.

Og uansett, hva annet skulle vi bruke 2.7 milliarder kroner på liksom? Har vi noe annet valg?

Det finnes norske aktører innen helse-plattformer også. Norske DIPS med sitt nye system DIPS Arena skal også være en universal-løsning for IT i helsesektoren. Den baserer seg på plattformen OpenEHR, som i det minste er en åpen standard. Så her har jeg større grunnlag for å uttrykke meg. OpenEHR har et slags modellerings-språk, som lar en definere alt mulig av helse-data. De har en rekke “arketyper” som består av grupperinger av felt av forskjellige typer. Det finnes en arketype for blodtrykk, og arketyper for forskjellige blodprøve-resultater, osv. OpenEHR har byggeklosser som gjør at en kan representere, lagre og hente frem hva det måtte være av helsedata, slik at absolutt ALLE kan bruke det til ALT.

Akkurat som et programmeringsspråk faktisk. I programmeringsspråket java, kaller vi arketypene “klasser”. Akkurat som i OpenEHR kan disse bygges opp av “attributter” som er av en gitt “type”. Dette lar en definere hva det måtte være av datastrukturer. Fra blodtrykk til fødsler, romskip til fuglebestander. OpenEHR – er altså et programmeringsspråk på toppen av et programmeringsspråk. Litt som å bruke en sag til å sage ut en ny sag i et mykere materiale, som du så igjen må bruke til å sage det du egentlig skulle ha kuttet opp. Ikke spesielt effektivt. (Bare bruk den første saga! Den er kraftigere og bedre.)

I en vanlig software-applikasjon, ville man hatt en struktur som heter “Blodtrykk” som har feltene overtrykk, undertrykk, dato, personnummer, etc. I databasen ville man hatt en tabell med tilsvarende navn og felter. For å hente ut data spør man så:

SELECT overtrykk, undertrykk FROM blodtrykk WHERE personnummer = ? AND dato BETWEEN ? and ?

Med openEHR, har man abstrahert seg vekk fra disse konkretene. Så istedenfor å ha en klasse og en database-tabell som heter “blodtrykk” som inneholder blodtrykkdata, så vil man f.eks hatt en tabell som heter “EHR” som kan ha kolonner som refererer til “Compositions” – definert i en annen tabell, som igjen referer til “Observations” hvor disse kan referere til konseptet “blodtrykk”. Så har man andre tabeller med “attributter” som har kolonner som referer til en type. Så har man til slutt tabeller for “verdi”, som refererer til en attributt.

Her er et eksempel av en OpenEHR spørring etter blodtrykk:

let $systolic_bp="data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude"
let $diastolic_bp="data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude"

SELECT
  obs/$systolic_bp, obs/$diastolic_bp
FROM
  EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1]
      CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
WHERE
  obs/$systolic_bp>= 140 OR obs/$diastolic_bp>=90

Så her kan vi altså sømløst jobbe med hva det måtte være av helsedata. Og det blir like vanskelig å jobbe med alt sammen. Hva konsekvensen er om man f.eks skriver “at0002” istedenfor “at0003” det vet jeg ikke, men det er åpenbart viktig at man holder tunga rett i munnen når man forvalter slik kode. De beste utviklerne vil holde seg langt unna – da denne typen koding rundt generiske modeller er notorisk vanskelig og lite tilfredstillende å jobbe med.

Ytelse er det også tilnærmet umulig å jobbe med. Det kan være vanskelig nok å optimalisere indekser og lagrings-løsninger når man vet akkurat hva slags data man lagrer hvor og hvordan de blir aksessert. Men når alt, uansett størrelse og tilgangsmønster lagres i de samme tabellene, så kan man ikke optimalisere for spesifikke bruksmønster på samme måte. Ikke uventet sliter DIPS stadig med ytelsesproblemer.

Kanskje viktigst av alt er likevel dette – hva skjer om plattformen eller databasen går ned eller får problemer? Da går alt ned. Hele helse-systemet blir utilgjengelig.

Likeså med oppgraderinger av systemene. Hele porteføljen blir nødvendigvis affektert samtidig. “Kan vi oppgradere til siste versjon?” Ikke uten å teste at absolutt ALT takler oppgraderingen. Noe som fører til at oppgraderinger skjer mer og mer sjelden. Med alle sikkerhetsrisikoer og manglende funksjonalitet det fører med seg.

Man kan få til de utroligste ting i slike plattformer. Det er ikke det. Mye bra har blitt laget. Mye bra kommer til å bli laget i fremtiden. Folk finner ut av ting. Bare se her:

Her har en fyr klart å lage et pokemon nintendo-spill inne i Minecraft, ene og alene med Minecraft sine innebygde CommandBlocks! Helt villt! Kjempeimponerende! Men på ingen måte den mest effektive måten å skrive et nintendo-spill på. Akkurat som at generiske alt-i-ett-plattformer ikke er de mest effektive måtene å skrive kode på.

Jeg har stor forståelse for at det høres forlokkende ut med plattformer som løser alt. Men det er ikke en god idé. Kommunisme feilet, ikke fordi kommunister var dumme og slemme, men fordi det er veldig vanskelig å ha et sentralstyrt system som passer for alt. Uansett hvor gode intensjoner man har. Kapitalisme kan være “rotete” i forhold, men med gode regler på plass, så er det mye mer effektivt. Dette gjelder for software også.

“Men helse IT er ikke som andre former for IT. Det er mye mer komplekst.” Blir det sagt. Vet du hva, jeg har hørt denne argumentasjonen før. Hvor var det igjen?
Jo i ALLE BRANSJER JEG HAR JOBBET I.
I absolutt alle bransjer, sitter fagfolk og fordyper seg i problemene i akkurat deres domene. Og det er alltid komplekst der nede i dypet. Men all erfaring (ikke bare min) tilsier at jo mer komplekst noe er, desto viktigere er det å nettopp dele ting opp. Jo mer komplekst noe er, jo viktigere er det å unngå å samle alt i ett system. Ønsker vi å ha gode helse-systemer, må vi åpne for flere, mindre, dedikerte og spesialiserte løsninger.

“Men det er jo det som er problemet idag.” Kan du si. At vi har masse små systemer som ikke snakker sammen. Ja, det at de ikke snakker sammen må vi gjøre noe med. Og det at samme type data lagres over alt i forskjellige formater. Det bør vi også gjøre noe med. Men det fordrer på ingen måte at vi må tvinge alle over på samme plattform.

Da jeg jobbet i Husbanken utviklet vi et nytt system for å kunne søke om bostøtte på nett. Det vant flere priser og var en stor suksess nettopp fordi vi klarte å integrere så mange forskjellige offentlige registre i løsningen. Man trengte bare logge seg inn med ID-porten, så hentet løsningen opp epost og telefonnummer fra kontaktregisteret, adresse, navn, barn og andre husstandsmedlemmer ble hentet fra folkeregisteret. Boliginformasjon ble hentet fra Matrikkelen, inntektsinformasjon ble hentet fra skattemyndighetene, trygder ble hentet fra Nav og eksisterende bostøtteforhold og startlån ble hentet fra Husbankens egne systemer. Da kunne man med veldig få tastetrykk få en ferdig utfylt søknad og vite hvor mye man kunne forvente å få utbetalt i bostøtte. Kjempebra! Ingen av disse systemene kjørte på samme plattform. Det trengte de ikke heller. Jeg ser ingen grunn til at man ikke kan få til tilsvarende løsninger innen helse.

Vi trenger ingen altomspennende helse-plattform. Vi trenger bare å fokusere på å lagre og tilgjengeliggjøre helsedata på gode og trygge måter. Akkurat som vi gjør med all annen data i Norge. Vi er alle enige i at folkeregisteret har navn og adresse-info, at matrikkelen har bolig-info og at kartverket har kart-data.
Hvordan man kom frem til denne inndelingen vet jeg ikke, men det er denne tankegangen vi må få inn i helse. Jeg vil at mine helsedata skal være lagret trygt og være tilgjengelig for alle helse-institusjoner i Norge. Blodtrykksdata trenger ikke være lagret på samme plass som resultatene fra MR scan av kneet mitt. Jeg bryr meg ikke om hvilke applikasjoner som leser dem opp eller skriver dem ned heller. Jeg bryr meg om dataene, og om hvem som har tilgang. Om mine blodtrykksdata leses opp i software laget av store kommersielle aktører, eller en app laget av sønnen til legen min, det driter jeg i, så lenge dataene er sikret. Vi må skille data fra verktøy. Verktøy kan hvem som helst lage, og det kan være mange av dem, samma det.

Vi må dele helsedata opp i mindre deler og fordele ansvar. Arketypene som har blitt laget i OpenEHR-arbeidet kan kanskje være et godt utgangspunkt for å fordele ting. “Dere der borte kan lagre blodtrykk og EKG, så kan dere her nede lagre MR-scan-resultater”. Altså hvordan dette deles opp, det kan ikke jeg uttrykke meg om. Jeg kan lite om helse. Men jeg vet at uansett hvordan man deler det opp kommer noen til å klage. Akkurat som at mange sikkert er irriterte over at epost-adresser og telefonnummer ikke er i folkeregisteret, men i kontaktregisteret. Men litt sånn kan vi leve med. Så lenge all data er tilgjengelig over gode APIer, så får man tak i det man trenger. Da kan hvem som helst lage gode tilpassede løsninger for alt mulig innen helse-sektoren uten at det hele må inn i en felles plattform. Om det er 500 forskjellige apper for å se på blodprøveresultater rundt om i Norge gjør ingen verdens ting. La legene velge det som er mest effektivt for dem. Vi må bare få kontroll på hvor dataene skal hentes fra og lagres til. Og dette kan vi gjøre steg for steg.

Hvordan spiser man en elefant?
En bit av gangen.

Den offentlige digitale støvsugeren

Er det problematisk at Nav bygger opp en intern IT-avdeling? Ja det er det, mener Kjetil Thorvik Brun fra Abelia:
https://www.abelia.no/bransjer/teknologi-og-digitalisering/digitalisering-av-offentlig-sektor/nyheter/den-offentlige-digitale-stovsugeren/

“Hvis det offentlige ønsker å gjøre hele jobben internt, får vi minst tre negative effekter” skriver han. “For det første legger det beslag på en kompetanse som det er knapphet på, og som både privat sektor og offentlige etater har stort behov for.”

Altså.

Når Nav har behov for utvikling av software, så vil det måtte være software-utviklere i Nav-kontorer som skriver denne programvaren. Om de jobber i Accenture eller i Nav, så vil de ikke beslaglegges noe mer eller mindre. De må være der. Akkurat som at når Sparebank 1 eller en hvilken som helst annen privat virksomhet trenger utvikling av sin software så trenger de software-utviklere i sine kontorer som skriver deres programvare. Det sier seg selv at når produktet man leverer er digitalt, så bør man ha folk i organisasjonen som faktisk lager det produktet man leverer. Hvis man ikke selv kan lage sitt eget produkt, så er det noe feil. Hvis man må ut på anbud og be og trygle og forhandle om penger med en ekstern part for hver foreslåtte nye funksjonalitet, så blir man mye mindre effektiv. Hvorfor skal staten drives mindre effektivt enn det private? Selvsagt bør man åpne for å leie inn eksterne eksperter i perioder for å bistå med enten spisskompetanse eller ekstra arbeidskraft i perioder med mye arbeid. Det gjør private bedrifter også. Men den delen av IT-næringa som har levd godt på å støvsuge statskassa for penger for å gjøre det som burde være statlig linjearbeid, den fortjener å dø.

Videre argumenteres det “For det andre krymper man næringslivets mulighet til å bidra i omstillingen av Norge, og dermed til å bygge verdier og arbeidsplasser som gir inntekter i statsbudsjettet gjennom skatt og eksportinntekter.”
Denne skjønner jeg ikke helt. Hva er mest økonomisk lønnsomt for Nav:
1) Betale X millioner i lønn til ansatte, som så skatter av denne lønnen og dermed gir skatteinntekter
2) Betale dobbelt så mye i fakturaer til konsulenthus der noe av det kommer tilbake i form av skatt, men der betydelige andeler rett og slett forsvinner ut av landet og går til utenlandske eiere.
Jeg skjønner ikke hvordan punkt 2 skal føre til hverken flere arbeidsplasser eller mer skatteinntekter.

Siste punkt: “For det tredje risikerer man teknologisk innlåsing. Interne IT-miljøer i offentlige etater har ikke samme krav til fornying som en IT-bedrift i privat sektor som tilbyr tjenester på et åpent marked.”
Et åpent marked, ja. Hvilket marked da? Det finnes ikke noe marked for implementasjoner av det norske trygderegelverket. Det kommer aldri til å finnes noe åpent marked for implementasjoner av det norske trygderegelverket. Dette er et produkt som må eies og styres av Nav og norske folkevalgte politikere. Videre er det faktisk ikke sånn at implementasjonene av det norske trygderegelverket automatisk blir modernisert ved at det er et eksternt konsulenthus som har laget løsningen. De sitter faktisk ikke å videreutvikler og moderniserer trygde-kode for morro skyld i Accenture. De jobber kun dersom de har en kontrakt som gir dem gode penger for å gjøre det. Å sette utvikling ut på anbud er faktisk en oppskrift på å IKKE få modernisert sin applikasjonsinfrastruktur løpende. Det er en oppskrift på å kjøre gammel, utdatert kode.

Nav har aldri vært mer innovativ enn når de nå den siste tiden har ansatt egne folk. Skatteetaten har hatt egne utviklere i lang tid og har høy grad av innovasjon og moderne IT-løsninger.

Videre har ikke Nav og andre offentlige etater samme incentiver til å øke bemanningen i prosjekter. Konsulenthus tjener mer penger jo flere mennesker de får leid ut. Alle ansatte blir lært opp i å se etter muligheter til å få inn flere konsulenter der de er. Derfor ender altfor mange offentlig prosjekt opp med altfor høy bemanning – noe som nødvendigvis fører til økt byråkrati og dårligere leveringsevne.

Jeg er enig med artikkelforfatteren, i at Nav og andre i offentlig sektor ikke har samme muligheter til å gå konkurs, og dermed ikke kjenner like stor trang til å innovere og følge med i tiden som private aktører. Dette er et problem vi aktivt må jobbe med. Derfor vi trenger politikere og toppledere som forstår seg på IT, slik at de passer på at man til en hver tid har løsninger som yter optimalt gitt dagens teknologiske muligheter.

Felles kurs mot 2020 og 2025

Brønnøysund har skrevet om sitt planlagte arbeid fremover mot 2020 og 2025. Felles kurs mot 2020 og 2025.
Det var ikke helt det jeg hadde lyst til å lese, men heller enn å komme med innsigelser og krangling som vanlig, tenkte jeg å skrive min egen versjon. Det jeg kunne tenkt meg å lese, eller et utkast til det jeg selv hadde skrevet hvis jeg var ansvarlig. Det blir jo mindre morsom lesning; ikke noe sarkasme, ingen rare sammenligninger, men samma det – jeg hadde lyst til å prøve å formulere hva det egentlig er jeg har lyst til å høre/forventer å høre fra det offentlige. Hva synes dere? Er dette en forbedring av budskapet til Brønnøysund?

Felles kurs mot 2020 og 2025

I Brønnøysund forvaltes mange forskjellige offentlige registere. Vi har gått fra papir-systemer der skjemaer og vedtak lagres i papir-arkiv-skap, til digitale løsninger, der skjemaer og vedtak lagres i elektroniske arkiv-skap. Men lite har egentlig endret seg for brukeren. Vi ønsker nå å fullføre den digitale transformasjonen av våre registre. Vi ønsker å legge til rette for gode, personlige, digitale dialoger der bruker og saksbehandler, når som helst og hvor som helst, får innsyn i dokumenter og muligheter til å tilføye/endre informasjon, fra mobilen, nettbrett eller datamaskin. Der både bruker og saksbehandler fortløpende holdes oppdatert med relevant informasjon.

Hva dette betyr i praksis vil variere fra register til register og fra brukerbehov til brukerbehov. Noen trenger informasjon om seg selv og sin bedrift. Andre trenger informasjon om store mengder bedrifter/personer. Noe informasjon er privat, annen informasjon skal være åpent tilgjengelig. Osv.
Ikke bare er det store forskjeller fra register til register og behov til behov, men landskapet innen IKT endrer seg såpass fort, at så snart en har fått på plass en løsning som passer ett brukerbehov, kan ny teknologi være tilgjengelig. Ny teknologi som det vil være hensiktsmessig å benytte for å løse andre brukerbehov. Eller for å løse det samme behovet på en bedre måte.

Vi ønsker derfor ikke å låse oss til én arkitektur og én løsning som skal brukes på tvers av alle registre. Gjør vi dette, blir løsningen mest sannsynlig suboptimal for en stor andel av brukerbehovene. I tillegg ville det bli vanskeligere og mer risikabelt å oppgradere, modernisere og gjøre endringer; Endringer i en enkel frittstående tjeneste, enten en endring i funksjonalitet eller teknologisk, har mye lavere risiko enn en endring som treffer hele porteføljen. Vi ønsker oss en portefølje det er enkelt å jobbe med og endre over tid. Vi vil lage små frittstående tjenester som kommuniserer over veldefinerte APIer ved behov. Istedenfor å utvikle egne felles plattformer, vil vi se til de mange etablerte sky-leverandører som idag leverer infrastruktur som kan brukes til å produksjonssette enkle frittstående tjenester.

Behovene vi skal innfri er ikke behovene til forvaltningen, men behovene til befolkningen. Derfor vil vi i arbeidet fremover organisere oss og arbeidet vårt først og fremst etter brukerbehov. Behovene til det norske folk. Vi vil ha team som jobber med selvstendige næringsdrivende, team som jobber med frivillig organisasjonsarbeid, osv. Tverrfaglige team, som jobber aktivt for at nettopp deres brukergruppe skal få optimale digitale brukeropplevelser. Dette vil innebære samarbeid med andre offentlige og private aktører, samt brukerne selv.

Hvis vi lykkes i å lage gode, stabile og brukervennlige løsninger, ønsker vi at andre skal få lære av våre erfaringer. Derfor vil all kildekode være åpent tilgjengelig, og vi tar imot forslag til forbedringer og utvidelser. Der det er hensiktsmessig vil vi lage gjenbrukbare biblioteker og tjenester som andre kan benytte seg av ved behov. Men vi jobber etter “bruk, før gjenbruk” prinsippet. Vi lager løsninger først og fremst for å løse et konkret og reelt behov. Først når vi ser at det fungerer i praksis, vurderer vi om det kan eller bør gjenbrukes.

Vi har en stor jobb å gjøre, men gevinstene er enorme og vi gleder oss til å komme igang!”