QCon 2009 Agile development practices may be growing in popularity among developers, but agilistas aren't getting much love from software architects.
The irony? Without the architects, agile will never be fully accepted in the enterprise.
That's according to ThoughtWorks chief technology officer Rebecca Parsons, opening this year's Qcon Conference, who believes agilistas need to help solve the problems architects face in gaining enterprise cred. Martin Fowler, ThoughtWorks' chief scientist and co-author of The Agile Manifesto speaking with Parsons agreed. ThoughWorks is an IT consultancy that specializes in agile development methodologies.
"Before we can get to why architects should run blindly behind agile and support it the way we think they should, we have to see the problems they face," he said.
During their Agilists and Architects: Allies not Adversaries presentation the two agile advocates talked about the benefits of light-weight development methodologies for enterprise software architects.
To illustrate what they see as a disconnect, they opened with a clip from geek favorite The Matrix Reloaded, in which Neo meets The Architect, a smug egomaniac in a white suit who tells Neo he's an anomaly in "what is otherwise a harmony of mathematical precision."
"Why is that funny?" Parsons asked the chuckling crowd. "Because it reinforces so many of the negative stereotypes - and in fact, negative examples - that we've all seen of architecture gone awry... There is a disconnection among architects from the problems that software developers are actually trying to deal with."
One of the basic principles of agile software development could repair this disconnection, Parsons argued. "Within agile there is this fundamental notion of the relationship between the development team and the customer," she said.
"It's a contract that says, 'As the customer, I get to say what I want and what's most important; as the developer, you get to say how much it's going to take to build it'. That's the contract the developer has with the business owner [in an agile project]. Why not include the architect? The architect is a stakeholder in a similar way."
Fowler laid out other benefits of agile methods. Agile brings transparency to the dev process that can free an architect from the need to create monolithic specifications that will never be followed through the life of most projects.
"Instead of trying to lay down a statement saying this is what should happen and trying to force that through," he said, "why not have a system that makes visible what is actually happening? When you can see what's really going on, you, as an architect, can react to it in a reasonable way."
Another benefit of agile is its ability to support code re-use. "I'm convinced that you don't get re-use by building something re-usable and expecting people to use it," he said. "You do it by building something use-able and then harvesting re-usable things from that."
"Sometimes when I give this talk people say that I'm too hard on architects," Parsons said. "But I understand that they have a very challenging job... They're put into very difficult positions, and organizations in general do them a disservice.
"The important thing to realize about this is that the problem is a systemic one," Fowler added. "It's about how the organization is set up, rather than a failure of individuals trapped within that system. No matter how good your people are, you can always mess them up with a bad process."®