11 Aug 2008

An Agile Architect

Agile software development approaches promote lightweight feedback focused evolutionary design techniques such as test driven development. Within that context where does the role that has become known as “Architect” fit?

Design can be considered as a set of decisions about how something should work. Architecture is meta-design, setting constraints to limit design decisions and create a design style/language. Many organisations have Architects create these constraints based on their “big picture” vision of the system(s).

I classify these constraints as either “enterprise constraints” which allow the system to integrate with the rest of the organisation, or "Good Practice constraints" which aim to optimise development activity.

“Enterprise” Design Constraints

Enterprise constraints are really non-business features related to legal regulations, service level agreements, or existing integration issues. When contributing these constraints the Architect is acting in a Customer role. As such these constraints should be contributed as user stories.

When enterprise constraints are contributed as user stories, the obvious feedback mechanism is automated Customer Tests. As with regular customer tests these tests should be periodically reviewed to ensure they are still relevant.

“Good Practice” Design Constraints

On large projects, many constraints are good practice constraints aiming to optimise implementation. Good practice constraints can be dangerous, often based on a combination of wisdom, theory, aesthetics, hearsay, guesswork, and simple proof of concepts. Almost every set of good practice constraints I have seen has initially been naively inappropriate for its intended situation.

That is not to say there is no value in good practice constraints. If the architects join developers to cut code and fully implement architecturally significant user stories, harvesting constraints as they go, they arrive at a small set of proven constraints that are fully illustrated with good code examples. Since we have these concrete examples these constraints then only need lightly documented.

Regardless of how they are brought into being, at some point there will be a set of design constraints representing "the architecture". Some constraints will likely date as the system changes through time. When constraints appear to push a sub-optimal design, their appropriateness should be questioned.

Architects who have daily interactions with the development team can review constraints better than those who simply think up constraints with and hand them over. Architects who are regular developers and live with their architecture will get the richest insights into its suitability. Less interaction will (unless extremely lucky) result in less appropriate architectures adversely affecting delivery dates, budgets, ongoing maintenance and support costs.

Instead of attempting to lead, architects should take their lead from the development team. If architects do not have ongoing interaction with both developers and the system they are building, they cannot appreciate nor help with the real issues faced by those developers.