2017-09-21 by ANDERS NORBERG
System architecture is about the components of a system and their relationships. You can also expand the concept of the principles that determine how these components and relationships are built up. A system architecture is about multiple views on the same system, such as structural and behavioral views, which means that each software system has a unique system architecture.
If a development project goes straight to the implementation phase and skips analysis and design, it will inevitably lead to an ad hoc software architecture. For all but trivial software systems, an architectural approach is important in achieving a system architecture that shows good quality. Quality means in this connection to fulfill all the requirements, the implicit and explicit ones that satisfy the views of all interested parties. One of the most important disciplines in a project is the mapping of system architecture requirements using a systematic approach.
This means not only drawing bubbles in graphical tools. In the end, system architecture is just a means of implementing, no less and no more, a software project in a way that provides a high quality product / solution. All these considerations lead directly to what we call tactics and strategies. A strategy identifies an indicative principle useful for achieving a certain goal in the software system as a whole. For example, how should your application behave when it comes to issues such as availability or error management? In order to ensure that the goal supported by the strategy is really met, it is important that the definition is clear. In the case of overlapping definitions, it is very likely that some of the developers will do one way and others in another way. Ultimately, this will have a negative impact on the maintainability and quality of the software.
What is tactics? Contrary to strategies, tactics are more detailed and closer to implementation. A tactic helps solve local problems, rather than dealing with the entire software system. Just like strategies, tactics also need to be clear and clear and properly implemented, it will support the implementation of strategies.
How should you work this out then? The best thing is to take it in two steps; Begin by defining the “baseline architecture” by utilizing the strategies that emerge from the requirements and drives the entire software architecture. As the next step, the “baseline architecture” should be refined using the tactics defined.
Yes, but in which order should I integrate strategies and tactics? Strategies (and tactics) must be derived from requirements, allowing risks and priorities to drive the order in which the architectural design is built. For example, for a system where performance is much more important than platform independence, you will build a completely different architecture than a platform where platform independence is the most important. Thus, in the first case, you will focus on performance (caching, pooling, load balancing, concurrency strategies), while in the second case you will apply appropriate strategies for platform independence (strict layering, wrapper-facades, reactors).
A good exercise may be to look at an ongoing or recent project and list all the strategies and tactics that apply there. Do you apply a systematic approach to treating and integrating strategies and tactics? In each project, you should regularly take some time and reflect on the project to keep it on track!
Good luck! – Anders Norberg, LeanDev