Updated: February 15, 2018

Over the past few days, I have had the opportunity to sit down virtually with Amit, an accomplished senior Business Analyst, to have focused discussions about UML, the Unified Modeling Language.

Since Amit and I are both quasi-techies, we’ve felt free to wander into object-oriented analysis territory and share various diagrams with each other. We've had even more fun than the blissed-out gentleman in the stock photo above. And our diagrams made sense too.

But our conversations have made me reexamine my opinions on UML and how BAs can leverage it.

It has also prompted me to come up with a new set of criteria we can use generally to assess modeling techniques for business analysis value.

There are around five criteria for assessing UML's relevance to Business Analysts:

1. Usefulness as a personal method 

Will the method help the Business Analyst personally to analyze and understand the problems and solutions under discussion?

Although only the BA can answer this question, UML tends to appeal to analysts that have general affinity for modeling, enjoyment of abstraction, curiosity about software engineering, and comfort with asking “dumb” questions of technologists.

2. Usefulness as a team method

Will the method help Business Analysts work more effectively with their teams?

If the team is heavy on engineers, this may be a compelling-enough reason to invest time in learning UML. A simple state diagram can convey in two minutes what an 800-word document can take hours to get across. If the team tends to be more broadly staffed, however, this lessens the value of the investment.

3. Usefulness as communication

How useful is UML as a general communication tool?

Assuming a typical set of stakeholders, not very. One of the valid criticisms of UML (even argued by Ivar Jacobson, one of its creators) is that it’s very large, and it’s complex overall, and that it takes a fair amount of time and study to learn (for engineers, mind you). This is not promising considering that the majority of our stakeholders are non-technical. If stakeholders have difficulties understanding use case diagrams, the less accessible UML diagrams are probably not the best way to communicate with them.

4. Required investment

What does it take to learn UML?

A lot. See point 3. UML was designed for use by software engineers. A typical BA will have to learn 12 to 14 diagrams (some will probably already be known). To work effectively with some of these diagrams, large engineering topics will have to be understood (e.g. classes, objects, interfaces, inheritance, polymorphism). Some diagrams will require knowledge of how languages compile codebase into discrete files. BAs without development experience – and even many Systems Analysts – and even many developers – will have to make a major investment.

5. Overall business context

This is essentially the “other” category.

Do you work for Microsoft? You should probably learn UML. Are 80% of your stakeholders engineers? You should probably learn UML. Did your boss tell you to learn UML? Learn UML! There are always special factors that can override your decision-making process. Only you know what they are for your situation.

* * *

If I haven’t scared you off UML, good. You should definitely look into it.

If I have scared you off UML, also good. It’s not for everyone, and it probably won’t be for you.

But don’t throw away the entirety of UML. Every BA must be able to construct a Use Case Diagram. Every BA must be able to understand State-Transition Diagrams and Activity Diagrams.

As always, be pragmatic. Learn the appropriate amount of UML that will make sense for your overall situation, and keep an eye out for situations where you can use the modeling language to improve understanding of problems and solutions for your enterprise and customers.

Subscribe