What do you mean when you want to know about software architecture ?
What do you mean when you want to know about software architecture ?
My take on the simple yet overloaded question about whatever Software Architecture is.
I am starting to dislike when someone asks me about the architecture of the product I am working on. I don’t dislike them for asking this question, but for the fact that I don’t know how to reply to this question. A question about architecture is an overloaded question, and one that has many facets.
So, when people talk ask you about your software architecture, they often mean one or more of the following :
What are the different parts of your system ?
What are the inputs and outputs of your system ?
If you want to make a change, where should the change be ?
If there is a problem in your software, how do we know where the issue is ?
When the system has more users or high usage, will it be able to support it ?
From Martin Fowler:
When people in the software industry talk about “architecture”, they refer to a hazily defined notion of the most important aspects of the internal design of a software system
To one or more of these questions, often the replies come in the form of following :
Here is the diagram that shows our system - big or small coming together in one amazing piece of convoluted diagram
Or, here is how the system is deployed including the load balancers, application server, database etc.
Ralph Johnson mentions it in a interesting way : “Architecture is about the important stuff. Whatever that is”. What is the important stuff about architecture ? - diagrams, interfaces, deployment view, patterns that are used etc or something else. While all this is important, I see the definition of architecture as something that you can share with your teams so that they can make technical decisions.
To make technical decisions, your team needs to know about things to consider, tradeoffs to make and parameters that they choose to decide the right decision to make at that time.
An architecture, or whatever it is, should be able to make accessible for your teams to know how to evolve their system. This means, that there should be something in your architecture that defines the way you think about your system should work now and how it needs to evolve over the period of time.
Important stuff includes decisions that are hard to change, or perhaps require significant amount of time and money. It also includes stuff that required us to go slow and have people aligned and agreed on it.
Think about Architecture in the form of a framework that helps your team make decisions and leverage these decisions while making incremental changes on the existing system. The framework manifests in the form of:
set of architecture decisions that are aligned with your team and are actively used when making changes to your system,
fitness functions that help provide feedback to your teams when they make continuous changes to the system,
a range of architectural characteristics that can be used to make tradeoff decisions - eg: how to preserve reliability while implementing the security related requirements,
visualization of the current state system in different forms leveraging a standard diagramming technique like C4.
So, the next time someone asks you about the architecture of your system, ask them what specifically they are looking to understand - decisions, characteristics, change fitness functions or visualization of your current state of the system, and share accordingly.
References: