|
When is enough modeling enough?
November 26, 2006
URL:http://www.drdobbs.com/architecture-and-design/dr-dobbs-agile-newsletter/196500031
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.
Best known for the books The Death and Life of Great American Citiesand Systems of Survival, Jane Jacob's once again hits it out of the ballpark with Dark Age Ahead. She warns us of common patterns which societies experience, patterns which lead to cultural dead ends. She describes "five pillars" that our society depends on: Community and family, higher education, the effective practice of science and science-based technology, effective taxation, and self-policing by the learned professions. Although the book title is ominous, I prefer to take it as a warning sign that we may be in trouble and we need to do something about it while we still can.
So why should you care? First, like all of Jacob's other books, this book is a really provocative read which will get you really thinking about the society in which we live. Second, for IT professionals the chapters on education and certification, as well as on self-policing of the professions, provides significant insight into how we need to evolve our profession. Are we really providing computer science graduates with an education, or are we merely certifying that graduates are worthy of a job interview? Do our existing certification programs provide any real value, or are they simply a money grab on the part of the certifiers? Should we set up a body which polices IT professionals? Would we be able to do so in a manner which provides any value at all? These are all interesting questions, and although this book may not directly provide the answers it will provide interesting insight.
Dark Age Ahead
Jane Jacobs
Vintage, 2005
http://www.amazon.com/exec/obidos/ASIN/1400076706/ambysoftinc/
--SWA
The Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development.
In Agile Architectural Modeling, I describe a collection of agile strategies for architectural modeling
Agile Enterprise Architecture describes techniques which enterprise architects can follow to support agile development teams effectively.
New To Architecture provides a collection of links to articles describing architecture modeling strategies.
Agile Models Distilled provides links to overviews of a wide variety of models at
The principles of Agile Modeling v2 are described here.
The practices of Agile Modeling v2 are described here.
Check out the Agile Modeling mailing list.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.