Hur kan informationsmodellering gå till? – del 2

Förra artikeln ”Hur kan informationsmodellering gå till? – del 1” beskrev vilka arbetsformer som kan finnas för informationsmodellering. Det gav en bild av själva verktygslådan som står oss till buds. Denna artikel ger exempel på hur man kan kombinera arbetsformerna i ett uppdrag. Jag tror att det är värdefullt att reflektera över och diskutera hur vi jobbar. Gör du likadant, eller på annat sätt? 

Min erfarenhet är att informationsarkitekter gör ganska olika. Det är inte alla som omfamnar alla arbetsformerna. Man har kanske inte tagit möjligheten att utöka verktygslådan.

Jag har funderat på hur jag gör egentligen. Det vanliga är att jag löpande kombinerar och växlar mellan arbetsformer efter behov och läge. Jag kan skönja ett någorlunda återkommande mönster i vilken ordning och på vilket sätt jag växlar de olika arbetssätten. Jag ska nu försöka beskriva detta. Föreställ dig att uppgiften är en av de vanliga, att modellera de centrala delarna av en verksamhet. Alternativt kan det vara en avgränsad del av en verksamhet, som till exempel en större verksamhetsfunktion.

Steg 1: Skapar en karta

Det första jag gör är alltid detsamma. Jag börjar inte med att informationsmodellera, utan först behöver jag skapa något som kan ge överblick och fungera som en kontextkarta. Det vill säga en karta där jag sedan kan ge förankring, det vill säga sammanhang och avgränsning för de olika informationsmodeller jag tar fram. Det blir en karta över vilka verksamhetsfunktioner (eller om man vill kalla det för verksamhetsförmågor) det finns, och hur de relaterar till varandra. Där ritar jag in alla it-applikationer liksom hur de är integrerade med varandra och omvärlden.

Hur man tar fram en sådan förmågekarta har jag ännu inte beskrivit i denna artikelserie, men det är lätt och snabbt att göra, och blir en mångsidigt användbar karta, som visar vilka delar den består av och hur dessa samverkar. Det bli ofta första gången verksamhet och it får en gemensam karta där båda sidorna kan känna sig hemma.

Det intressanta är att det mest effektiva sättet att få fram en sådan karta är att re-engineera applikationsportföljen. Ty informationssystemen är idag en så integrerad del av en verksamhet att it-landskapet, om man tolkar det rätt, faktiskt ger den mest tydliga och sanna bilden av hur verksamhetens olika funktioner samverkar operativt.

Det går till så här: Jag workshoppar med it-arkitekterna och tar hjälp av deras kartor över vilka applikationer som finns. Ty finns det en applikation så finns det en verksamhetsfunktion som applikationen stödjer. Eller som jag vill se det: En applikation är alltid, per definition, en integrerad del av en viss verksamhetsfunktion. Hur dessa sedan är integrerade och används ger nycklar till beroendet mellan verksamhetsfunktionerna.

Att det fungerar går tillbaka på Conways law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.“

Fast då behöver man först göra klart för sig vad som egentligen utgör en it-applikation och vad som inte utgör en it-applikation. En it-applikation är, per definition, ett informationssystem som stödjer en viss verksamhetsförmåga. Det kan således vara ”Pelles månadsrapport”, ett Excel-ark, så länge det har en återkommande och operativ roll i verksamheten. Ett affärssystem däremot är sällan en applikation, utan en plattform för flera separata applikationer. Huvudboken är en applikation, leverantörsreskontra en annan, och så vidare. En integrationsplattform är heller aldrig en applikation, utan en kommunikationsinfrastruktur. Finns det någon verksamhetslogik som körs på en sådan plattform så är denna verksamhetslogik en egen applikation. En applikation som ägs av en verksamhetsfunktion och bara driftas på integrationsplattformen. För en verksamhetslogik måste per definition alltid ägas av en verksamhetsfunktion, och utgör då en applikation som ingår som en integrerad del i den verksamhetsfunktionen.

Andra sätt att nysta ut hur verksamheten hänger ihop utgår ofta från saker som organisationsschemat eller processerna. Men det ger inte fakta på samma sätt som om man utgår från hur verksamheten verkligen fungerar och hänger ihop operativt, enligt ovan. Den bild man får fram när man gör en förmågekarta på det sätt jag beskrivit visar hur verksamheten fungerar på riktigt. Det blir sedan mycket intressant att lägga organisationsschema och processmodeller ovanpå detta.

Ännu mer intressant blir det att lägga på tjänsteperspektivet. Men då är vi kommit långt från informationsmodellering.

Vad beträffar informationsmodelleringen så blir en sådan förmågekarta användbar för att ge kontext åt de olika informationsmodellerna. Allt annat man kan göra med en sådan karta får det bli andra artiklar om.

Steg 2: Identifiera och få tillgång till scheman för de mest centrala databaserna, eller datakällorna

Jag behöver nu snabbt få ett första grepp om de centrala informationsstrukturerna. Det enkla och effektiva sättet är att ”reverse-engineera” databasschema för de mest centrala databaserna. Jag intervjuar it-arkitekter och förvaltningsansvariga för att få reda på vilka de centrala databaserna är. De förser mig med scheman, samt med upplysning om vem som är mest kunnig om respektive databas och som jag kan få störa med frågor allteftersom.

Steg 3: Tolka scheman

Jag går sedan igenom olika scheman, ofta databasscheman, tabell för tabell, kolumn för kolumn, och försöker tolka och rita början till en informationsmodell. Ofta får jag fråga den som vet vad som döljer sig i databasen och jag försöker med dennes hjälp ge bra konceptuella namn och definitioner till entiteter, attribut och relationer. Fast jag noterar också de fysiska namnen för att hela tiden behålla kopplingen till det fysiska.

