Twin examples of multiple trees: 1. UML models, 2. Machine Learning



“Today, professionals get trained in using tools…  there’s a lack of education of fundamentals like modeling, architecture, methods, or concepts... Getting value out of data needs professionalization based on education and practical experience.”                                                                 
Andreas Buckenhofer, Daimler TSS, in an interview by OODBMS on Big Data, July 2019 
In my opinion, he’s spot on.

My post from March mentions why new AI languages aren’t exactly heavies of a CV in a mainstream business; in April, a figure (at the end of the post) also touched on Forest structures in ML and eXplainable AI.

After a free-wind sail that took us from detail to architecture, we now go into some structural “forestry”. It’s about tackling the same domain from multiple viewpoints, instead of clinging on to one.

1. Multiple trees in UML: Generalization sets
This post from 2015 (in Swedish) discusses the sets in more detail, so let’s just recap the diagrams, in English, and add «powertype» on the fourth one (a power set’s instances are subsets, so by the same token, a UML2 powertype’s instances are “subtypes” of a general construct).






2. Multiple trees in Machine Learning: random Decision Forests
Here, a designer is not the one who maps out subclasses. Rather, an ML algorithm generates in training time, from (labeled) data, an ability to perform classification (i.e accurate “mapping-out” of “classes”). The decision nodes of a (classification) tree gradually subdivide the data into more and more fine-grained classes.
Why bother about decision trees when Deep Neural Networks are booming? Because explainability opens the door to acceptance in mission-critical apps. ML-generated logic has to be auditable. User enterprises are pushing for graphicness, conceptualization, traceability, V&V. Those are the strengths of decision trees, and weaknesses of Deep NNs (we know those work, but hardly how); same thing with learning time required, size of training data sets, execution speed, or partitionability (a hint for IT architects: a tree works independently, whereas a neuron relies on many other ones). Atop of that, decision trees offer a structural backbone of hybrid AI systems (see also the last paragraphs in this post).

You might remember that trees in woods sometimes fuse their roots and exchange materials. Unsurprisingly, we find some synergy in virtual forests too. Firstly, our trees are “grown” on a random sample each (hence some “biodiversity” too), from one training-data set (hence fewer terabytes of training data). Secondly, on each sample, its tree’s decision nodes use a random subset of all available attributes. This gives architects and other roles some room to tune the mix of efficiency and explainability; in forests, it’s is near the level of genetic algorithms (GAs too have possible “mix-tuning points” in “biodiversity steps” Crossover and Mutation).



The more trees and “biodiversity” our ML algorithm grows, the more accurate and robust the generated logic becomes, because the final step is vote counting. A forest’s output (a classification like here, or a forecast) is an aggregated value of the outputs of all trees (a statistical mode in classification, or a mean in regression). It prevents the random decision forest from getting stuck in local optima, that is, we minimize error rates and overfitting to a given training-data set (which may be both incomplete and biased).

Trainer at Informator, senior modeling and architecture consultant at Kiseldalens, main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).
Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, rules, and design. You can meet him in September at public courses (in English or Swedish) on AI, Architecture, and ML (T1913), Architecture (T1101, T1430) or Modeling (T2715, T2716).



Konsument-IT som liknar företags-IT

Christer Norströms presentation under SICS Open House 2018 handlade om hans intelligenta träningstjänst Racefox. Den stödjer individanpassad uthållighetsträning för löpare och längdåkare. Arkitekturen och kraven på Intelligenta träningsassistenter ligger ungefär halvvägs mellan ”vanlig” konsument-IT (gadgets) och företags-IT (mission critical).

Expertanvändare i gränslandet
Christer (tidare VD på SICS) med sina slides fick mig att mer eller mindre ångra två saker. Dels att jag la av med triathlon för ett antal år sedan. Dels att jag brukar dra den vanliga gränsen mellan B2C (Business-to-consumer) och B2B lite väl skarpt, oftast för att lyfta fram skillnaden i kvalitetskraven mellan dem.

Med tiden har Racefoxs logik utökats med skadeförebyggande eller –rehabiliterande inslag i träningen, i realtid, och då landar vi i gränslandet: expertkonsumenter minst lika pålästa om sin nischproblematik som processägaren på ett företag är om sin. Höga krav på tillförlitlighet, snabbhet (RT), exakthet. Samtidigt högt ställda förväntningar på att behålla kunderna (Racefox är uppe in en customer-retention faktor efter 1 år på 95%).

Arkitektur och arkitektroll
Autonoma Machine Learning (ML) system är ofta indelade i fyra lager, inte så olikt RT-system:
1. Perception (från input genom t ex Racefox kroppssensorer eller bilens givare)
2. Mönsterigenkänning (t ex kroppsställning och stavtag hos Racefox eller ojämn gång i en motor)
3. Analys, resonemang, beslut (dvs mönsterutvärdering och val av nästa steg)
4. Direkt åtgärd (t ex minska varvtal) eller interaktion (t ex varning genom genererad röst i skidlöparens hörsnäcka, eller ett anrop på bilverkstadens diagnostiksystem över Internet of Things).

Layered (arkitekturmönster). Modifierat från Informators kurs Avancerad Modellering (T2716).

Varje lager kan innehålla även ML-komponenter (t ex neurala nätverk tränade för sin nisch). Det gör en stor och trogen användarbas extra intressant, eftersom systemet blir smartare med tiden då det lär av allt längre tidsserier data från alltfler individer.

Bästa bakgrunden för en arkitekt blir då kunskap om domänen, om affären, om ML, om varje lager, och om samspelet mellan dem. Christer Norström kallade rollen value architect.

Milan Kratochvil
Informatorlärare, senior modeling & architecture consultant Kiseldalen.com, huvudförfattare: UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).


Milan och Informator samarbetar sedan 1996 inom arkitektur, modellering, UML, krav, och design. Du kan träffa honom på öppna kurser i Arkitektur på engelska eller svenska ( T1101, T1430) i maj och juni, eller i Modellering i maj ( T2715, T2716).

4 Witty Names for Overdoing Things Upfront, and How Much Is “Lagom”?

“We’ve many names for the things we love” is a proverbial phrase (its Swedish equivalent basically swaps “things” for “child”). Which in turn makes me wonder if human nature loves overdoing the upfront spadework and sometimes even prefers it to making things take shape. Contrary to what IT-people tend to believe, IT is not alone in the overdoing trap.


1. Analysis Paralysis
Is often IT-related in some way, but can actually occur even in financial analyses or big-data analytics with unclear objectives. Long story short: YAGNI (You Ain’t Gonna Need It), plus the problem domain changing as you go (and increasingly, being automated).

2. Researchitis
(Excessively researching the background of things,) is common in journalism and other writing professions. In the age of search engines however, it tends to precede most things we do.

3. Blankscreenophobia  
(Fear of a new blank page on the screen,) is both a sequel and an aggravator of number 1. or 2.

4. Writer’s Block
(In Sweden called write-cramp). To extend from writing to drawing, coding, and other tasks: “Brainslump” fits most kinds of work, but has a shorter duration than writer’s block.


Then, how much upfront work is “lagom” (the Swedish for just right, just large enough, sufficient, adequate, not too little not too much)?
The time spent upfront shall be worth less than the benefit it brings about (as our Architecture and Agile Modeling courses point out, see diagram). Estimating that benefit implies some insight into the needs of the recipients/users: do they want it comprehensive - or rather comprehensible, up to date, in sync, and informative? How can it facilitate their work and decisions?

Summing up
Both in Agile and elsewhere, there’s a fine line between unnecessary overhead upfront and building upon the sand. Neither modeling, nor architecture (IT, SW, Product, Enterprise), nor other high-skill work is exempt from the tradeoff.



Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, 

main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer),
Advanced UML2 Professional (OCUP cert level 3/3). 

Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, analysis and design. In the next few months, you can meet him at Architecture ( T1101 , T1430, in English or Swedish) or Modeling courses ( T2715, T2716 , mainly in Swedish).
x