How Deeply Should I Model My Applications?

Often, people who are ready to model their applications ask when they should move from modeling activities into implementation, or how much detail their models should contain. In certain situations, putting as much detail as possible into your models is in your best interest—for instance, when you are modeling something that is critical and/or high-risk, such as an implanted medical device (in which case lives are at stake), or when there will be huge financial implications if your system fails. Such dire consequences justify that you model your applications as deeply as possible.

Situations in which performance or reliability are critical are also good candidates, as are situations in which you are outsourcing development. What do these situations have in common? These are cases in which you want to limit design tradeoffs by fully defining (i.e., modeling) your application. You do not want to leave key design decisions that could impact your critical factors, such as performance or security, to a junior programmer. For example, that junior programmer might choose to implement the code in a manner that reduces memory consumption. Although this seems harmless, memory utilization might not be an issue for you—you might need a system that has superlative performance. You don't want to defer such critical design tradeoffs to implementation. You should fully model such critical systems in detail so that you get what you really need.

In non-critical situations, the amount of detail you put into your models is often governed by your project schedule, budget, and the skill of your staff. Although including more detail is generally better, often you will have to pragmatically balance all these factors. One indicator you might watch is rate of change. If the details in your model are in a constant state of flux, such as if the operations specified are changing frequently, it might be too soon to hand off your models to development for implementation because the design is obviously immature. You should wait until some reasonable level of stability sets in (because change never stops) before you proceed. The definition of “reasonable” is different for each organization, of course. However, when your rate of change levels off at some low, stable level, you probably are ready to begin to implement your design models.