This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
My understanding on patterns is that they are generic solution templates to commonly faced problems in Software development. But, does that mean that a good Software Architect should always try to find solutions using them? The reason I ask this question is to understand the importance of patterns in a Software Architect's arsenal.
I don't think the question is whether you should always use them -- a good software architect will use the best tools at his/her disposal and the toolbox will always have a few patterns in it. At some point, using patterns is practically inevitable. To me, the more important question is really knowing when to use them and how to recognize the appropriate pattern to use, i.e. recognizing the pattern that applies to a given context.
One aspect of patterns that folks tend to overlook is that they are a great way to communicate ideas, assuming of course that everyone involved in the conversation has a common understanding of the pattern's vocabulary. So even if you aren't applying a pattern to your software, just talking about the pattern can be useful in spurring and facilitating conversation and debate about technology decisions that need to be made.
It is important to note that when we talk about patterns in architecture, there are patterns beyond the ones GoF documented. Also, hopefully, the architect would be experienced enough to not only when to apply the patterns, but also create patterns that can be used to solve common problems in the organization. Think of the list of patterns as a toolset. Each pattern is a tool. The architect should be able to educate other members on how to use the tools in the toolset, but also invent new tools to add to the toolset.