UML is not a language suited to most aspects of EA

(prompted by discussions with EAs and "How UML is Used")

UML is often one of the first words that comes out of IT people's mouths when one discusses EA (in a bizarre attempt at logocide one organisation evens call its UML modelling tools Enterprise architect).

UML may be very useful, but not for most aspects of EA. This is because most of EA has little to do with OO modelling oriented at OO development (or SW development and per se) and because UML is just not effective for communicate with most of the business (i.e. not technical people).

The analysis that needs to be done in EA is not really related to: the different states that objects can exist in, the messages that objects used to communicate, or low level technical "use cases". Obviously an EA needs to consider scenarios of use (how things are used in different situations by different roles or systems). And one could use the very oddly named "use case" for this, however many other mechanisms are available usually better suited to use in EA. In my experience the quickest way to alienate most business people is to start of by using abstract terms like "actor", or talk to them Swedlish. Most people in the business prefer natural business concepts like: business process, business role or organization, etc.

That people attempt to apply UML to enterprising architecture probably indicates the mistaken belief that EA is somehow an extension of software development - and goes a long way to explaining why some many EA initiatives fail.

There are various aspects of detailed SW design oriented analysis that we may wish to relate to from an enterprise architecture or we may wish bring together for analysis the disparate views of various development silos e.g.
- process orchestration development views which use BPEL that may relate to BP models
- object development views which may relate to UML models
- data development views which may relate to ER models
etc.
This is more in the solution architecture rather than enterprise space. What an EA can do is bring together these disparate silos. For example we could consider the relationship between a business process or a business role/organization, and a business application (and elaborate that relationship using UML - if it really added value). But for most people getting a canonical list of business processes or business applications would be a great starting point - rather than elaborate great detail one interaction

We could also consider the broader issue of the utility of UML in capturing requirements per se. UML is also often also one of the first words that comes out of IT people's mouths when one discusses business requirements.  This is mostly the case when IT people with a SW engineering background are involved. Or when executives want to show they an "in" with technical people by using their arcane terminology,

UML not useful for most, if any, aspects of business requirements management. Business requirements may result in software development (the majority will not). Of those that do require development only a subset will require OO (e.g. others may require BI). Often when development is required it will be outsourced or done under contract. What the business needs is boundary of responsibility that allows those solutions elements delivery to be assessed.

By way of analogy. If one has transport requirements - one doesn't to be asked what use case of a brake pedal is. One wants either a transport solution (streets, tracks and trains, roads and vehicles, ships and ports), or a services (e.g. buses, taxis), or possibly an in-house asset car, a bike, a plane. In the rare circumstances where a car is engineered for a client - it would be a very brave (or foolish) client indeed who would try to specify it, or its components, using Use Case, Sequence diagrams.

In "How UML is Used" by Brian Dobing and Jeffrey Parsons - it seems reasonable to assume that as the data references in this article is gathered from UML practitioners/clients they are not unreasonably prejudiced against UML. What bemuses me is that the authors - despite the facts in front of them - doesn't seem to just say "UML is not great for client facing requirements capture" or for communicating with non-technical audiences. This doesn't mean UML may not be great for technical communications e.g. between designers and developers.

What can we learn about "How UML is Used" regarding requirements capture?
- UML may be too complex for clients (no kidding) and those who are not technical (i.e. who don't want to participate in development).
- UC are not thought that good for communicating with clients (business people)
- Clients (business people) don't want to review the artifacts beyond UC narratives (and why would they, when these are really development/developer oriented models)?
- UC diagrams are rated as least useful in providing additional information to developers.
- Despite the above developers, undeterred, seem to believe that UML diagrams can be understood by clients?

Contrary to claims in the popular literature, developers appear to believe that UML diagrams can be understood by clients. 87% of respondents rated UC Narratives as useful for "verifying and validating requirements with client representatives on the project team.", but when asked whether the UML facilitated communication with clients, 55% said it was at best "Moderately Successful."

Domain specific business languages (or Enterprise specific languages) may be a better answer. To instantiate these dynamically so they are available for modelling, one needs a metamodeller.

EA requires an ability to communicate on many subjects with a diverse range of stakeholders. Selecting an arcane language oriented at object oriented analysis is unsuited to the task i.e. both the semantics and the notation are a poor fit for the vast of the information used to describe an enterprise.

If UML struggles to capture the requirements for project in which development undertaken (i.e. to act an effective mode of communication) - surely people can see that if the task is describing an enterprise (where development is not the major goal i.e. it is a necessary evil) - it is unlikely to be a good fit.

Of course long before this Anthony J H Simons, Ian Graham wrote about: 30 THINGS THAT GO WRONG IN OBJECT MODELLING WITH UML 1.3. In this the authors catalogue problems experienced by developers, using various object modelling techniques brought into prominence by the widespread adoption of UML. Developers still seem to create inordinate problems for themselves by pursuing unproductive development strategies that are apparently fostered by UML. This article shows how the biggest problem by far is cognitive misdirection, or the apparent ease with which the rush to build UML models may distract the developer from important perspectives on a system. This problem is more serious than the outstanding inconsistencies and ambiguities which still exist in UML. While UML itself is mostly neutral with respect to good or bad designs, their are consequences of allowing UML to drive the development process.

The cognitive misdirection problem is more serious when UML is applied in domains other than OO design. In these case the pursuit of unproductive strategies oriented around UML can only consider "the triumph of hope over experience" (Samuel Johnson).

See www.semanticprecision.com for a better solution.