An Unlikely Leadership Framework
Object Process Methodology

Modeling with Stickmen

Fallen Stickman

From the beginning, I will confess to have harboured some reservations about the Unified Modeling Language (UML) and some of the methodologies and tools that are regularly associated with it. These reservations are interesting because I had become, at the time of its emergence, something of a fan of the Object Modeling Technique (OMT), which stands as a key (an substantially more elegant) precursor and contributor to UML.

These reservations were sparked initially, and it can be said superficially, by the elevation into prominence of the Stickman as a representation of an Actor within a Use Case. Whereas OMT had attracted me with its visual simplicity, I simply found myself unable, aesthetically, to represent any stakeholder in a system as a Stickman.


In addition to what we might call my initial aesthetic reservations, there were, upon further consideration, deeper reasons for my aversion to modeling with stickmen. Project experiences then fortified my objections on aesthetic, theoretical and practical levels. It should be noted that my focus when evaluating modeling notations tends to be from the perspective of describing a system at a high-level in terms of overall behaviour and, in particular, in a way that could be used to engage business stakeholders. It should also be noted that the evolution of UML has been driven by a somewhat different center-of-attention – one where the communication of lower-level system details, in a densely visual way, takes precedence.

A large part of the rationale behind my reservations about UML is that its centre-of-attention on communicating system details does not advance, and in fact directly impedes, the engagement of business stakeholders. More than anything else, the quality of this engagement will determine the success or failure of a project. If this higher-level context can be established and evolved effectively, then the possibility of deploying UML at the lower-levels of system description becomes more plausible. At this level of detail, however, it can be legitimately asked whether the introduction of a modeling notation helps or hinders the practical communication processes that must operate within a development team. What can be confidently said is that there will be circumstances where the deployment of a formalized modeling technique at all levels of system description will be beneficial and even essential. And this will remain true even where, perhaps on smaller projects, developers communicate more successful through direct contact and good coding practices.

To return to our Stickman, part of my objection to its use is the fact that it reduces to a comical simplification the real-world of people, processes and problems. In many ways, the sterile stickman symbolizes the placement of emphasis, within UML, on the internal features of the system being designed and developed. This crystallizes for me the fact that UML has not made the engagement of business stakeholders its primary goal. These stakeholders exist in a world that is external to the system and, from that limited perspective, they are necessarily reduced to a hollow abstraction. The Stickman notation communicates this perspective all too well.

The experiences of a number of projects have over the last few years done much to fortify this rather tepid attitude towards UML. One project in particular comes to mind.

This project was a relatively large one. With a budget in excess of $200 Million, you might even call it very large. On the surface, the project had many of the attributes that might be associated with future success. The project had adopted, at significant cost, an integrated development environment that was intrinsically designed to enable a methodology aligned with UML. And no expense had been spared in training the team and in retaining consultants specializing in the tools, the methodology and the UML notation. The project team was confident that these early investments all but guaranteed success.

But reality took a different path. It would be fair, even charitable, to call this project a failure. Disaster might be the more accurate description. And the failure of the project occurred early in the lifecycle with a complete breakdown of communication between the project team wielding UML diagrams and the business stakeholders wielding budgets. The reasons for this collapse are instructive.

A number of problems emerged. One was that the combination of all of the tools, methodological devices, and the UML diagrams proved overwhelming for the project itself. Ensnared in the sophistication of their early investments, the analysis and design team proved unable to maintain an acceptable pace of engagement with the stakeholders. The second problem was that the perspectives and symbols associated with the various UML diagrams, including and even especially Use Cases, proved alien to the business stakeholders.

Despite well-intentioned and even well-executed attempts to overcome this challenge, the business stakeholders confessed to being unable to correlate the depictions visualized in the models with their understanding of the business. As the discussion continued, it became clear that the problem was not simply that the modeling notation was unfamiliar, rather that the underlying perspectives could not be combined to reflect fully what the stakeholders understood about their business. Eventually the business stakeholders and their management team lowered the boom on the project team and ordered them to prepare business-level flowchart descriptions of the system and how it would integrate with, and impact, their business processes. Without this step being taken, the stakeholders would be unable to endorse any analysis results, design recommendations or technology investments. However well equipped, the project team was unable to respond to this request effectively.

