UML Must Die

One of the few things in this world that causes me to break into a cold sweat is UML.

UML stands for "Unified Modelling Language" and by the mere fact that it mentions the word "language" you can understand that is is a tool deeply loved by those up to their armpits in RAM, ROM and other technical pleasures. Like most things evil in the world of process it crawled out of an engineering environment - this time a software one.

Quite simply UML needs to crawl back up the cavity it came from. I'm sure there are software engineers out there that worship it, but when it comes to process it needs to die a quick death. The reason for this is quite simple - no-one understands it. No, not me, not the enterprise architects, not the BA's and above all else the business certainly do not understand it. And if we fail with the business's understanding of THEIR OWN PROCESS, we simply fail altogether.

If you want to create cohesive, understandable processes that will give the business confidence in your ability; keep it simple, keep it clear, keep it concise and keep well clear of UML.

- TPN

Comments

[Seidewitz]

I understand UML. Actually, I understand how to model processes in UML both at a formal level (having worked on the recent standard for the precise semantics for UML activity models) and, more importantly, I understand how to use it at a pragmatic level.

For example, last year my team completed a business process and role model of ALL human resource processes at the US General Services Administration, across all organizations and regions in that very diverse agency. In doing this, we talked to primarily HR professionals, not IT and technical folk. And we didn't take the time to specifically teach them UML, nor were we dogmatic in its use -- we simply drew UML diagrams (using primarily the MagicDraw UML tool) that represented what we heard from interviewing them.

And they loved it. More than once we heard from the staff in an HR office "Wow, what tool are you using? We would like to be able to document our processes like that so we can get a better handle on what we are really doing."

Due to unfortunate budgetary politics outside of our control, our funding to further support the Chief Human Capital Officer with business process modeling ended last July. However, I have kept in touch with our former sponsors, and I have been quite pleased to find that, even though they never have had any formal UML training, they continue to use the models we did as the foundation for the continued process improvement and transformation they want to achieve -- including very visible presentations within GSA and to the Office of Management and Budget -- and to hold them up as an example of successful enterprise architecture at GSA.

The issue is really not UML. The issue is using models to communicate, which is really the reason to do the models in the first place. If a modeler is using UML (or BPMN or informal PowerPoint or anything else) to create models that don't communicate, then that is the fault of the modeler, not the fault of the language.

A modeling language is just a tool. Saying "UML Must Die" makes nor more sense to me than saying "Hammers Must Die" because too many people see too many things as nails.

-- Ed Seidewitz

[The Process Ninja]

Well, some hammers should die. Some hammers are cheap, nasty and don't do the job - they can't hammer in nails properly - they bend nails or break them...but if there is nothing other than a bad hammer to use then people will use it, right?

[Jørge Perez]

Hi Process Ninja,

The Unified Modelling Language is a diagramatical language for software developers. In fact, as a Process Analyst myself i did a small course to understand it. The unfortunate thing with it is that no one understands it. In fact, as software developers and process analysts, it is our job to VALIDATE our interpretations of their business.

UML only confuses people.

Mr Seidewitz talks about people loving the tool rather than the modelling language itself. I couldn't verify whether the HR professionals actually understood UML or enjoyed understanding it?

UML must die in the process world as it does not represent the tasks and steps of what people do in a process, and business people will never understand it.

[NeilS]

UML is a useful tool in that - when compared to other diagrammatic process mapping tools it is reasonably user friendly.

If you can not understand a picture of a person linked to a box with a label saying 'logs in' perhaps you're in the wrong field? I do not see you proposing an alternative, so judging by your post we should kill UML and......? just give up?

When attempting to understand a business process in order to build an application we need to take a process that can be relatively complex and model it into something that can be easily documented, understood and interpreted. In other words, I should be able to speak to the business and document what they are experts in a manner than they will understand (pictures are useful here). Equally importantly - it has to be documented in a manner that - should someone take my place tomorrow, they will be able to pick up the document and understand the business process. Again - if you have a better means of doing this that would make a tremendous post, I would love to read about it.

Just wanted to add - UML, as with all tools, must be in the hands of a skilled resource. If you give me a chisel, you're asking for trouble - but if you give a stonemason the same chisel you can have a masterpiece.

Neil Samtani

[The Process Ninja]

Reasonable user friendly - yes, in 1983...

Quite simply Business Process Diagrams should be displayed as swimlane diagrams. These can be used to document processes at various levels of detail and the business understands them as they can quickly identify the tasks that they are responsible for. I am intending to write a long post on how to do different levels of swimlane diagrams. I am very much in agreement with Alec Sharp - arguably the world's greatest process mapping guru. He uses swim lanes and that's good enough for me.