Varför finns det inte ett system som löser det där?

Till de vanligare frågorna Verksamhet ställer till IT hör ”Det måste väl finnas att system som löser sånt här?” IT-organisationens serviceanda, direktiv och uppdragsbeskrivning leder inte sällan till att ett system ”som löser det där” raskt upphandlas och implementeras. Det har lett till att förvånansvärt många organisationer har flera olika system som delvis gör samma sak, ibland på lite olika sätt.

En klok IT-arkitekt sa en gång till mig: ”Ge mig din organisationskarta så ska jag rita din systemkarta.”

Han menade att systemkartan (eller djungeln) ofta är en spegling av organisationsstrukturen. Där varje silo inom sina väggar prydligt och ordnat, upphandlar och inför system som ”löser det där”.

En snabblagad spagettirätt
När internet var nytt som kommersiell plattform rekryterades jag som konceptutvecklare för digitala tjänster till ett telekomföretag. Där talade jag och mina kollegor tidigt om integration, API-plattformar, orkestrering av anrop till tjänster med mera.

Men verksamheten i övrigt fortsatte länge att använda även nya investeringsmöjligheter till att upphandla system, stora system och fantastiska så kallade Enterprise plattformar. Ju mer inbyggda funktioner desto bättre.

Under tiden fungerade vi som jobbade med tjänsteutveckling som ett löst sammankopplat gerilla-nätverk där webbare tillsammans med kommersiella- och tekniska produktchefer tog hjälp av utvecklare av lite olika slag för att bygga webbar, appar, upphandla tredjepartstjänster och det mesta som gjorde internet glatt för våra kunder.

Eftersom vi saknade bra möjligheter till integration uteblev för det mesta nyttoeffekterna i verksamheten och instruktionen var ofta som en kommersiell produktchef uttryckte det: ”Kan ni inte bara göra något kul på internet?”

Hur fick vi då till alla tjänster tänker du nu? Jo, förstår ni, genom att lösa affärslogiken i gränssnittsapplikationen eller om det rörde sig om webb, i CMS:et. En snabblagad spagettirätt och ett effektivt sätt att bygga teknisk skuld, men vi kommer till det lite senare.

Sminka grisen
I en senare roll som konsult inom digital utveckling skulle jag ofta bli efterfrågad i ganska stora affärsutvecklingsprojekt. Mer besvärande var att det inte alltid berodde på allt jag lärt mig om hållbara integrationer under tiden inom telekom 2008–2015. Det var ett helt annat skillset som efterfrågades.

Jag skulle sminka om gamla Java-applikationer från 90-talet som inte riktigt lirade med i den nya digitala tjänsteportföljen. Också en erfarenhet jag hade från tidigare.

När internettjänster började slå igenom runt 2005 satt telekombolagen fast i monoliter i form av billing-system som inte alls var lika intresserade av internets framsida som vi, vilket påverkade produktutvecklingen negativt. Hos vissa av våra grundprodukter var livscykeln på väg utför och det var inte var ekonomiskt försvarbart att ta utvecklingskostnaden för att göra integrationer mot bakomliggande system.

Därför fann vi olika sinnrika sätt att sminka om applikationerna så de såg ut att ha ett modernt gränssnitt, istället för att lösa problemet. Sminka grisen som det kallas i folkmun.

I Skugg-IT:ns dal
Och så var det ju det här med teknisk skuld jag nämnde. När en ny och smart systemförvaltare runt 2012 kallar mig till ett möte för att diskutera lösningsarkitektur för en av våra mer omfattande skapelser, blev jag nöjd och tänkte att nu ska vi prata framtidens webb. Förvisso så.

Två minuter in i mötet fattar hon tag om whiteboard-pennan och går fram till tavlan, hon sa: ”Jag ska rita vår lösningsarkitektur”.

Sen tog hon av korken och ritade med stor inlevelse ett fenomenalt nystan. Klart.

Vi kan säga att den typen av framtidens webb som stavas teknisk skuld präglat den mer betydande delen av mitt arbete som konsult. Att bena ut digitala tjänsteportföljer i enormt komplexa sammankopplingar mellan affärssystem, ekonomisystem, ärendehantering, e-handelsplattformar, CRM, självserviceportaler, produktkataloger, CMS, kampanjsajter, facebook-appar, www2 et al.

Det är lätt att vara efterklok men det behöver ju inte fortsätta så här. Allt fler branscher börjar komma till rätta i sin tjänsteutveckling tack vare aktiv tillämpning av öppna tekniker och principer i sin utveckling.

Det nya öppna
Fordonsindustrin är ett exempel på en tidigare hårdvarutradition (bilen) som nu tar steget ut i det öppna. Flera personbilstillverkare däribland Volvo och Ford har ganska nyligen lanserat utvecklarsajter där de genom att dela sina API:er och data hoppas att nya innovationer och tjänster ska formas med deras plattform som grund.

Också ett smart sätt att scouta utvecklartalanger i en värld där de som är duktiga på att skriva kod är färre än det finns behov för och därigenom hett eftertraktade.

I dagarna lanserar även Allmännyttan sin utvecklarsajt. Där vill vi dela och vidareutveckla öppen källkod och öka API-användningen i fastighetsbranschen. Och härifrån och nu kommer i alla fall Allmännyttans Digitaliseringsinitiativ alltid fråga…

Finns det inte ett API vi kan använda för att lösa det här?
Det borde du också göra!

Terese Skärvagen

Terese är digital strateg och projektchef för Digitaliseringsinitiativet på Sveriges Allmännytta.

Dela artikeln: LinkedIn
Inköpsportal - tipsa oss

Inköpsportal - ansökan
Logotyp, minst 200 pixlar bred *

Maximum file size: 209.72MB

Bild, minst 540 pixlar bred *

Maximum file size: 209.72MB

Kontaktspersonsbild, minst 200 pixlar bred *

Maximum file size: 209.72MB

Inköpsportal - tipsa en kollega