In the part I of these series it was introduced the importance of the stakeholders in the architecture. In Part II we have learned how to communicate with them, using views and viewpoints. We will now focus on the concept of perspectives, the non-functional requirements in our architecture but usually the most important, like security, audit, logging.
In the previous parts, we have talked about architecture elements, and how to show them to stakeholders in a way understandable for all the parties. By now, we have an initial structure of the whole system, but it misses the most important things in the architecture, and usually the more challenge to include, the quality attributes, or sometimes called cross-cutting concerns, like security, performance, logging, audit, scalability, etc.
These attributes of the architecture are always very challenge to include because they are orthogonal in the architecture. For instance, logging is something we want all over the architecture, probably in all modules, tiers, layers, etc, which implies changing all views already developed.
The name was given to these attributes in the context of an architecture its a little bit controversial, because there are entities that consider these attributes additional views of the architecture, and other entities consider something that change the views, orthogonal in the views, something that complements and can change an entire viewpoint. So it is natural to find these cross-cutting concerns named as views or perspectives. I, personally, like the term perspective, because these attributes are not another kind of views in the architecture, but the application of “quality” in the architecture, the insertion of elements that enrich the system. Like in a house, besides the construction we can improve the whole house with a better light system, internet all over the house, better walls, toilets with material that don’t get rusty, etc.
Why is this important for stakeholders and why we need them? Because they are usually the most important concerns! For instance, in a Bank, security is probably the attribute most important, and I bet almost every requirement includes security, explicitly or implicitly. The people who give support surely they want logging and audit to help them finding the origin of issues or someone who tried to access a resource illegally. In a website like amazon, the end users surely they want a very performant website, and so amazon wants a scalable system, for the system to grow big and in a smooth way.
The quality requirements, are the core of the requirements. They give color and form to the functional requirements. You can create a web page to register a user, but you will want to include audit, logging, security (like HTTPS) and manage the load balancing and scalability, not forgetting about sticky sessions or another architecture tactic (different from patterns).
With all these views, viewpoints and perspectives, you can think the architect will have a fragmented view of the whole architecture, which is true, but someone who wants to be an architect must be prepared for this challenge, find the best way to build a system with all these pieces, that’s why he/she will be an architect. It is not about the technical skills, only, but about choices and stakeholders.