Agile Documents

The supplementary AM practices of Discard Temporary Models, Update Only When It Hurts, and Formalize Contract Models support the concept of agile documentation. A document is agile when it meets the following criteria:

  • It maximizes stakeholder investment. The benefit provided by an agile document is greater than the investment in its creation and maintenance. Ideally, the investment made in that documentation was the best option available for those resources. In other words, no better approach was available to you.

  • It is "lean and mean." An agile document contains just enough information to fulfill its purpose. It is as simple as it can possibly be.

  • It describes "good things to know." Agile documents capture critical information that is not readily obvious, such as design rationale, requirements, usage procedures, and operational procedures.

  • It has a specific customer and facilitates the work efforts of that customer. You must work closely with customers, or potential customers, for your documentation if you want to create something that will actually meet their needs.

  • It is sufficiently accurate, consistent, and detailed. Agile documents do not need to be perfect; they just need to be good enough.

Implications for Architects

Although Chapter 7 describes an agile approach to architecture in detail, it is worth noting several implications that AM has for architects:

  • It's about people, not models and documents. An effective architect focuses on people. You must work closely with your stakeholders, including both business experts and developers, to ensure that the architecture reflects the actual needs of your organization.

  • Models do not equal documents. A model isn't necessarily a document, and a document isn't necessarily a model. A sketch or stack of index cards might be a model, but it's doubtful you'd consider them to be documentation.

  • You can't think everything through from the start, and you don't need to anyway. Requirements change. A person's understanding of the requirements change. Technologies change. Your strategy changes.

  • You must embrace multiple models. There's more to architecture than data. There's more to architecture than process. There's more to architecture than objects. There's more to architecture than hardware. There's more to architecture than [Fill In Your Favorite View Here].

  • Be prepared to take an iterative and incremental approach. Effective architects work in a way that reflects the software development followed by the project teams with which they work. Because modern software development processes, such as the RUP, FDD, and XP, take an iterative and incremental approach, so must architects. The BDUF approach to development simply isn't acceptable for the vast majority of projects.

  • Your work needs to be just barely good enough. It doesn't need to be perfect.

  • The longer you go without feedback, the greater the risk that your architecture doesn't reflect the needs of your stakeholders.

  • It's your stakeholder's money that is being spent, not yours, therefore they should determine what they choose to fund. The implication is that the decision to invest in an architecture model, and in architectural documentation, belongs to the stakeholders, not to you. You should inform stakeholders of their options and the trade-offs among the options, and then let them decide how much they intend to invest in architectural efforts. Effective architects who can actually provide value on a project team should welcome this approach; less-than-effective architects are typically threatened by it.

The Agile Modeling methodology defines an important collection of values, principles, and practices for architects to have in their intellectual tool kits. Extensive models and documents are one extreme, no models and documents are another. Your goal is to identify when your models are just barely good enough for your situation. Anything beyond just barely good enough is a wasted effort, effort that could be better spent elsewhere.



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