Has UML Died Without Anyone Noticing?

Share on:

The Unified Modelling Language (UML), developed by Rational Software, and adopted as a standard by the Object Management Group (OMG) in 1997, was meant to standardise several disparate pictorial notations in the field of software engineering.

My love affair with UML started almost a decade later, when I started evangelising it as a language to bridge the gap between the IT and business community. I was never entirely convinced about the value of UML as a notation to model concrete software artifacts; my goal was to use UML to describe the desired structural and behavioural properties expected from a given system under design.

The revelation, to me, was the formal semantics surrounding UML Activity Diagrams. I could not stand the informal Visio flowcharts because they were plagued with ambiguity. For example, do two arrows emerging from a box indicate a choice or a split of the flow into two parallel tracks? Likewise, do two arrows pointing to a single box mean that the activity starts as soon as the first flow hits the box? Is it OR, XOR, or AND? You get my point. UML addresses this problem by introducing clear and unambiguous semantics.

The game is rigged: there’s no plausible answer

I was truly invested in UML:

  • I drew most of my own solution’s diagrams primarily using UML between 2004 and 2015 for seven different employers and customers.
  • I ran UML boot camps (for business analysts) for two large customers.
  • As my Master’s dissertation, I identified the key set of discrete mathematics that underpin most structural and behavioural UML models. I even wrote a tool, using Haskell and GraphViz, to visualise said mathematics back into pictorial UML.

A few years later, maybe around 2015-ish, I realised that I had pretty much stopped using UML, and so had the rest of my peers and nearly every Fortune 500 customer I have consulted for recently. What happened?

I know. It was a death by a 1000 cuts. And no, UML wasn’t killed by the business community because of its complexity or rigour. Au contraire, business folks loved the ability to communicate clearly and unambiguously by using a handful of new symbols of conventions. It was the IT folks who brought UML to the table (as I did back in the day) and took it away in a puff of smoke.

But it wasn’t UML that got killed, per se. In fairness, UML was just collateral damage. The massacre was in the entire requirements engineering field encompassing business analysis and design. Agile was the assassin and user stories were her deadly, poisonous arrow heads (pun intended).

In a model in which you pour user stories into a sausage machine, and you get a demo at the end of it (or a feature production release in a DevOps shop!) there is no room for purposeful, structured problem analysis anymore.

In today’s brave new world, understanding is crystallised directly into production-ready code. Even business entity modelling, at large, got killed by Agile’s sister discipline: Domain Driven Design (DDD). Bounded contexts encapsulate (sweep under the rug) complexity so an enterprise can scale by adding two pizza teams. Shops that employ BDD and ask their business teams to write Cucumber specifications directly have the upper hand here but very few businesses do that.

Today’s paradigm, though, is that we are hopeless at understanding the problem anyway. Digital transformation gurus tell us that we should deploy into production and let the users tell us what the business requirement is, rather than formulating it ourselves a priori. We can take multiple shots until we get it right. Yes, fail fast, and often.

So now you understand. It had nothing to do with UML’s shortcomings. We have simply given up on business analysis and formal specifications, which takes us to the next question: what are we using if not UML?

Example of a masala diagram. Source: Red Hat

Whilst some people employ lightweight modelling techniques such as C4, most diagrams in use today, are what I call, somewhat derogatorily, masala diagrams. No hard feelings, I call my own diagrams like this. Why masala? Because they are informal; they cover multiple dimensions at once, they may be both structural and behavioural, logical and physical. They are often a mishmash of the 4+1 architectural model’s views.

How to cook a masala diagram

Multi-million systems, upon which your life and finances depend, are devised, funded and executed entirely on the back of said masala diagrams, with often no more additional collateral than a bunch of epics and user stories.

Ernie, surely my bank’s mortgage system hasn’t been architected using one of these dreadful masala models that you describe.

That can’t be right? Yes, if your bank isn’t running CICS, and the solution was sold last year, it is very likely that it had been entirely conceived using the very same kind of masala diagrams that I am talking about.

Has the world gone mad? No, it’s just that we have just given up on the engineering side of software. It is just a coding affair for now. I am not saying that those who write software aren’t engineers themselves; they largely are. The point is that, at the organisational level, software isn’t being engineered any longer, as per the equivalent processes and artifacts found in disciplines such as mechanical engineering. Boeing would never order a jet engine from Rolls Royce on the back of a set of said informal masala diagrams.

Masala diagrams have a role though. If you take them for what they are, they can be beautiful things. See, they aren’t specs. Their purpose is to evoke emotions. Masala diagrams are valuable when they spark joy in the heart of every stakeholder the diagram is intended for, as per Marie Kondo’s principle.

Ernie, can you add personas to your diagram please?

As much as I disagree with my friends in the Agile camp, I can’t be blind to human happiness. My customers and peers not only keep asking for more masala diagrams, but they also insist that I make them even more masala (that I merge more architectural dimensions in them!) So why be so stubborn?

UML is still in my heart and I still structure solutions using multiple dimensions but, today, I do this in a pure data/tabular fashion. When the time for pictorial representations comes, I get my NutriBullet and my five litre pan out of the cupboard, so that I cook a delightful masala diagram for my lovely customers.