All posts in Solution Architecture

En vanlig definition är att kunskap är att veta eller känna till något, en annan definition lyder att kunskap är sann, välgrundad övertygelse och ytterligare en annan definition är att kunskap är inlärd teoretisk förmåga att förstå, återge och tillämpa information och idéer. Det finns med stor säkerhet fler definitioner och tolkningar kring kunskap och blickar vi framåt in i nästa decennium så tror jag vi kommer uppdatera våra uppslagsverk med en bredare definition kring kunskap för att även inkludera kunskap baserad på kollektiv intelligens och artificiell intelligens.

I vår föränderliga värld så är ”kunskap” något vi tidigt lär oss att man ”måste” ha för att överleva och få ett bra liv. Mängden information runt oss ökar lavinartat och vi ignorerar ofta att kunskap är färskvara för människor. Halveringstiden för kunskap är väldigt kort, men med hjälp av digitala uppfinningar och högteknologiska maskiner så kan vi se på ”kunskap” med helt nya ögon.

The real voyage of discovery consists, not in seeking new landscapes, but in having new eyes

– Marcel Proust

Under hösten så presenterade Microsoft mängder av nya teknologier som avsevärt förbättrar organisationers förmåga att samarbeta och utvinna värdefulla insikter och kunskap från nya och redan existerande källor. Med nya spännande ord som Fluid Framework och Project Cortex så utlovar Microsoft en mycket spännande vision av framtiden. En vision där värdefull kunskap kan utvinnas ur data och information med kontinuerligt förbättrad artificiell intelligens. Genom att samarbeta i realtid med samma information oavsett kontext och dokumentformat kan vi enklare kan få en enda gemensam sanning – Single source of truth (SSOT).

Vad är Project Cortex?

Project Cortex använder avancerad artificiell intelligens (AI) för att leverera insikter och utnyttjar kollektiv ”kunskap” för att automatiskt organisera innehåll och innovativa upplevelser genom ämneskort, intranätssidor och kunskapsbanker i vanliga Office verktyg som Outlook och Teams. Project Cortex använder AI för att analysera innehåll från team och system, identifierar innehållstyper, extraherar viktig information och organiserar automatiskt innehåll i ämnen som projekt, produkter, processer och kunder. Som sedan skapar ett kunskapsnätverk baserat på förhållanden mellan ämnen, innehåll och människor.

Se mer kring Project Cortex på ALMBoK.com

Vad är Fluid Framework?

Fluid Framework är ny teknik och uppsättningar av upplevelser som gör samarbete sömlöst genom att bryta ner hinder mellan olika applikationer.  Stödjer samarbete för flera personer att samtidigt samarbeta direkt på webben och/eller innehåll inne i ett redan existerande dokument. Ramverket bygger på en komponentbaserad modell som gör det möjligt för skaparen att konstruera generiskt innehåll och använda komponenten i olika applikationer. Ändringar sker samtidigt på alla instanser där komponenten används. Detta möjliggör för nya sätt att samarbeta och säkerställer att information alltid är uppdaterad med senaste innehållet och ger även utrymme för digitala intelligenta agenter att arbeta tillsammans med människor.

Se mer kring Fluid Framework på ALMBoK.com

Vad är ALMBoK.com?

Application Lifecycle Management Body of Knowledge (ALMBoK) är en kunskapsbank kring livscykelhantering av applikationer och digitala produkter. Ambitionen är att strukturera insikter kring affärs- och mjukvaruutvecklingsmetoder, verktyg och processer längs hela livscykeln från vaggan till graven. ALMBok.com är helt gratis och utan reklamintäkter, men med möjlighet att stödjas som Patreon.

ALMBoK.com länkar samman information från flera platser på internet, exempelvis Wikipedia och Youtube för att skapa en snabb och ren översikt på kunskapsområden och för att referera till mer djupgående information kring produkter, metoder och externa länkar. Några heta kunskapsområden inkluderar:

Om du skulle vilja hjälpa till att utveckla ALMBoK.com med nya kunskapsområden så kontakta gärna mig direkt på Linkedin eller gå med i LinkedIn gruppen – https://www.linkedin.com/groups/6668160/



SharePoint Spaces möjliggör så att du kan se ditt företagets digitala innehåll i en blandad verklighet (mixed reality) direkt på intranätet. Detta öppnar upp för en ny epok av smarta digitala arbetsplatser med tät integration mellan 3D och artificiell intelligens (AI).

