Udi has a great post, Money?! Schedule?! But I

Joshua asked me to clarify what I meant by implementing by architecture. Here’s my picture-story.

When a team implements by architecture, they tend to be functionally-based teams implementing across the architecture. See .

When a team implements by feature, they are cross-functional teams. See .

When teams implement by feature, they do what’s needed in whatever part of the architecture is needed. To the outsider, it looks a little messy–sometimes incomplete. But to the team, the architecture is cohesive. And, most importantly, the team is not writing code they won’t use.

When teams implement by architecture, they are too likely to implement more than they need–ever.

Given the thoughtful comments on Architects Must Write Code and Testing Design, I’m wondering if some of the difference in our beliefs stem from our perceptions of the architect’s role.

I see the architect as the technical lead who shepherds a product through the overall design, someone who explains enough about the system and how it hangs together so that the other developers can take their parts write/design them (in whatever way works for them). I now believe in as-little-as-possible design-up-front and as-much-as-possible emergent design. Because I see the architect role as a shepherding role, I see the architect as immersed in the project, and integral part of the project team who needs to continue to participate to see when things go south.

But I wonder if some of you are thinking about the architect as more of a consultant. The more up-front design and architecture you do, the more you can try to create the architect-as-consultant role. Certainly, architects for buildings do become “merely” consultants once the general contractor starts the actual construction. (Yes, this is one more reason the building construction metaphor doesn’t work for me.) If the role of the architect on your project is more of a consultant, then I can understand why you disagree.

I’m going to have to think about ways to make the architect-as-consultant model successful, even if I don’t believe in it. (For me, this all points to feedback for the architect.) Certainly, many of my clients believe in and use that model. Just because I can point out ways that it doesn’t work doesn’t mean these folks can or are willing to change. So, I’ll be thinking about ways to make it work–and the risks involved. (This will make the organize-your-project-team chapter easier to write too. Duh.) I may well ask you for your comments.

In Architects Must Write Code, several architects responded that I was too prescriptive (I’m summarizing their comments). Maybe. But I don’t think so.

I’m in a nice hotel, where things just don’t work completely right. Yes, the hotel is clean (that’s the big thing with me). The hotel upgraded me to a suite with an oval bathtub. Clearly, people of normal height and weight had not tried to shower here–the tub is about 9 inches (a hand-width) from the toilet. There’s no grab bar to balance on one foot while stepping into or out of the tub/shower. I tried to draw you a picture here.

I travel a lot and stay in lots of hotels. This problem is similar to many problems I encounter in hotels: outlets too far away from where I want to use them, chairs too high, sinks too high, and my favorite, too-high shower heads. Most of the time, the shower head is too far away for me to adjust. I’m short (5 feet tall), but if I can’t reach the shower head, it’s set for a 6-foot plus person. If the people who designed the hotel rooms had tried them at all, they would realize they were creating difficult situations for a significant percentage of the users.

So, it’s possible that architects don’t need to code and participate in a project. But I don’t know of other effective techniques to test the design. Testing design with a thought experiment is insufficient. Testing design by using it provides much more feedback.

However you arrange your project, think about how to test the design–the design in-the-large, and all the little pieces of design-in-the-small. Certainly, test-driven development is great for testing design-in-the-small. And if you have a whole project that’s willing to try test-driven design for overall architecture, that’s fabulous. But if you don’t or you can’t see how, at least think about how to build in testing of the design, especially design-in-the-large as you proceed through the project. Then you won’t end up with a bathtub practically in the toilet, requiring people to balance while stepping in and out of the shower.

I had the opportunity to read Practices of an Agile Developer: Working in the Real World. The book has 45 tip to help developers become agile. And, it’s clear that Venkat and Andy know the problems of becoming an agile developer, because along with each tip, there’s a devil-thought to show people what happens in the real world. There are also angel-thoughts to show people why this tip works.

My favorite tip, and something I’ve been saying in my assessment reports for the last 10 years is “Architects Must Write Code.” (p. 155 in this book.) Venkat and Andy say this about ineffective architects:

They typically come in during the beginning of a project, draw all kinds of diagrams, and leave before any serious implementation takes place. There are many “Powerpoint architects” out there, and they aren’t effective because of lack of feedback.

I’ve been a part of projects for 30 years. I’ve been assessing projects for 10 years. And every time I’ve seen an architect who doesn’t participate in the code-writing part of the project, I’ve seen an architecture that doesn’t do what it’s supposed to do, never mind extend to inevitable changes in requirements that occur during the project.

Architects need feedback about their architecture. The only way to get feedback is to write the code, integrate it, and see what happens.

If you haven’t read Joel Spolsky’s entry on office architecture stop and read that first. Finally, an office in which people can successfully work alone andwith other people — and who don’t have to worry about keeping their voices down. I’m amazed at the space per person (425 sq. ft if I understood). Most offices give people 80-100 sq. ft. My home office is 22×14, 308 sq. ft. I have room to spread out my various current projects, room to meet with one or two people, room for a flip chart and of course all the machinery I need. The offices must feel palatial to the people at Fog Creek.

What Joel describes is requirements starting with the users. Notice that he doesn’t separate functional requirements from non-functional requirements. What people call non-functional requirements are the attributes of the system that make it usable — or not. When you start with the users, and describe requirements holistically as Joel did, (well, ok, he has some design, such as “offices with doors”), you describe what makes the system (in this case, the offices) usable.

Esther and I are teaching consulting skills to architects this week. We have a variety of simulations as part of the workshop, and we’ve noticed that great architects act in certain ways:

• Great architects look for multiple alternatives to explore.
• Great architects look for how the user claims to want to use the system, and continue to probe on currently-visible extensions for how people may want to use the system in the future.
• Great architects discover the primary system attributes that will drive the system and build on that. One architect described this as building from the inside out.

The primary system attribute, what other people call a non-functional requirement, is often unclear. For our simulations, the attribute was the ability to support a physical load. For software systems, it can be some aspect of performance, reliability, security — or some combination. Here’s an example. Our telephone systems in the USA are build around a primary system attribute: the system will have uptime of greater than 99.999% over the course of a year. (The telco requirements are probably higher than that, but it’s a lot of 9s after the decimal.) That means that you can virtually always pick up a land-line phone and get a dial tone. That requirement drove the architecture of the telephone systems, both for each central office and all the interconnections.

If you find that primary attribute, or the combination of attributes, the system architecture alternatives appear — to me it looks as if they become clear to architects by magic.

The lesson I’m taking away this week is that if you want a coherent architecture, it’s more important to discover the primary system attributes rather than all the functional requirements. No matter how you approach requirements, make sure you take a holistic approach. Don’t use techniques that separate functional and non-functional requirements. If you do, you won’t see the architecture emerge.