Agile Models

A model is an abstraction that describes one or more aspects of a problem or a potential solution addressing a problem. Traditionally, models are thought of as zero or more diagrams plus any corresponding documentation. However, nonvisual artifacts such as collections of CRC cards, a textual description of one or more business rules, or the structured English description of a business process are also models. An agile model is a model that is just barely good enough. But how do you know when a model is good enough?

Agile models are just barely good enough when they exhibit the following traits:

  • Agile models fulfill their purpose. If you don't know why you need to create something, don't create it. That wouldn't be agile.

  • Agile models are understandable. A requirements model will be written in the language of the business that your users comprehend, whereas a technical architecture model will likely use technical terms with which developers are familiar. Style issues, such as avoiding crossing lines, will also affect understandability messy diagrams are harder to read than clean ones (Ambler 2003a). The level of detail in your models and their simplicity also affect understandability.

  • Agile models are sufficiently accurate. When a street map is missing a street, or it shows that a street is open but you discover it's closed for repairs, do you throw away your map and start driving mayhem through the city? Of course not. You can tolerate some inaccuracies. It's the same with models: The nature of the project, the nature of the individual team members, and the nature of the organization all determine how accurate your models need to be. For example, Figure 8-5, modified from Agile Database Techniques (Ambler 2003b) depicts the basic logic for optimistic locking although it isn't necessarily the exact way you would actually implement it (you don't need near that many database accesses). It isn't perfect, but it gets the job done.

    Figure 8-5. A UML sequence diagram.

    graphics/08fig05.gif

  • Agile models are sufficiently consistent. In an ideal world, all your artifacts would be perfectly consistent, but the world isn't ideal nor does it need to be. There is clearly an entropy issue to consider regarding accuracy and consistency. If you have an artifact that you wish to keep as official documentation, you will need to invest the resources to update it as time passes, otherwise it will quickly become out of date and useless. There is a fine line between spending too much time and not enough time updating documents.

  • Agile models are sufficiently detailed. A road map doesn't indicate each individual house on each street because that would be too much detail. However, when a street is being built, the builder requires a detailed map showing each building, the sewers, electrical boxes, and so on. Sufficient detail depends on the audience and the purpose for which it is using a model. For many projects, a couple of diagrams drawn on a whiteboard and updated as the project progresses are sufficient to describe the architecture. For example, Figure 8-2 doesn't depict the indices needed to support this data structure, yet you likely could create a working database schema from this diagram.

  • Agile models provide positive value. A fundamental aspect of any project artifact is that it should add positive value. Does the benefit that an architecture model brings to your project outweigh the costs of developing and (optionally) maintaining it? If not, find more cost-effective ways to create it.

  • Agile models are as simple as possible. Strive to keep your models as simple as possible while still getting the job done.



Practical Guide to Enterprise Architecture, A
A Practical Guide to Enterprise Architecture
ISBN: 0131412752
EAN: 2147483647
Year: 2005
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net