Med SharePoint Spaces kan vanliga användare skapa och visa 3D-innehåll och 360-graders video direkt i webbläsaren. Användare kan även ta på sig på ett headset för att visualisera information och med stöd av handkontroller interagera med innehåll från flera vinklar. Nya möjligheter för medarbetare att interagera med objekt som kan vara för många, för stora eller för dynamiska för att uppleva i den verkliga världen eller i en tvådimensionell miljö blir nu tillgängligt direkt på intranätet.

Företag kan skapa fördjupade virtuella världar för visning av data och dokument direkt i SharePoint. Helt klart ett välkommet tillägg till den smarta digitala arbetsplatsen baserat på Microsoft 365.

Det finns just nu möjlighet att ansöka om tidig tillgång till SharePoint Spaces – Early Access Program

För mer information om SharePoint Spaces – https://www.microsoft.com/en-us/microsoft-365/blog/2018/05/21/sharepoint-innovations-transform-content-collaboration-with-mixed-reality-and-ai/

 


I takt med att informationsteknologi och digitalisering blir allt viktigare för företag och organisationer så blir även inverteringar mer integrerade och komplicerade. Detta leder till att det blir svårare att retroaktivt anpassa fundamenten till nya inriktningar, livscykelhantering blir avgörande för vilka risker och möjligheter man har att anpassa mot strategier och kvalitetsförväntningar.

 

Icke funktionell kravställning & Teknisk skuld

 

I takt med att informationsteknologi och digitalisering blir allt viktigare för företag och organisationer så blir även inverteringar mer integrerade och komplicerade. Detta leder till att det blir svårare att retroaktivt anpassa fundamenten till nya inriktningar, livscykelhantering blir avgörande för vilka risker och möjligheter man har att anpassa mot strategier och kvalitetsförväntningar.

 

Icke-funktionella krav anger kvalitetskriterier

För att undvika att hamna i ett läge där man inte längre har möjlighet att möta marknadens behov inom en rimlig tid och investeringsnivå så bör man redan tidigt etablera nyckeltal som indikerar trender på de icke-funktionella kraven och den tekniska skuld som man har upparbetat i lösningen. Dessa nyckeltal agerar som en baslinje (nollmätning) som man sedan mäter förändringar mot. Det pratas väldigt mycket idag om IT säkerhet och vikten av informationssäkerhet – inte minst i samband med ny lagstiftning och medias reportage kring organisatoriska fadäser inom just IT säkerhet.

Beslutsfattare och kravställare av informationssystem och tjänster underskattar ofta vikten av de icke-funktionella kraven, kanske för att det är grumligt vad det egentligen innebär, samt att det ofta rör sig om tekniska eller designmässiga kvalitetsaspekter och vedertagna begrepp från yrkeskåren. Icke-funktionella krav är krav som anger kvalitetskriterier som kan användas för att bedöma driften av ett system, i stället för specifika beteenden. Planen för genomförande av icke-funktionella krav beskrivs ofta i dokumentation för systemarkitekturen och underhålls vanligtvis av en lösningsarkitekt. Några vanliga områden man pratar om kring icke-funktionella krav är:

  • Säkerhet – Nivå av preventiva säkerhetsåtgärder för att motverka otillbörlig tillgång
  • Förvaltningsbarhet – Livscykelaspekter för att bedöma hur utvecklingsbart systemet är
  • Tillgänglighet – Toleranser för systemets tillgänglighet
  • Användbarhet – Intuition mått för användare att konsumera nya funktioner
  • Prestanda – Kapacitetsmått under tung last

 

Kvantifiera den tekniska skulden

Framgångsrika organisationer använder moderna metoder för att utveckla lösningar med inbyggda kvalitetsgrindar för att systematiskt och inkrementellt bygga lösningen med rätt kvalitetsegenskaper. Vilket innebär att man ibland medvetet inte bygger lösningen med full funktion. Vanligtvis gör man en prototyp för att tidigt utvärdera egenskaper och riktningsbeslut. Eftersom vissa delar har medvetet blivit eftersatta och kommer behöver kompletteras så aggregeras det en skuld, eg. teknisk skuld. Begreppet (teknisk skuld) fungerar precis som vanlig ekonomisk skuld, genom att man lånar för att tidigare kunna erhålla produkten så får man betala ränta så länge man har lånet kvar.  Precis som amortering på ett ekonomiskt lån så betalar man tillbaka sin tekniska skuld med refaktorisering, dvs man förbättrar kvalitén i koden. Teknisk skuld kan mätas genom att kvantifiera attribut och kodmönster med tidsfaktorer och övervakas kontinuerligt (continuous inspection). Koden kan delas upp i olika alvarsgrader som exempelvis att det luktar illa till riktigt buggar och sårbarheter som akut måste fixas före det produktionssätts.

