Software architecture – land of confusion
Architecture it is still a big elephant in the room for software engineering in general and agile in particular. We do not want to make supplementary mistakes because of unappropriated definition or understanding.
Possible problems:
- Focus on “paper architecture” instead of proven architecture by working software
- Focus on structural aspects and disregards others because lack of understanding for the behavioral dimension or the needed consistency using an architectural style
- Poor real architecture because the goals of the architecture are not understood very well
You can find below some comments about some definitions from significant sources, similarities with construction domain and Uncle Bob notes about “fundamental architecture”.
Wikipedia definition
“Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. It is the set of structures needed to reason about the software system. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building.” (https://en.wikipedia.org/wiki/Software_architecture)
According to this source, architecture is the:
- Structure of the system ….
- Process of creating …
- The documentation …
- A metaphor …
Strange, I could bet that is none of these things! Here are some comments.
Structure … A software solution (“system”) it is represented by both structural and behavioral dimensions. Of course, if there are sub-systems and components, encapsulating both structure and behavior, we could metaphorically (!) say that these subsystems/components are the “structure”.
Process … it is not – it is just a language convention to use “architecture” term also for the “process of creating the architecture”.
Documentation…it is not. Only if the documentation is 1:1 with the real architecture, we could use the term “architecture” for the documentation. For most of the software systems, there are significant differences between paper architecture and real architecture. A better term it is “architectural description”.
A metaphor… we can use metaphors, but if we will implement them, we will build a poem, not a software system.
MSDN definition
“Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.” (https://msdn.microsoft.com/en-us/library/ee658098.aspx)
Process … see above comments.
Quality attributes … another metaphor. Usability, Performance, and others are non-functional requirements, and the quality is the degree of adherence to any kind of requirements. The architecture must fulfill all types of requirements, including the non-functional ones.
IEEE Standard 1471-200 definition
“3.5 architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”
Components … This definition could work for a component-based architecture, where both structure and behavior are intuitively represented using components. In many cases, various structures and behaviors are mixed, “melted” in a single component, and this definition it is unusable.
SEI definition
“The software architecture of a program or computing system is a depiction of the system that aids in the understanding of how the system will behave.
Software architecture serves as the blueprint for both the system and the project developing it, defining the work assignments that must be carried out by design and implementation teams. The architecture is the primary carrier of system qualities such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an artifact for early analysis to make sure that a design approach will yield an acceptable system. By building effective architecture, you can identify design risks and mitigate them early in the development process.” (http://www.sei.cmu.edu/architecture/)
A description, a blueprint… See “Documentation”
Defining the work … see “Process”
Artifact … see “Documentation”
A better definition
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman, Rational ( starting from the work of Mary Shaw and David Garlan) are using this definition:
“Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.”
(See https://pkruchten.files.wordpress.com/2009/07/kruchten-090608-agile-architecture-usc.pdf)
This seems to be a much better definition. Architecture encompasses the set of significant decisions about the software system organization, including more aspects: structural elements, behavior, composition of these structural and behavioral elements and an architectural style.
Summary & Conclusions
Definition – Architecture is about the most important decisions related to the software system (the software solution), including various aspects (see Krutchen& definition)
Requirements and quality – Architecture should address all kind of requirements: functional, non-functional and constraints. The architecture contribute to the system quality, that it is adherence to all these requirements. A modern approach for a better quality is to have a “built-in quality”, and architecture has a major role here.
Process – There is a process of realizing the architecture – “architecting” – that could be different for various software process and design approaches
Documentation – We could document the software solution less or more. Representing the most significant decisions related to the software solution, architectural aspects are the first candidates for a such documentation. A good approach is to have also all architectural intents and decisions directly visible in resulted product.
Similarities with construction domain (?)
In construction, the architecture it is usually split from engineering aspects: structural engineering, mechanical, electrical. In software domain, all the aspects of the solution are part of the architecture. More: the solution in the construction domain is less evolutionary, and the documented architecture & documented engineering (the artifacts), are less likely to be different than the final result.
Uncle Bob: fundamental architecture and details
For Robert C. Martin, the architecture seems to be very similar with the one from construction domain, but in fact I think he use a metaphor to point out what matter most on creating a software architecture.
“Is the web an architecture? Does the fact that your system is delivered on the web dictate the architecture of your system? Of course not! The Web is a delivery mechanism, and your application architecture should treat it as such. The fact that your application is delivered over the web is a detail and should not dominate your system structure. Indeed, the fact that your application is delivered over the web is something you should defer. Your system architecture should be as ignorant as possible about how it is to be delivered. You should be able to deliver it as a console app, or a web app, or a thick client app, or even a web service app, without undue complication or change to the fundamental architecture.” (See http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html)
This is my translation: Martin try to correct those interpretations, where the Web – a delivery mechanism, as he mentioned – it is considered an “architecture”. And it is not! It is a detail (an architectural detail). This “detail” should not affect the rest of the architectural decisions, which could be far more important. Forr this reason details should be decoupled (“as ignorant is possible”) from the “fundamental architecture”.
What is this “fundamental architecture” ?
We can consider the part that realize the functional requirements as fundamental and should not be mixed with frameworks, delivery mechanism and other “details”. That it is the “Form follow function” principle applied in software engineering. If we search carefully, we can discover that many recommendations for a good software design contains a such approach.
Like this:
Like Loading...
