HOW SOFTWARE MODELING TOOLS ARE BEING USED

by Tom Welsh, Senior Consultant, Cutter Consortium

The many changes in the information technology industry over the past decade have given rise to an increased use in software modeling tools. Based on the replies of 182 respondents to a June 2003 Cutter Consortium survey on the use of software modeling tools, the salient facts about the market penetration of automated tools and how those tools are used include the following:

• More than half of organizations already use automated software modeling tools, and a further 10% expect to do so in the future.

• Of those organizations that use or plan to use modeling tools, 75% plan to make more extensive use of tools in the future.

• More organizations are engaged in data modeling and process modeling than in object-oriented (OO) or business modeling.

• A remarkable 82% who do modeling of some kind use the practice for business/commercial purposes rather than for technical applications.

• Of those with modeling tools, 58% use them for analysis and design; another 29% for analysis, design, and code generation.

Before starting to code, it makes sense to analyze the task at hand and to work out an efficient, robust design for a solution. Various experts have suggested suitable notations that tend to be graphical because, as the saying goes, a picture is worth a thousand words. Some of these methods can be worked through by hand, with simple aids such as a whiteboard or a stack of cards. But since the introduction of information engineering in the 1980s, the strengths of automated analysis and design -- or modeling, as it has come to be known -- have been apparent.

The modeling tools of the early 1990s flattered to deceive, under the banner of CASE and IBM's failed AD/Cycle strategy. Today, however, conditions are more favorable. Ordinary desktop computers have become vastly more powerful; user and data-source interfaces have been improved and standardized; and whether they realize it or not, developers increasingly need modeling tools as they tackle bigger, more complicated projects.

Up front, we wanted to know how many respondents actually use automated software modeling tools. The survey found that 55% currently use them, while 30% do not. Another 10% don't use modeling tools yet but plan to adopt them in the future, while just 2% had used them but no longer do so.

This level of adoption is higher than might have been expected. While there definitely is a mass market for modeling tools, it is probable that fewer than 500,000 licenses were sold worldwide in 2000 -- a number unlikely to have increased much since that time. On the other hand, it's quite likely that most organizations buying modeling tools purchase only a few licenses each.

Traditionally, companies that take the plunge by investing in modeling tools have tended to buy them for only a few senior staff such as analysts or architects. Meanwhile, some vendors have launched sales campaigns aimed at persuading their customers to buy modeling tools for all their developers. The "analysts and architects only" approach goes hand in hand with a largely discredited practice in which the privileged few create beautiful, detailed models that they then "throw over the wall" to less-experienced (and lower-paid) programmers. It's far harder to write code that accurately implements a paper model than to generate skeleton code at the click of a mouse. So automatic code generation seems to be the way to go, with the implication that all developers should have their own modeling tools.

Having established present-day levels of use, we naturally wondered how use will likely change in coming years. So we asked respondents how their organizations plan to use modeling tools in the future. Of the 125 respondents who answered this question, 75% plan to use tools more; 2% report they will use tools less often; and 23% plan to remain at the same level at which they currently use tools.

If we believe that modeling improves the quality of software produced, these findings are good news for modeling tool vendors and for the IT industry as a whole. Even at a time when corporate budgets are tight and only necessities get funded, a clear majority of respondents expects to increase its reliance on modeling tools.

In computing, one of the most pernicious syndromes is believing that the whole world is like your own backyard. From a cursory reading of what analysts and the media have been saying lately, it would be natural to assume that everybody does OO modeling based on UML.

But it's always safest to check, so we did. It turns out that OO modeling is still by no means universally accepted. Of the 132 respondents answering the question about whether they do some kind of modeling, 74% perform data modeling; 74% do process modeling; 64% perform OO modeling; and 54% engage in business modeling (respondents were allowed to choose more than one). Clearly, most organizations engage in more than one style of modeling. Equally clearly, traditional data modeling is still more popular than OO.

Data modeling, which dates back to the 1970s, has had more time to mature than has OO modeling. The leading data modeling method, entity-relationship diagramming, is closely related to the dominant relational database model. Virtually all commercial applications, and some others, include a relational database and can thus benefit from data modeling at an early stage.

Process modeling and business modeling overlap to some extent in the shape of "business process modeling." Process modeling is mainly concerned with designing and improving business "flows" -- the handling of insurance claims or aspects of the supply chain, for example. Business modeling, meanwhile, has a broader scope, encompassing strategic planning, organizational structure, and the overall matrix within which individual IT systems fit.

Finally, OO modeling aims to combine data modeling with a description of the operations performed on data. Of the four types of modeling dealt with in this survey, it is the only one that results in designs that are equivalent (in a sense) to source code. Indeed, OO modeling evolved "backward" from OO programming languages, such as Smalltalk, C++, and Java.

It should not be surprising that organizations perform more data modeling than they do OO modeling because data modeling is well understood and its value is self-evident. On the other hand, many developers and IT managers still feel that OO modeling constitutes wasteful and unnecessary overhead. Over the coming years, this perception may gradually change as Model Driven Architecture (MDA) from the Object Management Group (OMG) gains acceptance.

There was a time when software modeling was mainly limited to engineering and "technical" applications. These had the most demanding requirements for correctness and reliability -- after all, any failure could lead to serious damage or even loss of life -- which helped to justify the substantial cost of top-end workstations and modeling tools.

Evidently, times have changed. In answer to the question "Which kind of software applications do you mostly model?" no fewer than 82% of the 129 respondents who answered this question chose business/commercial applications. Meanwhile, engineering and real-time/embedded applications account for 7% each. These results fit in with the predominance in the survey results of data and process modeling, which are not generally associated with technical development. Neither, of course, is business modeling.

Nevertheless, it is noteworthy that more than 80% of respondents engaged in automated software modeling use it for business or commercial applications. This suggests that modeling tools are becoming more closely aligned with the requirements of the large and influential commercial development sector.

Software modeling includes a wide variety of activities supported by dozens of rival methods. Most methods focus on design, while a smaller number address analysis. Moreover, the leading products can generate source code from designs (although this usually amounts to little more than "skeletons" that developers have to complete by coding manually). Of 121 respondents, 58% use modeling tools for analysis and design; 29% for analysis, design, and code generation; 4% for analysis only; and 3% for design only. A tiny 2% combine design with code generation but don't use their modeling tools for analysis.

Another way of presenting the message behind these results is to point out that 87% of modeling tool owners use them for both analysis and design; 31% also take advantage of their code generation capabilities. In assessing these numbers, remember that code generation is usually meaningless in the context of business modeling or process modeling, although SQL or some other data manipulation language can be generated from a data model.

-- Robert D. Austin, Editor, Cutter Benchmark Review, and Fellow, Cutter Business Technology Council