In This Issue:
- How Much Architectural Modeling Do You Really Need to Do?
- Book Review: Dark Age Ahead
- Hot Links
How Much Architectural Modeling Do You Really Need to Do?
I believe that the IT industry has had some rather unfortunate theories forced upon it over the last several decades. One of those theories is that we should do a significant amount of architectural modeling early in the lifecycle of an IT project so as to think through all of the critical technical issues before we begin programming. This strategy is often justified by a civil engineering analogy, bridge building seems to be a popular choice even though the person making the analogy rarely has experience building bridges. Then again, often they don't have a lot of experience with successful software projects either. This isn't to say that initial architectural modeling isn't a good idea, in fact I think it's a very good idea. The problem is that traditional architectural modeling strategies prove to be excessive, and like most things done to excess it usually proves to be a bad idea. This month I explore the question of how much architectural modeling should you do on a software development project. I suspect that the answer may surprise you.
Agile Model Driven Development (AMDD) explicitly includes initial requirements and architectural modeling efforts during iteration 0 of an agile project (what some processes might call the "Inception" or "Initiation" phase). The goal of the initial architecture modeling effort is to try to identify an architectural vision that has a good chance of working. I'm going to let you in on a little secret: You need to do a lot less modeling than most traditionalists claim, but you need to do a bit more than what some extremists claim. The important thing is to remain realistic about how much modeling you actually need to do and to do just enough for your situation and no more.
Let's consider several common situations that a project team might find itself in, and then reflect upon how much architectural modeling would be appropriate in that situation. First, let's consider the simplest situation you can find yourself in -- the team is working with known technologies that it has worked with before. At most, I suspect that you need to create a single whiteboard sketch to ensure that everyone is working to the same vision, and frankly you likely don't even need that. For example, if this is the 10th web-based application that your team has built using Websphere and Oracle, how much architectural modeling do you really need to do?
Let's assume that you're at the other end of the spectrum and you're working with technologies that you have little or no experience with. The traditionalists will tell you that to reduce your risk that you should model everything in detail. Wrong, wrong, wrong! If you step back and think about it for a minute, this actually increases your risk. Does it really make sense to do a lot of detailed modeling when you don't really know what you're doing? No, all that could possibly achieve is that you waste a lot of time, write a lot of documentation which will likely be ignored by the developers because they'll know pretty quickly that you don't know what you're talking about, it give you false confidence that you know what you're doing, and it will likely give management a false sense of confidence that the team has a solid architecture plan in place. What you really want to do is do a little bit of modeling to help you identify what you don't know and, if possible, you want to invite people on to your team who do have the experience that you're missing. Then you need to gain some hands-on experience with the actual technologies themselves via architectural prototyping/spiking, and then based on that experience evolve your architectural models so that they reflect what actually works. In other words, let your architecture emerge throughout the project.
It's interesting to talk about extreme situations but in practice you typically find yourself somewhere in the middle. For example, perhaps you have experience with some but not all of the technologies. Or perhaps your team is experienced with the technologies but simply hasn't used them all together at once. In middle ground situations such as this it makes sense to do a lot more modeling initially (perhaps even several days) so as to identify potential risks and likely strategies to mitigate them. Modeling makes sense in this situation because it enables you to define a shared technical vision within the team and to potentially think through major issues. In other words, some initial architectural modeling will offer value to your team.
What if your team is dispersed amongst several sites, or if it's large and you have several subteams? My experience is that you will gain some value from initial architectural modeling because it will help you to organize your efforts. It helps you to grow a common vision between the subteams but more importantly you can identify separate components/subsystems, and the initial interfaces to those components, which can then be assigned to the subteams. These interfaces will evolve over time, so you'll need to collaborate with one another throughout the project, but once again some initial architecture modeling will provide significant benefit.
Some people will tell you that you don't need to do any initial architecture modeling at all. However, my experience is that doing some initial architectural modeling in an agile manner offers several benefits. First, you can think through some of the critical technical issues facing your project and potentially avoid going down fruitless technical paths. Second, your team gains the advantage of having a guiding vision without the disadvantage of having to overbuild your system -- just because you've modeled it doesn't mean you have to build it. Third, it enables you to make better cost and time estimates for your project, two pieces of information which management will want. Fourth, it helps you to communicate what you think you're going to build and how you think that you'll build it, two more critical pieces of information desired by management.
You should strive to do just enough modeling for the situation at hand and no more. The implication is that there is no one correct answer for how much modeling each project team will do, that instead it will vary from team to team. My philosophy is that repeatable results -- in this case having a shared architectural vision within the team -- are far more important than following a repeatable process that ensures that each team does the same amount of modeling each time.
