What is Software Architecture

Anyone involved in software development projects is used to the term "Software Architecture". If asked what software architecture really means, most people will throw some of the well-known definitions at you. Just give yourself a try and search for it in Google, Wikipedia, or whatever information source you prefer. You definitely will be overwhelmed by the number of hits. In http://www.sei.cmu.edu/architecture/definitions.html some definitions are available. It's definitely entertaining to read all these definitions which are all valid but only show a part of the whole picture. To be honest, all of these definitions are mostly useless. It is much more important to ask what software architecture is going to provide for a project. In other words: if software architecture is the answer, what exactly is the question? Basically, every software system has a software architecture. However, a software architecture might be worthless when it is built by accident. Let me give you an example. If I just put together some spaghetti code using a trial-and-error approach without ever thinking about software architecture, I'll get an implementation that propably will work. Unfortunately, I'll have no clue why the system is working and I will definitely have a very bad time when being asked to maintain, evolve, change, integrate or otherwise modify or understand the system. As a consequence, software architecture in a more narrow sense should be the result of systematic analysis and design. But even systematic analysis and design might lead to problems when just considering implementation aspects. I've seen a lot of systems that were realized with a specific middleware, operating system, or database system in mind. As soon as some of these system details changed, development teams were doomed to fail. Thus, software architecture should focus on more implementation independent aspects, but also stay in harmony with the underlying system infrastructure (a.k.a. system architecture). In a further step, we should ask ourselves what drives the software architecture design? Basically, all kinds of forces respectively requirements such as desired properties, constraints, commonalities, variabilities have an impact on the architecture. But you may ask, what if there are conflicting requirements, and how to deal with requirements when there are so many of them? All requirements should be prioritized. If there are conflicting requirements with the same priority, then you got a problem! In this case the problem must be resolved with all stakeholders. That brings me to a further perspective on software architecture: First of all, software architecture is about communication of explicit and documented design decisions. This is the reason why I consider domain modeling so important. In addition, software architecture is not only about structures, relationships, dynamics but also about the process used to define all these structures and relationships as well as their interactions. In this context, it proves to be particularly important to differentiate between the strategic baseline architecture and tactical design. The core of the architecture should implement all important strategic requirements. Tactical refinements must not modify strategic decisions. Thus, designing software architecture is mainly a top-down approach, but may also use bottom-up integration of legacy systems or components. As already mentioned, requirements are the drivers for software architecture design. In the process, requirements depending on their priority need to be realized in the software architecture in such a way that requirement traceability is easily possible. Without traceability design erosion will destabilize the whole system, requiring additional efforts for refactoring or architecture recovery. Thus, software architecture mainly deals how to map requirements to appropriate structures. Here, granularity aspects are important. Have you ever tried to build a house by assembling atoms? That does not make sense as complexity cannot be mastered using a fine-grained approach. Therefore, software architecture is about mastering complexity by introducing appropriate abstractions. Patterns are a good example for such "abstract" architecture entities. As some requirements denote cross-cutting concerns, the right structuring of a software system under development is not easy. Consequently, software architects must introduce different perspectives. These different perspectives must be combined and converged to a unified and consistent software architecture. Therefore, software architecture is also about perspectives and the combination of these perspectives, which, however, turns out to be one of the most complex tasks in any software development project, because of emergent behavior. Of couse, this posting could only show the tip of the iceberg. I think, it is obvious why no single definition of "software architecture" can ever satisfy anyone. Nor is it really important to have such a definition. It is much more important to have a common understanding of the benefits of systematic software architecture design.