Big (data) news om Panama Papers, noSQL, och IT som draglok som kvällstidningarna missat

Skillnaderna i DB-arkitektur mellan RDB och noSQL, och deras inverkan på kvalitetsattribut som prestanda, skalbarhet, modifierbarhet mm är väl beskrivna både i kurser och på nätet. När man kommer in på vilka typer av verksamheter som är ”nischen” för respektive arkitektur så brukar det bli mer diffust. Ändå är verksamhet och IT alltmer sammanflätade. Hade Panama Papers publicerats tio år tidigare, hade de i stället för global scoop mest liknat en överbelastningsattack - på hela världens pappersbruk…

Låt oss ta vid där mitt förrainlägg slutade. Det är en klasskillnad i komplexitet mellan gångtunneln vid pendeln och nya Gotthard-Basistunneln på 57 km med toleranser under 13 cm. Och en liknande skillnad mellan att basa över chaufförerna i lastbilarna och att leda kunskapsarbetare som arkitekter eller ingenjörer, på samma bygge. Det har managementteorin påpekat i ett halvsekel (men teori och praktik tenderar att bara bli lika i teorin…)

När jag läste intervjun på ODBMSIndustry Watch med ICIJ:s data- och forskningschef Mar Cabra, kom jag ihåg min första kontakt med ”pre-SQL” och så småningom tidiga noSQL DB. Först hierarkiska DB, för framförallt komplexa produktstrukturer (ABB ROSAM, IBM DL/1), senare en UML-miljö för utvecklare (Component Factory) med en OO DB i botten. Vad har då tolkning av 11,5 miljoner Panama-filer med 2,6 Terabyte data i alla upptänkliga format för gemensamt med PDM, CAD/CAM, eller UML-CASE?

I ett verksamhetsperspektiv är det komplexitet, teamarbete och högt kunskapsinnehåll. I ett IT-perspektiv är det bl a:

komplexa heterogena datastrukturer (inte enbart tabeller, långt ifrån) som dessutom behöver åskådliggöras grafiskt (i UML miljön som standard UML diagram, i Panama Papers som noder där en nod visar sina kopplingar till andra noder när användaren klickat på den)

förlopp och skeenden är viktigt, så att animering (i UML) eller gamification (i Panama Papers)

fördjupar förståelsen av hur komplexa saker fungerar

få anrop totalt sett, och oftast fler frågor (”Q”, i CQRS) än uppdaterande transaktioner (”C”)

timslånga transaktioner: man laddar ner en ritning, pratar över den med kollegan, t ex om olika

 alternativa lösningar, och efter någon timme ändrar i den (eller inte)

stöd för distribuerat samarbete som t ex publish/suscribe (t ex går en ändring man gör på sin 

skärm in i OO DB med autosave, och därifrån vidare upp till alla andra som har samma ritning uppe 

på sina skärmar, vilket naturligtvis även gäller bakåtpilen när man behöver ångra en eller flera steg 

bakåt i DB-loggen)

en del lateralt tänkande av arkitekten: varför valde ICIJ (eller tidigare SLL och KS, för lansering 

och uppföljning av nya läkemedel) noSQL-strukturen graph, mest känd från FB, Linkedin, & Co? 

Mar Cabra fick naturligtvis frågan under intervjun. Hon svarade: därför att allt (i Panama Papers) 

handlar om förhållanden, folk kopplade till varandra eller till företag.     

Inget av detta är särskilt viktigt i säg, hotellbokningssystem, där RDB sitter säkert i sadeln ett bra 

tag till. I många noSQL-sammanhang är däremot arkitekturdokumentationen även en viktig länk 

mellan IT, Knowledge management, och kunskapsteknologi:

’De flesta ”systemutvecklingsmetoder” som finns är helt uppåt väggarna fel. (…)

Systemarkitekturen (…) är absolut viktigast!’ (Christian Ekvall, hjärnan bakom Scanias 

orderkonfigurator med 150 000 regler för att tackla ett par miljarder möjliga produktvarianter - 

att jämföra med XCON’s 30 000 regler på Digital, numera HP).

Graph och UML-modell – olika men ändå släkt.

(Bildkällor: ICIJ resp Select Business Solutions)

Där produktkomplexiteten, kunskapsinnehållet, och kraven på modifierbarhet och på stöd för samarbete är tillräckligt höga, ska man alltså noga överväga noSQL.

/Milan Kratochvil

konsult, Kiseldalen.com

Huvudförfattare: GrowingModular: Mass Customization of Complex Products, Services and Software samt UMLXtra Light: How to Specify Your SW Requirements

UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Milan samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys, arkitektur och design. Håller f.n. kurser i grundläggande Arkitektur, Modular Product Line Architecture (T1430), i modellering (T2715, T2716), och 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.