The Content Philosopher

Modeling with Stickmen

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 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 both the aesthetic and theoretical levels. It should be noted that my focus tended to evaluate modeling notations 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 process owners. The evolution of UML has been driven by a somewhat different centre-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 utility of UML at the lower-levels of system description can then be deployed amongst designers and developers for whom continuous communication using documentation is critical.

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 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 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.

An Unlikely Leadership Framework

A quick survey of recent business literature will highlight the current prominence of "leadership" as a domain of interest. Exploring why this would be so at this time and plumbing the depths of what has been emerging as an interdisciplinary field of research are worthwhile tasks.

During a workshop in which I participated, a specific challenge was introduced for consideration. The challenge bundled together an all-too-familiar set of problems and did so with specific reference to the healthcare sector. Costs were spiralling out of control, the complexity of the services and infrastructure was outstripping current management mechanisms, and the community of stakeholders was expanding and growing more demanding. On top of it all, change was being introduced in every facet of the sector by uncontrollable demographic forces. Against this was placed the challenge: How can professionals working in this community muster their resolve and resources to respond? It was framed, with good cause, as a question of "leadership".

The magnitude of the challenge, both within the context of the workshop and on the larger plane of reality, was such that the most natural response was one of overwhelmed paralysis. It was a circumstance where a framework, and working set of definitions, would need to be introduced in order to organize information and initiate discussions. What was needed was "intellectual scaffolding" that would allow participants in any discussion to ascend to the various levels of the challenge where the details could be analyzed and solutions hammered out. This scaffolding was going to be an artifice but this should come as no surprise. What else could it be?

So just such a framework was introduced. This framework was drafted with reference to many of the themes seen within leadership literature. The first step was to introduce the above four-part breakdown of the challenge dimensions: cost, complexity, community and change. Making the artifice of the emerging framework clear, alliteration was embraced as a rhetorical device. A parallel model was then introduced under which a response could be elaborated along the following dimensions: innovate, integrate, involve and inspire.

Some readers familiar with the nascent domain of leadership studies will even notice that the choice of colours used in the graphical illustrations of the framework echo those seen in many evaluative tools leveraged for assessing individual and organizational capabilities. In a way that is both uncanny and predictable, challenges and proclivities are frequently decomposed into quadrant models and these models all too often map interestingly to the four humours that ultimately descend to us from ancient times.

Given the specific association of this leadership challenge with the healthcare sector, the attractiveness of invoking Hippocrates (460 – 370 BC), the Greek founder of what we will call western medicine, proved irrestistible. The framework provided by the four humours in fact offered more benefits than its advocate (yours truly) expected. By comparison to some of the alternative models available, all of which were associated with commercially licensed methodologies, the model of the four humours proved to be at least as informative and in many ways superior. And as any claims on the intellectual property manifest within the framework could safely be considered to have lapsed over 2,000 years ago, teams seeking a solution framework were free to mine this resource aggressively.

For the purposes of this effort, the framework expressed with the four humours, as used by Hippocrates, offered a very functional tool for organizing the concepts and positions associated with establishing a leadership strategy for the healthcare sector. Indeed, it has, in this particular case, been generalized to apply to all discussions of "leadership". Applying the framework had some interesting effects such as helping to differentiate between areas of focus that might otherwise be lumped together. And with these differentiations, the various areas became associated with specific types of leadership roles. The overt recognition that there are different types of leaders and that any significant undertaking will require that a balance be established amongst these leadership roles illustrates how harvesting historical models and leveraging them as artificial scaffolds can yield significant benefits for even the most modern of initiatives.