I live in the state of New Hampshire. It’s a major pumpkin-growing region of the country, and October is harvest season. Truckloads of pumpkins head south and west, and local farm stands are bursting with the orange globes. But what do you do with all the misshaped or leftover pumpkins? Chuck ’em, what else? A local farmer has turned this into an art with his World Champion ‘Yankee Siege’ Trebuchet. This is something you really must see to comprehend. The top of the mast rises to more than 60 feet, and when the 12,000 pounds of weight are let loose, pumpkins fly for about 2,000 feet.
Now, it turns out that this farmer is not the only person enamored with “chunkin’ punkins.” In fact, there’s a yearly competition that takes place in Delaware every November. This year is the 24th annual competition (and will be featured on the Science Channel on Thanksgiving night), but, the Yankee Siege has been the undisputed champion in the trebuchet category for years. This year, its Web site published “10 Rules for Winning at Punkin Chunkin’,” and it occurred to me how similar many of these rules are to implementing any type of repeatable process, such as architecture. According to Steve:
1. Practice, practice, practice
2. Set up two days before the competition
3. Bring extra parts
4. Make your first throw count
5. Don’t try anything radical
6. Keep records
7. Make a checklist
8. Don’t get distracted
10. Don’t get cocky!
Let me try to paraphrase these rule with respect to implementing and introducing architecture. Remember that one of the major challenges facing architectural efforts is the process changes required to incorporate architecture into decision making, acquisition, and development. I generally recommend an agile approach to incrementally introducing architecture to any organization. You want to make sure that you’ve got the process worked out and have tried it yourself first before subjecting another team to it. And, you want to try it on one or two friendly teams, and really get it right before trying to roll it out to the total organization.
So, this is pretty much what the first few chunkin’ rules are saying.
- Practice – in other words, refine and prove the processes before trying to apply them to an important project or, especially, to a less-than-willing development team.
- Setup – in other words, be well prepared. Make sure that the process is not only well defined, but well articulated in whatever form of documentation is appropriate for that organization. In fact, this is one of the major reasons for the incremental approach. It’s just a fact of life that it takes a while (12+ months) to get the architecture and processes specified sufficiently that it can be adopted on a large scale.
- Spare parts – in other words, be prepared. Make sure that you’re ready to adapt to changes in requirements and situations that are not exactly what you’re expecting.
- Make it count. Often, architecture has a muddied history, burdened with previous attempts that did not produce the desired results. We must overcome this skepticism one project and one business unit at a time. Many times, the business is only going along grudgingly because they’ve been told they have to. When this is the case, we won’t get another chance to try again, so we have to make this attempt count.
- Don’t try anything radical. Part of making it count is choosing appropriate projects where an architectural approach will provide value beyond the typical siloed project approach.
- Keep records. Metrics are an architect’s best friend, but you have to actually look at the data collected. Keep track of what you’re doing, measure it against goals, and incrementally improve on things. Incidentally, metrics are one of the best ways to demonstrate the value of architecture.
- Keep a checklist – in other words, formalize the process and make sure that it is followed with some simple but effective governance procedures.
- Don’t get distracted, or as I like to say, “pick your battles.” Pay attention to the things that really matter, and where architecture can really make a difference and add value. For example, don’t get bogged down trying to standardize on a development tool when you could be providing common and consistent customer information instead.
- Keep it simple. For architecture to be successful, it must be understandable. You can’t introduce a complex architecture or process to an organization before it is ready. Start simple, prove the value, and grow from there.
- Don’t get cocky. Remember that architecture provides a service to the organization. We win when we influence the business and development to do the right things.