AN UPDATE ON SOFTWARE MODELING: PRACTICES AND PATTERNS

by Robert D. Austin, Fellow, Cutter Business Technology Council

Let me begin with a statement of full disclosure: I have not often been a fan of modeling-based approaches to software development, at least not in some of their common manifestations. Software modeling is a practice that often, in my opinion, succumbs to a "forest for the trees" problem. Managers confronting business problems are often justified when they ask, amid mind-numbing discussions about abstract diagrams of yet-to-be-built systems, whether modeling efforts truly move them toward real solutions in an efficient manner. And there is little doubt that some enthusiasts become so absorbed in debates about the theoretical merits of different techniques of, say, process representation -- trees -- that they lose sight of any business forest.

Yet modeling clearly shows potential. If we take a "forest" view on software modeling practices, we see them as no less than the application of automation to support knowledge-intensive innovation -- ways of solving a problem elegantly described by interactive computing pioneer J.C.R. Licklider: "I spend about 85% of my time getting into a position to think." Surely there is great potential in using automation to free knowledge workers from the onerous "getting ready to think" activities involved in software development. Some software modeling practices fall into this category (as do other practices in such areas as automated software testing).

The original, forest motivation behind modeling, which continues today, centered on a vision. If we could construct representations of systems in a language that is more natural for developers and users, and if these representations could serve as a basis for (1) discussion of hypothetical systems functionality; (2) analysis of system completeness, quality, etc.; and (3) direct rendering of the representations into functioning code, this would clearly be a very good thing. Users and developers could discuss what the system should do, test their ideas in the abstract, then push a button that turns outputs of their discussion into code, which they could then experience. Productivity would ensue; so would software quality. Many will recognize this as the vision behind CASE methods, which were heralded in the 1980s. Modelers are making progress toward this vision.

But questions remain. One that seems pressing to me is this: Will abstract diagrams ever truly allow business users to discuss system functionality that often remains hypothetical at the time of the discussion? Given recent rapid progress on prototyping-intensive methodologies (such as XP and its relatives), which aspire to center that same conversation with users around a much less abstract "working code" prototype, and given that prototyping approaches also benefit from progress in automating knowledge work practices, I wonder if modeling approaches will ever find the widespread applicability that some have forecast.

Of course, prototyping and modeling are not mutually exclusive -- not at all. Some modeling practices, those that dovetail with prototyping approaches, will, I believe, achieve broad acceptance. A recent Cutter survey indicates that modeling is not yet used directly by frontline developers, but this may change. Prototyping and modeling may ultimately converge in practice to form a development process that uses working code prototypes for most discussions of system requirements with users, but that employs modeling diagrams and practices in areas in which prototypes don't effectively work (designing data models, for example).

In the debate surrounding modeling, proponents of different approaches often talk past one another. For example, the XP crowd often charges that modelers "don't get it," while the modeling crowd accuses proponents of XP of exactly the same thing. It would not be surprising to me if this Advisor provokes the ire of some modelers and results in complaints about "not getting it." Honest readers will agree, however, that there are deep disagreements about the best ways of discovering what is required of an eventually functioning system. We also should realize that this debate does little in itself to advance the true needs of business managers with true business problems. As "IT people," we must sort this out. Until we do, software modeling will continue to be an area that inspires perplexity in many.

-- Robert D. Austin, Fellow, Cutter Business Technology Council

If you'd like to comment on today's Architecture E-Mail Advisor, send e-mail to architecture@cutter.com, or send a letter by fax to +1 781 648 8707 or by mail to the Architecture E-Mail Advisor, Cutter Consortium, 37 Broadway, Arlington, MA 02474-5552 USA