Here's a paragraph from a review I wrote, years ago, of a multi-million dollar health care information engineering effort that had produced the usual foot thick pile of "architecture" documents - and went on to become the foundation for the usual brilliantly successful but utterly useless development effort that killed any hope of positive change in Alberta's health care system for more than a decade.
Consider an, admittedly somewhat strained, analogy. Georges Seurat evolved an information engineering oriented approach to painting in which an image is formed from large spatial groupings of meticulously crafted pixels within which smaller groupings, or individual pixels, appear, while technically perfect, inherently contentless to the eye. The concern is that as one mentally backs away from these three documents no coherent image emerges; clearly no Ver Meer; not even a dark El Greco.
"Strained" may not be the word for it, but the point is that precisely expressed models covering every function point the modeller knows about can produce results that amount to works of art without contributing anything of value to the real goal: understanding the business system well enough to mess with it.
Instead this particular example, and thousands like it elsewhere, produced first class documentation, several enormously successful applications development projects that produced nothing of value to the business, and at least a ten year delay in any opportunity to rethink the basic issues underlying the system's inner workings.
And that's really the most fundamental problem with a lot of modelling applications: they cast in stone some set of assumptions about how the business works and how the applications will be developed and run, thereby harshly limiting the degree of flexibility that can be tolerated in the actual operation of the business and turning the application into a strait jacket for users hoping to get an independently powered exoskeleton.
In some cases, of course, you want both the rigidity and the duplication you get from coding in both the modelling and the programming environments. If I'm designing a control system - and whether it's for an airplane, a nuclear weapon, or a telephone doesn't matter- I've got engineering certainties about how parts behave and there's no human element in the thing's operation. As a result modelling can be useful during application design and is, more importantly, a necessary first step toward getting what's needed: provably correct functioning.
But business applications aren't like that. You don't have engineering certainties about how processes behave, modelling tells you nothing about the forces shaping the processes, and the models abstract the human judgement that should heavily influence the actual business behaviours the application is intended to support.
Most importantly, however, an applications architecture model built up from functions and processes casts those relationships in documentary stone - freezing business evolution and the user's ability to adapt behaviours to the daily realities of external change.
Notice too, that I said "should heavily influence" because what happens when human judgement is taken out of the equation is that you get systems doing things no human being would do -like shipping 400 tons of chocolate candy to a school cafeteria.
And that's really what most formal or methodology driven modelling does too - the process ultimately produces applications that have wonderfully complete documentation, but don't do what the business needs.
In fact I'd like to posit a kind of Heisenberg uncertainty axiom for business application development here: the more formal and mechanistic the modelling methodology used for human mediated business applications, the less effective, more expensive, and more demoralising the resulting application will be.
In other words, if you're developing a business application and want to use a few use cases to illustrate how a couple of lanes make a pool, go for it - but deploying UML (or any other bench set) in all its glory will prove completely counter-productive in the long run.