In the years since this project, there has been work directed toward the modelling techniques available to fill this communication gap. This is where the Business Process Modeling Notation (BPMN), which more recently and more inscrutably has been renamed to be Business Process Model and Notation. It is an open question whether the availability of BPMN at the time, or its introduction, would have solved the communication problems facing the project. I suspect that the problems that hampered the flowcharting effort would have also undone any similar effort with BPMN, namely that the volume of low-level process detail being recorded led to spiralling costs and slipping schedules. Going further, I even suspect that BPMN would likely have exacerbated the problem by introducing a more sophisticated representation of event relationships than is normally found in flowcharting techniques.

In the end, the chasm between the two perspectives was never successfully bridged and the project soon entered a period of reductions that were positioned as changes but that in reality constituted a fulsome retreat. The primary lesson to be drawn from the experience was that UML, and its associated tools and techniques, proved wholly unequal to the critical task of forging a common understanding of the business and therefore unable to establish an all-important context within which system details could be articulated and evaluated. Now this may not be a fair charge to level at UML. Despite common claims and widespread belief to the contrary, it may not be within the proper scope of UML, even as augmented by SysML, to address the subject of forging a common understanding of business knowledge. If this is so, something else is needed and the deployment of UML, together with its associated analysis and design tools, should not be attempted until this preceding step is taken.


Feed You can follow this conversation by subscribing to the comment feed for this post.

Yanic Inghelbrecht

Hi Joe,

Interesting. So the project consisted of a team of people new to the method, the supporting tool and UML, assisted by specialized consultants.

I can understand that most of the UML is alien to stakeholders, but then again, UML was never meant to be a customer facing notation.

Two questions spring to mind :
- how were functional requirements captured and communicated with the stakeholders?
- how confident are you about the expertise of the 'specialized experts'?

From what I read above, it seems more of a problem with the chosen method than the notation.

Best regards,

Joe Gollner

Thanks for your note Yanic.

In line with the direction in which your questions are headed, this particular project was challenged in many ways. Most importantly it was embarking on an undertaking of what we might call "multi-dimensional complexity". In other words, they were asking for trouble from the beginning.

What was interesting was that the team assembled, in terms of external experts, was pretty good, in my estimation. As I noted in my post, several of the team's efforts to bridge the communication chasm were in fact well-done.

One of the reasons I became involved in the project (under protest I might add) was the need to find a way to "re-express" the requirements in a way that the business stakeholders could work with. This leveraged many of the efforts that had been undertaken in the project including the past preparation of "process workflow diagrams" (using more traditional flow chart symbols). What we were doing as the project lumbered along was building "supplements" to the Use Cases with these helping to paint a more integrated picture. I actually think we would have eventually resolved the communication challenges had not the "clock run out" as it often does on large projects.

My role in the project, which covered about a year and a half (and on an a somewhat occasional basis) was to review all aspects of the project from a colder, more objective perspective. There were other issues but the challenges around communication were the ones that stand out as the most interesting in retrospect.

As you highlight, and as my closing thoughts touch upon, UML is not really intended for this "engagement" role so much of my argument in fact is less of a criticism of UML as it is a case for a more sound approach to addressing this all-important requirement. This sound approach would, ideally, provide both the needed accessibility, if I can call it that, and formality, so that the business requirements that are established are genuinely useful in the detailed analysis and design activities that must follow.

I believe I have found, after much searching, a good candidate toolset for this, and it will be the subject of one of my next posts. I am always eager to hear about alternatives though.


Hi Joe,

Thanks for taking the time to write such a detailed response.

It is indeed a real challenge to find a language that is both accessible and formal (enough) at the same time.

It will have to involve stakeholder training one way or the other, which can be a hard sell depending on the audience.

One interesting initiative that I came across in that regard was a concrete syntax for OCL (object constraint language) that was business oriented.

I'm looking forward to reading about the solution you have in mind. And of course, I hope it will employ UML sequence diagrams in one form or another ;o)

Best regards,

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Comments are moderated, and will not appear until the author has approved them.

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)