Talk the Talk
Mark Richards
in Any pRoFESSion, jargon is used so that individuals within that pro- fession can effectively communicate with one another. Lawyers talk to one another about habeas corpus, voir dire, and venire; carpenters talk to one another about butt joints, lap joints, and flux; and software architects talk to one another about ROA, Two Step View, and Layer Supertype. Wait, what was that?
It is imperative that software architects, regardless of the platform they are working in, have an effective means of communication among one another. One of those means of communication is through architecture and design patterns. To be an effective software architect you must understand the basic architecture and design patterns, recognize when those patterns are being used, know when to apply the patterns, and be able to communicate to other architects and developers using them.
Architecture and design patterns can be classified into four basic categories: enterprise architecture patterns, application architecture patterns, integration patterns, and design patterns. These categories are generally based on the level of scope within the overall architecture. Enterprise architecture patterns deal with the high-level architecture, whereas design patterns deal with how indi- vidual components within the architecture are structured and behave.
Enterprise architecture patterns define the framework for the high-level archi- tecture. Some of the more common architecture patterns include event-driven architecture (EDA), service-oriented architecture (SOA), resource-oriented architecture (ROA), and pipeline architecture.
Application architecture patterns specify how applications or subsystems within the scope of a larger enterprise architecture should be designed. Some common pattern catalogs in this category include the well-known J2EE design

patterns (e.g., Session Façade and Transfer Object) and the application archi- tecture patterns described in Martin Fowler’s book Patterns of Enterprise Application Architecture (Addison-Wesley Professional).
Integration patterns are important for designing and communicating concepts surrounding the sharing of information and functionality between components, applications, and subsystems. Some examples of integration patterns include file sharing, remote procedure calls, and numerous messaging patterns. You can find these patterns at http://www.enterpriseintegrationpatterns.com/eaipatterns.html.
Knowing the basic design patterns as described by the Gang of Four book Design Patterns: Elements of Reusable Object-Oriented Software (Addison- Wesley Professional) is a must for any software architect. Although these pat- terns may appear to be too low-level for a software architect, they are part of a standard vocabulary that makes for effective communication between archi- tects and developers.
It is also important to be aware of and understand the various anti-patterns as well. Anti-patterns, a term coined by Andrew Koenig, are repeatable processes that produce ineffective results. Some of the more well-known anti-patterns include Analysis Paralysis, Design By Committee, Mushroom Management, and Death March. Knowing these patterns will help you avoid the many pit- falls you will most likely experience. You can find a list of the common anti- patterns at http://en.wikipedia.org/wiki/Anti-patterns.
Software architects need the ability to communicate with one another in a clear, concise, and effective way. The patterns are there; it is up to us as soft- ware architects to learn and understand these patterns so we can “walk the walk and talk the talk.”