Genom att kontinuerligt mäta och medvetet styra utvecklingen inkrementellt så får man även tidiga varningssignaler och minimerar kvalitetsbrister. Genom kvalitetsprofiler så kan man mäta specifika grader av kvalitetsbrister och säkerställa att man inte överstiger satta tröskelvärden. Enhetstestning och utforskande testning kan påverka kvalitetsgrindar och kan med fördel innefattas i kvalitetsprofilen. Kvalitetsgrindar säkerställer att varje inkrement uppnår rätt nivå och mäts i perioder mot baslinjen för att se trender och tendenser. Ju tidigare man upptäcker en kvalitetsbrist, desto mindre blir i regel skadan och ju enklare blir det att åtgärda.

Kontinuerlig inspektion

SonarQube (www.sonarqube.org) är ett bra verktyg för att kontinuerligt mäta och kvantifiera den tekniska skuld man har i lösningen. Genom statisk kodanalys så analyserar verktyget hela kodbasen och presenterar visuellt hur olika ögonblicksbilder av koden presterar mot den kvalitetsprofil man har fördefinierat. Det möjliggör en dialog kring icke-funktionella kvalitetsaspekter och teknisk skuldhantering som annars kan vara abstrakt och svårkommunicerad.

Genom att visualisera och använda verktyg som SonarQube för att analysera stora kodmassor så kan vi säkerställa att vi ser samma bild och gemensam förståelse för annars svåra begrepp att säkerställa handskakning med tydlig kommunikation med intressenter.

Tillsammans med en partner som har gedigen erfarenhet av kvalitetshantering och med effektiv kommunikation kring icke-funktionella krav så att du som kund kan komma till avgörande insikter och säkerställa att investeringar frodas under lång tid framöver.


Att bygga mjukvaror är svårt, att räkna på investeringar i mjukvaror är svårt, att möta investeringen med rätt byggkvalitet är jättesvårt. Vi vet oftast för lite kring vilken skuld vi har ackumulerat genom de beslut vi tar längs resan och vi fokusera inte ofta på att amortera skulder.

Total ägandekostnad (eng. Total Cost of Ownership, TCO) är något som investerare kalkylerar på för att se vad den totala kostnaden är för en mjukvara inför ett investeringsbeslut. Den totala ägandekostnaden omfattar såväl anskaffningskostnad som driftskostnad men i många fall så räknar man inte med ackumulerade skulder som en del av den totala kostnaden för ägande, kanske för att det inte finns bra modeller för detta eller för att man helt enkelt inte förstår att det kan kalkyleras.

Under en applikationslivscykel så skiftar investeringen från en kapitalinvestering (CAPEX) till en operativ kostnad (OPEX), vanligtvis från ett projekt till en förvaltning. Inkluderat i denna övergång är de skulder som ackumulerats vilket kan leda till oförutsedda kostnader och ytterligare investeringsbehov för att möta effektmål. Det är en stor risk att inte veta vilken skuld man äger och vilka mått av kvalitet man mäter på, detta kanske är än mer viktigt när det kommer till mjukvaror då det kommer strida strömmar av inkrementella förbättringar och de positiva riskerna (vinster) kan kontinuerligt värderas därefter. Det är trots allt idéer som blir till affärsapplikationer, som sparar pengar eller ökar omsättningen.

För några veckor sedan var jag med som talare på en konferens kring systemförvaltning och passade även på att lyssna på övriga talares framträdanden. Ett mycket intressant framträdande var från Johan Magnusson, forskare från Chalmers kring Teknikskuld (eng. Technology debt) och Teknisk skuld (eng. Technical debt). Det bredare begreppet kring teknikskuld som innefattar såväl personal (ideologi, kompetens, arbetsmiljö), användare (nöjdhet, rykte) och system (infrastruktur, skugg-it, teknisk, styrning) kan även ackumulera skuld på samma sätt som teknisk skuld gör vid exempelvis bristande kvalitet i konstruktion av programvara. Väldigt användbart för att hantera såväl risker som nyttorealisering och skuldsanering, ser fram emot mer insikt i denna forskning.

Att automatisera, optimera och integrera leveransprocessen är utmanande, men om inte snabbt införande prioriteras kommer det inte heller att gå snabbt, likaså är avsaknad av inbyggd kvalitetshantering det säkraste sättet att erhålla dålig kvalitet och en stor dold skuld med ockerränta. Genom att kontinuerligt värdera nya insikter och vikta dessa mot baslinjen så kan man istället undvika onödiga problem och säkerställa bra och friska nyckeltal.