Strategies and Tactics

Software architecture is about the components of a system and their relationships. It also comprises the guiding principles that lead to these components and relationships. Finally, a software architecture deals with multiple viewpoints on the same system, for instance structural and behavioral viewpoints. Hence, every software system reveals a software architecture. However, if you just enter the implementation phase skipping analysis and design you will follow an unsystematic approach which inevitably leads to an ad-hoc software architecture. For all but trivial systems a systematic approach is important to achieve software architecture quality. Quality in this context means to meet all requirements, the implicit and the explicit ones - of course, considering the viewpoints of all stakeholders. One of the most important disciplines in a project is mapping requirements to the software architecture using a systematic approach. This does not only imply drawing bubbles in graphical tools. At the end, software architecture is only a means for implementation, not less and not more. Reminds me of the famous Bertrand Meyer, who once said things like "Bubbles don't crash" and "All you need is code". All these considerations lead directly to what we call tactics and strategies. A strategy represents a guiding principle helpful to achieve a particular goal in the software system as a whole. For example, how should your application address issues such as availability or fault handling. To guarantee conceptual integrity and orthogonality strategies shouldn't overlap. Let me introduce an example for such an overlap. Assume, the architects in a project come up with the following strategies: (A) Whenever a security exception appears, a 32 bit error value must be returned. (B) For reporting and handling all kinds of errors and exceptions, structured exception handling shall be used. Both are strategies as they deal with guiding principles for the whole application. But now suppose, you are in the role of a developer. How should you deal with a security exception? Because the two strategies overlap, it is very likely that some of the developers will return error values while the others will apply exception handling. Why is this bad? Overlaps always have a negative impact on understandability and readability of the software architecture. What are tactics? In contrast to strategies, tactics are more fine-grained and closer to implementation. A tactic helps solving local problems instead of addressing a whole software system. Design patterns are very good examples for such tactics. Assume, you have implemented a temperature sensor component which needs to notify other components when specific temperature tresholds are reached. Of course, this is exactly a problem context where the GoF Observer pattern comes into play. Needless to say, that tactics shouldn't overlap either. In the ideal case tactics also help implementing strategies. By the way, architecture patterns such as Model-View-Controller are often applicable to define strategies, while tactical patterns such as Observer help implementing the architecture pattern. I guess, this gives you a better understanding what strategies and tactics are and how they relate with each other. For the job of a software architecture this classification implies a two-step, top-down approach. First define the base line architecture using the strategies that are derived from requirements and are supposed to drive the whole software architecture. In the next step, refine the software architecture base-line using tactics. Yes, but in which order should I integrate strategies and tactics? As strategies (and tactics) must be derived from requirements, let risks and priorities drive the order of architecture design. A system where performance is much more important than platform independence will reveal a completely different architecture than a system where platform independence is king. Thus, in the first case you'll first encounter strategies that deal with performance (caching, pooling, load balancing, concurrency strategies), while in the second case you will preferably apply appropriate strategies for platform independence (strict layering, wrapper-facades, reactors). A good exercise could be to look at your current or last project and figure out all the strategies and tactics applied there. Did you systematically consider and integrate strategies and tactics? In every project, you should regularly take some time and reflect about the project to keep it on the right track!