Software architecture plays a very important role in the delivery of successful software systems, yet it is being neglected by many teams. The software architecture role exists in every team. However, most of the time, the "architecture" reflects wishful thinking rather than reality. Many teams think that they do not need software architects, because they can "self-organize". Many teams throw around words like "YAGNI", "evolutionary architecture" and "emergent design". Being agile has many benefits, but it does not discard the responsibility of having just enough upfront design.
In the IT industry, the term architecture has many meanings to many different people and there are a lot of definitions of what it means. Here are a few: "software design", "the big picture", "plan", "technical direction", "foundations", "abstract view", "non-functional requirements", "standards and goals", etc. The truth is that there isn't a single valid definition. Therefore, there are many types of architecture: "application architecture", "software architecture", "it architecture", "platform architecture", "infrastructure architecture", etc. What do they all have in common? Structure and Vision.
At a first glance, "software architecture" could be defined as the architecture for a piece of software. Right? It is true, but it goes beyond software design.
This is the term that developers use the most. Developers are familiar with the concept, because they create applications (desktop, web, mobile, etc.), and, in this context, architecture represents the building blocks which are predominantly programming languages, technology choices, frameworks, libraries, APIs, etc.
System Architecture scales one level up, and we think of the "software system" as being composed of multiple applications. We might have a web facing app communicating with a backend service, which, in turn, has access to a DB server/system. Of course, all of these applications must run on a piece of hardware. Therefore, system architecture is a mix of software and hardware.
That being said, the combination of System Architecture and Application Architecture gives us the Software Architecture. Well, it is not just about software. Isn't that right?
Architecture and design are two terms commonly used to define the same thing. They do have something in common, but they do not mean the same thing. As Grady Booch said: "All architecture is design, but not all design is architecture." So what do they have in common? They share the process of making decisions. Every time we have to create a design or an architecture, we basically make decisions, we investigate what platform to use, we investigate framework choices, we investigate libraries choices, etc.
The key difference in these decisions is the cost of change. An architectural decision is more important than a design decision. And how can we measure the importance of a decision? We can measure it by assessing the cost of change.
For example, let us consider the decision of writing a web facing application in ASP.NET MVC. What would be the cost of change to "shift" it to AngularJS? Of course, it would take weeks depending on the current progress of the application. This is, therefore, an architectural decision.
What about choosing between two different logging mechanisms? We chose Microsoft's Event logging system, but then we wanted to switch to NLog or log4Net. Of course, this refactoring could be easily done in one business day.
Essentially, all significant decisions are "architecture" and everything else is "design". Architectural decisions are those that you cannot revert in one afternoon.
We talked about software architecture, but we didn't talk about the role. First of all, software architect is not a rank in a company. It is a role. Software architects do not live isolated, in ivory towers. Being a software architect requires both good technical skills and soft skills. A software architect introduces control, structure, and vision. And yes, they should code too and be collaborative with the team they belong to. Here are a few of the soft skills that a software architect should have: leadership, communication, negotiation, collaboration, coaching and mentoring, etc.
So how do we create an architecture? What tools do we use? Well, the choices are many but we do not really need a UML diagram tool. We can draw diagrams on whiteboards and flipcharts. The idea is to have a collaborative design. Remember that the architecture is meant to introduce structure and vision.
Here are a couple of examples that lack both structure and vision:
"The airliner"
"The Eh?"
It is very difficult to show an entire system in only one diagram. Today's systems are very complex with many standpoints to be analysed from. A "smart" architecture shows different views which highlight different aspects of the solution. Try to imagine a very high-resolution panorama picture. If you want to see the details, you must zoom in. There is no way you can see all the details from the highest standpoint.
This is not a set of rules, but rather some guidelines which were introduced by Simon Brown in his book "Coding the Architecture". This is the "C4" model: Context, Containers, Components, and Classes. As we "zoom in", we discover more details and aspects of the solution.
Describe the "big picture". Who are the "actors", who is using the system and what are we building? This kind of diagram can be shown to non-technical people like the upper management, for example, and they should be able to understand it.
A container is everything that can host code or data. A web App, desktop App, DB, file system, etc. can be considered containers. In this case, we could draw the high-level technology choices and the communication between them.
The component diagrams show the high-level technology decisions, and the interaction between the modules and other services.
The main question that we should ask ourselves is: "Are we going to code it that way"? This is a very important aspect, because, more often than not, the architecture is more like an "aspiration" for what the system should look like.
How much architecture is enough architecture? Obviously, one cannot design the whole system from the beginning and it would not be recommended to do so, because new systems change a lot. Well, the answer is to have just enough up front design to introduce structure and create a shared vision for your team. Identify the key risks and provide a vision to move forward.
Try to do some architecture rather than nothing at all or all at once. Be pragmatic rather than perfectionist. Create short and useful architecture documentation over encyclopaedias that are not up to date, that no one reads and cares about.
Always choose simplicity and common sense over complex and overly architected solutions.