Recently, I’ve been posting answers about architecture questions I’ve seen pop up in a few places. I’ll collect them here so that you can find them.
Agilists disagree about planning and architecture. XP tends to advocate no (or little) architecture up-front (i.e., planned design), but people like Martin Fowler say they do planned design maybe 20% of the time. Chapter 14 of XP Explained (Kent Beck) has a nice articulation of the XP design philosophy.
Michael Keeling has a good explanation about why agilists (and others) disagree. He says to pay attention to two dimensions: your knowledge about solutions and your knowledge about problems. When you know lots about solutions in this field (e.g., web systems), then you are more likely to defer planning. But when nobody has ever built a Mars Rover before, you do more planning. To me, this explains why engineers in different situations do different things, yet what each does is rational.
Chapter 3 of my book on software architecture is devoted to answering the question “How much architecture should you do?” In brief, the answer is “Do architecture until risks fall off your radar”. If you’re not worried about scalability or security, don’t bother planning those. But if you’re worried about auditability (e.g., regulatory compliance) then work on it until you think you’ve got it handled, or can handle it using evolutionary design. That chapter is available for free download.
If you’re being agile, you should avoid shoving lots of up-front design into an Iteration Zero. Put another way, if your Iteration Zero is three months of design, you are not really very agile.
Your question is specifically about architecture models – just one of the things that you would do in planned design. Models are a means to an end (the end being a running system). Used well, they can help you reduce risks, but nobody will be happy at the end of the project if you have a great model and no system.
Your question is a hard one because it touches on many areas: process, leadership, and software design (or architecture). I’m going to assume you have a standard process already, but if you don’t then try one of the Agile processes. I’ll talk about leadership and software architecture.
Leadership. Fred Brooks’ great book, The Mythical Man-Month, talks about having a technical leader the way a surgical team has a leader. Personally, I like more collaboration than I see with doctors, so let’s treat Brooks’s surgical team as an extreme. Still, you need someone to technically coordinate who is doing what, things like allocating people to work in different parts of the system, deciding what the hardest (riskiest) parts are (so that they don’t get deferred until they’re expensive to change/fix), and make choices when the team disagrees. This kind of technical leadership is needed whether you are building software, cars, or pogo sticks.
Architecture/Design. The standard mantra is that “Every system has an architecture” but the corollary is that not every architecture is deliberately chosen. You may implicitly copy the architecture from your last project, say a 3-tier system. Or it may be pre-decided once you know you’re using a framework like EJB. At the beginning of a project, you’ll be making architectural decisions and some will be hard to change later. How will you persist data? Will you use a framework (eg Spring, EJB, RoR)? Will you process data incrementally or in batch?
Pretty much any architecture can be forced to meet your requirements. For example, you could use RoR to build an thermostat. But you’ll have an easier time when your architecture is a good fit for the requirements. Sometimes you’ll have requirements, such as low user interface latency, that can be helped out by a wise architecture choice, like using AJAX. So the beginning of your project is an opportunity to think about these things and get them right. (And this doesn’t mean you go up to the mountain, think hard, then dictate your answers to the team – here again I favor collaboration).
Don’t be afraid to think about architecture up front, especially about ways it can help you avoid difficulties, but also don’t try to decide everything in advance. You’ll have trouble if one part of your team started using Ruby on Rails while another part started using EJB – so make some technical decisions, the ones that are forced on you and the ones that will address your biggest risks.
One last thing: Early architecture discussions are a blessing and a curse. They are a blessing in that they get ideas out early and allow you to choose your design rather than blunder into it. But they are a curse in that everyone will have opinions, and it can be difficult to get them all pointed in the same direction (ie back to the need for technical leadership).
I recommend Chapter 12 of Applied Software Architecture for guidance on your question. The list of headings gives a good idea of its advice: Creating a vision, the architect as key technical consultant, the architect makes decisions, the architect coaches, the architect coordinates, the architect implements, the architect advocates. The 97 Things book you mention is more of a collection of pearls of wisdom rather than a cohesive guide to architecture.
Full discussion on Microsoft forum
I agree with the other responses to some extent – reading a book on C# syntax will not make you a good programmer, nor will reading a book on software architecture make you good at architecture. On the other hand, there were plenty of clever Roman engineers but any engineering student today can build things better than those Roman engineers. The difference is the knowledge we can apply.
So where do you get knowledge about software architecture? One place is your experience building systems. Another is conversations with other developers or reading their code. Yet another place is books. I am the author of a book on software architecture (Just Enough Software Architecture) but let me instead point you to some classics:
That’s just a short list and just because I didn’t list something doesn’t mean it’s a bad book. If you are looking something free to read immediately, I have three chapters of my book available for download on my website.
Rhino Research is devoted to improving the state of software practice. We do this by using our industrial and academic roots to give you the freshest and most practical advice in classes and during consulting engagements.
We have taught classes for many kinds of clients, ranging from regular information technology shops, to huge internet shops, to NASA.
subscribe via RSS
