In Agile Modeling (AM), you want to travel as light as possible, so you need to choose the best artifact to record information. (I use the term "artifact" to refer to any model, document, source code, plan or other item created during a software development project.) Furthermore, you want to record information as few times as possible; ideally only once. For example, if you describe a business rule in a use case, then describe it in detail in a business rule specification, then implement it in code, you have three versions of the same business rule to maintain. It would be far better to record the business rule once, ideally as human-readable but implementable code, and then reference it from any other artifact as appropriate.
Why do you want to record a concept once? First, the more representations that you maintain, the greater the maintenance burden, because you'll want to keep each version in sync. Second, you'll have greater traceability needs with multiple copies because you'll have to relate each version to its alternate representations to keep them synchronized when a change does occur. AM does advise you to update only when it hurts, but having multiple copies of something means you're likely to feel the pain earlier and more often. Finally, the more copies you have, the greater the chance you'll end up with inconsistent information, as you probably won't be able to keep the versions synchronized.
It's interesting that traditional processes typically promote multiple recordings of technical information, such as representing business rules three different ways, while also prescribing design concepts such as normalization and cohesion that promote developing designs that implement concepts once. For example, the rules of data normalization motivate you to store data in one place and one place only. Similarly, in object-oriented and component-based design, you want to build cohesive items (components, classes, methods and so on) that fulfill only one goal. If this is O.K. for your system design, shouldn't it also be O.K. for your software development artifacts? We clearly need to rethink our approach.
It's clear that you should store system information in one place and one place only, ideally in the most effective place. In software development, this concept is called "artifact normalization"; in the technical documentation world, it's called "single sourcing". With single sourcing, you aim to record technical information only once and then generate various documentation views as needed from that information. A business rule, for example, would be recorded using some sort of business-rule definition language. A human-readable view would be generated for your requirements documentation (easier said than done, but for the sake of argument, let's assume it's possible) and an implementation view generated that would be run by your business rule engine or compiled as application source code.
To make the single-sourcing vision work, you need a common way to record information. Darwin Information Typing Architecture (DITA) is an XML-based format that's promoted for single-sourced technical documentation. Nothing can stop you from creating your own storage strategy: Single sourcing is often approached in a top-down manner with the data structure for the documentation typically defined early in a project. However, you can take a more agile approach in which the structure emerges over time.
The primary challenge with traditional single sourcing? It requires a fairly sophisticated approach to technical documentation. This is perfectly fine, but unfortunately, many organizations aren't yet able to achieve this vision and eventually back away from the approach. This doesn't mean that you need to throw out the baby with the bath water; you should still strive to normalize all of your software development artifacts.
Just as it's extremely rare to find a perfectly normalized relational database, I suspect that you'll never truly be able to fully normalize all of your software artifacts. In the case of databases, performance considerations (and to be fair, design mistakes made by project teams) result in less-than-normal schemas. Similarly, everyone won't be able to work with all types of artifacts -- it isn't realistic to expect business stakeholders to be able to read program source code and the ¼ber-tools required to support this vision continue to elude us. However, we can still choose to travel as light as possible, and next month, I'll describe techniques for doing exactly that.
-- Scott W. Ambler
>>RECENTLY ON THE AM MAILING LIST
What Does It Mean to Be Agile?
To get some input for my January 2005 print column ("The Agility
Quotient"), I asked this question to the list members. We debated a wide
range of concepts, such as being feedback- and change-friendly, willing to
work in a collaborative manner, willing to focus on delivering working
software that meets the needs of its stakeholders, willingness to work with
stakeholders, and flexibility in your approach. Keep an eye out for my column,
which describes these ideas in detail and suggests a tongue-in-cheek rating
system.
Cost of Change Curve
We discussed the merits of the agile cost of change curve, which in practice
proves to be much flatter than the traditional cost of change curve due mostly
to the increase feedback prevalent in agile approaches. New metrics showing
this to be true, and new techniques to support a flatter cost of change curve,
are actively being worked on within the agile community.
Crystal Clear
I announced that Alistair Cockburn's latest book, Crystal Clear: A
Human-Powered Methodology for Small Teams, was released by
Addison-Wesley in late October. I've been waiting for this book for a long
time and am delighted to finally see it in print. Crystal is summarized by
seven properties: frequent delivery, reflective improvement, osmotic
communication, personal safety, focus, easy access to expert users, and
a technical environment with automated tests, configuration management
and frequent integration.
>>HOT LINKS
JoAnn Hackos and Ann Rockley's article "Single Sourcing White Paper"
overviews the fundamentals of single sourcing.
http://www.infomanagementcenter.com/pdfs/white_paper_001.pdf
Pamela Kostur and Anne Rockley's paper "Information Modeling for
Single Sourcing" describes a top-down process for single sourcing.
http://www.stc.org/confproceed/2001/PDFs/STC48-000158.PDF
The Darwin Information Typing Architecture (DITA) describes a potential
approach for storing normalized documentation in XML format.
http://www-106.ibm.com/developerworks/xml/library/x-dita1/
The essay "Data Modeling 101" covers, among other things, how to
normalize a database design.
http://www.agiledata.org/essays/dataModeling101.html
Eliminating the Cost of Change essay explores the agile cost of change
curve and explains why it works.
http://www.agilemodeling.com/essays/costOfChange.htm
Links to critical MDA resources on the Web can be found at
http://www.agilemodeling.com/essays/mda.htm
The concept of generalizing specialists is described in detail at
http://www.agilemodeling.com/essays/generalizingSpecialists.htm
Alistair Cockburn's latest book, Crystal Clear: A Human-Powered
Methodology for Small Teams (Addison-Wesley, 2004), is worth a read.
http://www.amazon.com/exec/obidos/ASIN/0201699478/ambysoftinc/
The Agile Alliance homepage is the best starting point for anyone
interested in learning more about agile software development.
http://www.agilealliance.org
The principles of Agile Modeling are described at
http://www.agilemodeling.com/principles.htm
The practices of Agile Modeling are described at
http://www.agilemodeling.com/practices.htm
Check out the Agile Modeling mailing list at
http://www.agilemodeling.com/feedback.htm
Get agile modeling training resources at
http://www.agilemodeling.com/training.htm
