OR… question = (2_architect | !2_architect);

I just posted to a thread on linked in about whether or not you should blow out a full architecture on a project to let the design evolve over time. I’m reposting and expanding may response here because I think there are some important elements to the topic worth consideration.

This is a topic that I’ve seen pop up again and again since I’ve started doing Agile.

The basic premise is that if you’re using sound design principals/patterns, and have a solid understanding of what the customer wants, (Remember you’ve gone through release planning with the customer, and have hopefully developed a solid product backlog) then you can allow the architecture to evolve iteration after iteration. Using techniques, such as refactoring and strangulation, you can keep the code base moving forward without ripping things out and starting over.

At this point let me point you to an article that Martin Fowler wrote back in 2003 called, “Who Needs an Architect?” (I told you this debate has been going on for a while.) In the article he describes the role of the architect within an agile project, and even has a section towards the end called, “Getting rid of software architecture.” Whether you agree with him or not, it is an interesting read, and one of the best arguments I’ve ever heard for not doing a lot of architecture up front.

Personally I always try to do as little as I can get way with up front, in order to allow for future scenarios I can’t see today. I always have an over-arching architecture in my head, but I don’t want to make it real until I need to. That way if new requirements pop up later, the project has not backed itself into a corner that might cause major overhaul. “What do you mean we’re going to deploy all the services as workers in the cloud? We just spent two weeks setting up an application server farm!” is something I hope never to hear because wrote something down on paper too soon.

When I look at the times where I “Over-Architected” a solution, it was usually because I had to have the full architecture documented before the team could write code. As a consultant I don’t always get to do things my way, and this includes the use of Agile. In these situations it can be easy to overthink things, as there tends to be pressure to “Get it right up front,” and “Account for all eventualities.” In my humble opinion this is one of the top reasons projects fail. In cases where requirements are simple, or very well defined, it’s ok, but oftentimes customers don’t really know what they want up front. A good indicator of this is when you start getting conflicting requirements.

If you’ll allow me the metaphor, I like to think of the software architecture as a collaborative art installation, and the role of the architect as one more of chief artist. As chief artist I select the medium we’ll work in, wood, canvas, marble, etc. If we’re working on canvas I will usually step in and take the requirements of the customer and begin to paint in the larger areas. I may lay down a patch of azure across the top of the canvas for the sky, and then work with the other artists to begin painting clouds, birds, balloons, or whatever else is needed. As we reach stories that involve a landscape or ocean, I may decide the placement, size and/or shape. Again blocking the pieces in, then working with the team to fill in the detail.

Now there is a place where this metaphor begins to break down for me, and that is in regards to the customer. In our metaphor the customer is exactly that, a customer, and our installation piece begins to be a commissioned piece of art. The reason that this bothers me is that commissioned works of art tend to be seen as somehow lacking in quality in comparison to art created for the sake of the artist’s own vision. At it’s worst I think this type of commissioned art can be equated to purchasing a painting to hang in your living room that matches your couch and curtains. In our tech metaphor this might be buying off the shelf software, or utilizing inexpensive labor. You tell them to draw a line, they’ll draw a line, and it will be mostly straight. While there is certainly a place for this type of art it leaves me wanting more. So lets see if we can’t fix our metaphor to make it more appealing.

So what if our customer is more than our customer? So what if instead of our band of artists creating just any type of art, we are instead are focused on creating sequential art? We can still keep our artistic mediums open. For example instead of sequential images that tell a story we might install a series of life-sized dioramas along a park trail that reveal the story. By making this simple change we can now put our customer in the role of writer. Our customer has now magically been transformed from patron and bill payer to an integral and active member of the artistic team. Now we’ve got a metaphor we can really work with, and in true agile fashion we’ve gotten there through iteration and a desire to keep our customer integrated with the team.

Next time I’ll explore the metaphor further and see if we can’t iterate against it even further.

Until then, keep thinking malignant thoughts.