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.