Nobody, or at least, almost nobody in the software engineering world believes in the waterfall design model any more. Like Santa Claus, waterfall sounded like a great idea (old guy comes down chimney and leaves free stuff in living room; planners work out all issues during design phase so that implementation is easy and predictable), but a little maturity and experience forces us to leave both fantasies behind.

So now we mostly agree that software and information system design has to be iterative and agile, and after years … well, decades … of heartbreaking failure, we’re actually starting to be able to deliver projects that work on a reasonable schedule and for reasonable cost.

But how do customers know what to order in the first place? Out of curiosity, I spent some time reading through the UN/CEFACT Modeling Methodology, or UMM, the business-side counterpart to the technological ebXML specifications from OASIS (the two can be used independently). If you don’t feel like reading hundreds of pages of documentation, here’s a quick summary: the UMM is a top-down business-modelling approach using forms and UML models to move from an abstract, executive-level view of a business to a more concrete, information-management view. Once the final, low-level UML model is ready, it can be handed off to technologists for implementation using ebXML, Web Services, or anything else convenient (it tries hard to be technology-agnostic). The decomposition of business modeling goes through four stages, called views:

1. the business domain view separates the business into areas and processes, from the perspective of senior management
2. the business requirements view deals with scenarios, inputs, outputs, and so on, from the perspective of an expert in the business domain
3. the business transaction view is pretty-much the same thing, but more concrete and from a more technological perspective (i.e. less what? and more how?)
4. the business service view deals with services, agents, and other stuff, and gets passed off to the software developer for implementation

In other words, it’s a waterfall. If that approach doesn’t make sense for technology, can it make sense for business management? As far as I can tell, business management and technology both deal with building robust, predictable systems against constantly-changing requirements and unpredictable inputs, so my own hunch is that a top-down approach like the UMM will not serve business itself well, and will make life hard for the technologists feeding out of the bottom of it.

In fact, I think that the problem may go much deeper, because no matter how business requirements themselves are developed, top-down or bottom-up, there is usually a waterfall-style leap between business requirements and technology requirements: businesses are supposed to figure out what they want, and technologists are supposed to figure out how to give it to them. In reality, however, business requirements are often driven by the technology available: few businesses were interested in setting up an online presence, for example, until the web made it cheap and easy to reach customers that way; outsourcing technical support to offshore call centres is economical only because of certain types of technology; opening up an organization’s systems makes sense only if enough potential partners are using something like ebXML or Web Services; and so on.

We’ve gotten a lot better at building systems to spec, so if we’re going to see similar improvements in the future, we’ll have to start looking at the specs themselves, learning to iterate all the way back up to the top, instead of just inside our little technology sandbox — in other words, it’s not just the technical requirements but the business requirements that have to be agile. If that means that the CEO occasionally has to be troubled with nuts-and-bolts details like web protocols or database scalability, so be it — it beats losing the whole company to a bad technology decision.