Snabbt har jag nu ett första utkast till en informationsmodell som jag visar för kunniga it-personer. De ger mig feedback, korrigerar mina missförstånd och snabbt har vi en modell som representerar vår gemensamma förståelse så här långt.

Det här är ett lätt och roligt arbete i verksamheter som har egenutvecklade system. Även om det är gamla system är de nästan alltid relativt välstrukturerade vad gäller informationsstruktur och begriplighet. Det är min erfarenhet. Jag håller inte med om det som ofta sägs, att de gamla systemen är den stora bromsklossen.

Men med standardsystem är det en helt annan sak. Dels har de ofta tusentals tabeller varav nästan alla är så generella att de kan innehålla lite av varje. Ofta är också strukturerna misshandlade, både av företagen som utvecklar systemen och av den senare anpassningen när man har försökt få systemen att åtminstone hjälpligt stödja det som verksamheten behöver. Och vad värre är; ingen i organisationen har någon vidare kunskap om vilka data som faktiskt finns i systemen eller hur den är strukturerad. Om jag då vänder mig till leverantören så är det också där svårt att få vägledning. Dels har de inte så mycket grepp om vilka anpassningar som gjorts och hur olika strukturer har använts hos just denna verksamhet. Dels är de sällan så värst pigga på att hjälpa till om det inte handlar om merförsäljning. Ofta skäms de för att visa sina trassliga datastrukturer.

Arbetet att bringa ordning blir då betydligt knepigare, och långsammare. Men det finns ändå inget annat sätt än det jag beskrivit. Organisationen behöver ta tillbaka kontrollen över sina data och hur det hanteras.

Steg 4: Tolka data

Därigenom går jag igenom data i databaser och filer. Vanligen börjar jag med de mest centrala databaserna. Jag går igenom datainnehållet kolumn för kolumn.
För varje kolumn kollar jag saker som följande:

• För alla kolumner: Finns det tomma förekomster (vilket inkluderar innehåll som på något sätt kan tolkas som tomt)?
• För textkolumner (utom de med ett litet och bestämt antal möjliga värden): Vad är de längsta textsträngarna? Är de klippta? Finns det konstiga värden?
• För numeriska kolumner (utom de med ett litet och bestämt antal möjliga värden): Vad är minimi- och maxvärde? Finns det negativa värden? Finns det orimliga värden?
• För kolumner med ett litet och bestämt antal möjliga värden: Vilka är värdena, och vilka antal har varje förekomst?

Tillsammans med någon kunnig går jag igenom hur man ska tolka innehållet, och bokför alla resultat. Jag listar särskilt de anomalier jag upptäcker, det vill säga de misstänkta bristerna i datakvalitet, så här långt.

Sedan går jag vidare på liknande sätt. Fast med den lite djupare förståelse jag nu har kan jag göra analyser med databasfrågor där jag kombinerar värden i olika kolumner, detta för att hitta mönster i data som kan förklara saker och ting.

Vid det här laget har jag fått en djupare kunskap om befintliga data och vad de betyder. Ofta får vi justera definitioner och ibland även namn på entiteter och attribut. Vi kan till exempel upptäcka att bland det vi trodde var kunder finns även leverantörer eller partners.

Så syftet är dels att få en djupare och mera rättvisande förståelse för vilka företeelser som hanteras av verksamheten och hur, det vill säga en mer korrekt informationsmodell och mera korrekta definitioner och beskrivningar än vad vi annars skulle ha. Dels får vi också en lista på brister till exempel saknad, motsägelsefull eller på annat sätt uppenbart felaktiga data. Detta kan bli input till data management-åtgärder, vilka kan vara att korrigera bristerna men också att utforma åtgärder för att den typen av fel inte ska uppstå igen.

Ibland får jag till och med tillsammans med en programmerare tolka någon algoritm i programkod som bestämmer värde på någon output, baserat på olika kombinationer av input-parametrar.

Också detta är vanligen ett rättfram, roligt och enkelt arbete. Men även här blir det oerhört mycket knepigare när det är frågan om standardsystem.

Steg 5: Fördjupat arbete

I detta läge har vi kommit så långt man kan komma med dessa enkla och rättframma arbetsformer. Det har mest handlat om ett rakt och enkelt arbete. I en del fall räcker detta och vi kan mer gå över i en mer lugn takt, att fortsätta stödja utvecklingsarbetet i organisationen.

Men i många verksamheter finns det områden som har trasslat ihop sig ordentligt. Det kan vara en produktstruktur där man tappat greppet fullständigt. Eller att man har olika strukturer och begrepp i olika system och där ingen egentligen vet hur det hänger ihop. Då är det tidigare kartläggandet bara själva initierandet. Nu börjar det riktigt roliga! Ett detektivarbete med att lägga pussel och hitta mönster i oredan. De mest framträdande metoderna i detta arbete blir att varva dataanalys (för att hitta mönster och mening i oredan) med riktade eller spontana workshoppar med de tyngsta kunniga inom området, ofta analytiker av olika slag. Vi tar oss an ett område efter ett annat. Min erfarenhet är att det kan ta lite tid, men det går alltid att bringa ordning. Bara man har envishet. Man jobbar på, men forcerar ändå inte, saker och ting måste få mogna fram.

Detta är en förenkling

Denna beskrivning är naturligtvis förenklad. I verkligheten blir det mer att man växlar och blandar arbetsformer ännu mer. Men det ger ändå en bild av det typiska, hur tyngdpunkten stegvis flyttas från vissa arbetsformer till andra.

Hur jobbar du som informationsarkitekt? Liknar det mitt sätt eller är det helt annorlunda?