A mailing list pointed me to a recent post by Jeremy Miller on Agile design and an older one by Joe Ocampo. Both discuss how design happens in an Agile project. Both are great posts. Jeremy’s post sticks largely to what is considered the Agile “party line”: design is done all the time rather than up front. Joe’s post talks about using Domain-Driven Design to develop the “ubiquitous language” that teams need for communication. Jeremy admits in the comments that a bit of up-front establishment of a domain is useful as context, but distinguishes it from design. Presumably he is equating it with analysis. Having written a book that, in part, shows how use of consistent domain modeling patterns can inform design and implementation, I would say it’s both. But that’s not what I want to talk about….
Reading these posts and exploring a bit further, I began to relate the establishing of a domain context for stories with establishing an architectural context.
One of the main challenges I have faced and hear others describe is how to maintain agility when there is a scope of multiple Agile projects (what the PMBOK would call a program) or an enterprise portfolio that really needs consistent architecture. I am generally a believer in simple, evolutionary design. However, as Jeremy points out in his post, it requires people with the proper skills to maintain an open design/architecture and who know how to tell when they have reached the last responsible moment. What I have discovered is that as the scope of systems under development scale, the last responsible moment for certain architectural decisions tends to shift earlier.
As such, a reasonable step would be to include a (short) architectural analysis session for each release that would mirror the domain modeling exercises Joe mentions late in his post. In that way, those with architectural knowledge could get involved and discuss what architectures support the features required and which decisions need to be agreed up front. Provided this is timeboxed and the group puts appropriate emphasis on postponing that which can be, this is in line with Agile values as well.
I should also note that I would only add this practice if the team found it necessary. As a coach, I might recommend it upon seeing the following things either in a retrospective or during planning or other working sessions:
- multiple components, libraries, and/or frameworks in use that accomplish the same goals
- “not invented here” syndrome
- lack of integration testing between project teams’ output
- failure of or difficulty with coordinated deployment (usually preceded by the lack of integration testing)
- no or limited consideration of nonfunctional requirements (performance, stability, etc.)
- failure to meet nonfunctional requirements
I’m sure there are other smells that would indicate a need for architectural planning. If you think of others, let me know in the comments.
Tags:
agile, design, domain modeling, streamlined object modeling
6 comments ↓
You are the second person I’ve encountered in as many days who’s suggested in writing that Architecture is a good way to address non-functional requirements.
I’ve been burned by “architects” as have others, as suggested by your own words. A co-worker of mine has said that he had a really positive experience working for a large private contractor and another good experience working for a large government owned corporation.
I think the case for using an architect may greatly depend on the architect.
When I was at Agile Austin Open Space, Scott Belware introduced me to the term “design hernia”. Think of a herniatied disk in the spine. This disk is inflammed and applies pressure to the spinal cord causing in many cases severe pain. If the hernia is resolved in the body, eventually the surrounding tissue will cease to be affected. That is, the body is self correcting. Programming code is not self-correcting. Effects of a design hernia can continue to be felt even after the hernia is removed.
I’ve been in a few environments now where the “architect” (whether this person refered to themselves as such or not) actually introduced some serious design hernias and was either unable to remove them because of bureaucratic inertia or was too stubborn to concede that the “architecture” was flawed.
In building construction, design is the process and architecture is the result.
To me, too many architects come up with their architecture without thinking about its consequences. Why do these people try to set in stone what basically should just be design before their ideas are validated through user acceptance testing?
Bad architecture can unnecessarily increase the time to live, increase the overall complexity of the system and increase the maintenance burden.
These things make me question, “Is architecture really worth it?”
Robert
p.s. That other article that suggested non-functional requirements were best handled by architecture was in “Better Software” magazine.
Believe it or not, I wrote this before you posted and not as a reaction to your article: http://geekswithblogs.net/rstackhouse/archive/2008/07/09/123691.aspx
Architects do indeed have a bad reputation with a lot of software development folks. In part this is because of the way the title “architect” was bandied about in the 90s. People who knew nothing about it were given the title. In part it is because “Enterprise Architecture Group” was generally put into practice in the same way as “Project Management Office”: both essentially ended up as gatekeepers rather than as helpers. And I am sure there are a ton of other reasons to go with these two.
Therefore, I suggest that architecture choices (.NET vs. Ruby , Rails vs. MERB, one rubygem vs. another, etc.) should be made by team members rather than by “the Architect”. Note that I say “those with architectural knowledge” in the post. I should probably change that to “team members with architectural knowledge”; it was that way in a draft.
The one point I disagree with in your longer comment is implying that the possibility of bad architecture is a reason to never plan architecture. While bad architecture is painful, lack of *any* architecural planning *can be* even more painful. To detect whether that is the case, I suggested the list of smells.
Also, as I mention at the end, I do not recommend this for all projects. It is generally applicable when there are multiple projects that must integrate. Integrate either in their deployment or in the need for team members to move between projects.
Before anyone hoists me for saying that someone can move between projects… Note: I don’t mean work on multiple projects at a time. That is generally a bad idea. However, if an organization has two products, one may have a lull when the other is trying to deliver more features for a release. In that case,moving staff from one to the other *can be* a good idea. Also in that case, having some consistency in the libraries/frameworks/components used can reduce the impact of ramp up and communication overhead that we’ve known about since even before Fred Brooks’ Mythical Man-Month.
Just to follow-up on the blog post which I have now fully read, I agree completely. The best way to inform your design (or architectural choices) is to talk with a user about how they will use the particular feature. In the same way leaving HCI out is criminal, not having at least a development team member in the room for most of the usability discussions should be too.
I find it funny that both of us reference Fred Brooks.
This is an interesting thread as it points out the difficulty many people have in separating Analysis from Design and what the word ‘architecture’ really means.
The challenge much of this is pointing out is that software development, and technology in general, has advanced to the point that projects need a wide variety of different ‘architects’ and they all need to be capable of analysis and design. These days large organizations have such complex environments that you need input from any number of architects (security, network, enterprise, usability… take your pick). However, understanding the true goals of the system and ensuring these are well understood is what will make your implementation successful.
On a slight aside, over the course of my career I’ve become increasingly suspect of asking for ‘users’ to define the requirements of a new system or enhancement. Most users, unfortunately, often have very myopic views of how they use a system and the overarching business processes their activities support. That ‘big wallet’ guy that Robert referenced often has a better vision of what the system really needs to do because you usually don’t get the big wallet without being connected to the real strategies/direction of the company.
@Bryan: Difficulties with terminology are a large part of the problem Agile tries to solve by using frequent, face-to-face communication and a predilection toward linking requirements very strongly to testing (e.g. BDD). Natural languages are just so full of overloaded terms with connotations that can vary from person to person based on experiences. “Architecture” and “architect” are a great example of this.
With regard to where requirements should originate and how to evaluate them… that should be done in large part with the users. However, the relative priority of those requirements must be set by someone with the big picture view and the overall authority to make decisions. This often - not always - goes along with the big wallet. This is where Scrum came up with the concept of the Product Owner which is a little more specific than (my understanding of) XP’s Customer.
Leave a Comment