- Published on
The ambiguity of software architecture
- Authors
- Name
- Damian Płaza
- @raimeyuu
Party people
Imagine that we were asked by our friends, a couple, to help them organizing their the wedding.
It's a big deal, as there are so many moving parts!
What about the food?
What should be the ratio of traditional meals, in comparison to "modern" ones?
Don't forget about vegeterians!
Yeah, food is one thing, but what about the seats?
Should we group young people together and leave older people sitting next to each other?
Don't forget that auntie Dorothy doesn't like talking with auntie Marie!
Music - what's should be the ratio between good'n'old songs and the latest pop hits?
There's no good or bad decision, we just need to understand the conditions we have.
Let's focus on the way we organize seats.
Far from the DJ? Yes, please!
Turns our there are much more constraints we need to take into account when we are organizing the seats.
People have their local preferences that sometimes are pretty darn impossible to satisfy!
Eventually, everything becomes clear when we went into the place where entire celebration will take place.
Well, this situation constrains as a bit.
We won't be able to distribute people as we would wish for.
We decide to go with friends and younger parts of the family to sit together, and let older parts of the family be with each other.
Additionally, older parts of family will sit far from the DJ, as grandma Susanne complained about "her ears dying from the modern beats".
Our friends, that we're hepling them, were amazed by the skills we have!
Now, everything looks so crystal clear.
We've made a really good job!
Workshop? Yes, please!
Turns out that the rumours about our outstanding performance, regarding organizing seats for the wedding, were spreading so rapidly that we got another request.
This time, another friend of ours, who's organizing a workshop for elder people on how to use computer, asked as if we could do him a favor.
Sounds easy, isn't it?
We've already tried out one pattern and it make total sense...
...In the wedding context, at least.
As it's easy to start with, we have asked our friend if the same pattern of tables and seats, that we used for wedding, wouldn't make a decent job.
The principle of the least effort doesn't work this time.
Our friend gives us some additional piece of information, when it comes to this workshop.
Three, really mobile mentors
The staff, doing the workshop, will consist of three young and bright mentors.
They will try to do their best to faciliate and help elder people.
In general, twelve seniors are going to come.
What's more, our friend wants to keep attendees close to each other so they can feel support while facing some struggles.
Turns out that our mentors would need to be pretty mobile so that everyone feels the presence of a knowledgeable staff member.
Eventually, when we went into the premise, where the workshop will take place, everything became clear.
Decision was made.
After couple of weeks, we got a feedback from the friend that "all attendees felt that no one was 'alone', and everyone could support others in all the efforts!"
Software architecture?
I hope, my dear Reader, you're now wondering "how the hell seats has something to do with software architecture?!".
So actually, what is a software architecture?
One of the images, that is drawn is that there's a wizard, sitting on the magical orb and grasping an ivory tower in his hand, creating big plans and making important decisions.
Maybe he has a black cat, too.
Then, builders, doers or peons are just executing the masterplan.
Another answer that is typically summoned is "the decisions that are hard to change later".
Yet another one could be;
Architecture is about the important stuff. Whatever that is.
Let's use Wiki definition:
Software architecture is a term for the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations. (...)
It's all makes sense, isn't it?
Also, it's about decisions.
Those ones that are hard to change later. So the software architect, creator and big planner, needs to make it all before everything starts.
But really, why are we naming it as "software architecture"?
A denture
Somehow I have a feeling that back then we didn't have a good metaphor for those things we consider as "important".
Our industry was crawling, craftsmanship wasn't yet there and you must explain to someone non-techy that this single decision might give problems in the future.
Typically, we would use something common, so that both sides would understand.
Software is being build, we plug or glue things together and so on.
You're getting the point, right?
Software is not like building houses. It might be one of possible metaphors, helpful in conversation, but is it really hepling when doing it?
Hence I am not satisfied with existing definitions, or attempts to cover this highly important, and sometimes mythical concept (Concept? You might be interested in Concepts, Entities, Data).
As you might know me (hopefully, dear Reader!), I like playing with the language because it might actually open a new ways of thinking (models?).
How to name it?
At the beginning of this little tale, we were involved in organizing seats in two differents events.
The way we organized where people will sit, what would be the table arrangement, was the key aspect of achieving the goal.
Our decisions and ideas were depending on what we wanted to achieve or what to support.
Could you imagine another scenario when we would need to organize tables and chairs for a lecture?
Would tables be even needed?
One of the best definitions I've heard comes from Udi Dahan's talk (it points to exact moment of time when it appears).
Quite simply, a way of organizing things
It's so concise, so terse! And also it captures the essence, as it's focused on the process, on the act of doing it.
To make it a little more complete, I extend it a bit in the following form:
A way of how we are organizing things to achieve or support X
Powerful, isn't it?
As in our two examples from the beginning of the tale, we organized the seats and tables in certain ways to achieve or support some qualities.
An avid Reader might say - "architecture is more than a structure!" - and that's true.
Organizing things
It's true because this thing we call (by mistake?) architecture, it's much more than just a structure.
But this way on how we organize our thinking about architecture also supports other aspects of it.
In case of the wedding, we focused on organizing the communication so that two aunties won't start a bar fight in the middle of the celebration.
When we worked on the workshop scenario, we put our attention into attendees feeling taken care of and supported.
It was much more than just a structure.
Hey, what about "architecture as (hard) decisions"?
"Decisions about the way of organizing things" and "a way of organizing things" are two different beasts.
In my mind, architecture shouldn't be conflated with "decisions", as we have another process for that (I am thinking of "designing", an activity - more about it in the next blog post!).
Isn't that too broad?
You might wonder, dear Reader, that "a way of we organize things to support or achieve X", might be too broad.
Software architecture touches various aspects of our industry, but typically it boils down to technical things.
Data models, sequence diagrams, technical tools, frameworks, scalability, loose coupling, and so on.
What makes me happy is the fact that we're maturing our approaches in perceiving things we build, create and operate as sociotechnical systems.
Take famous Conway's Law as an example.
Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.
A way of organizations organize a communication structures supports limiting a way these organizations design so that the structures of designs are the copy of the organization communication structure.
We could simplify it as: the way we organize teams will impact designs that those teams will produce.
Again, it's about the act of organizing, the process of arrangement.
This process touches every aspect of human activity. Hence, it's widely applicable!
Should we drop the name "software architecture"?
Of course, that's the right moment to do so. This blogpost will rule the world and turn the entire industry around.
Jokes aside, "software architecture" is an abstraction for "a way of how we organize things to support or archive something".
Could you imagine your boss asking you each and every time: "hey, did you finish working on a way we organize communication between the services to achieve desired qualities?".
Looks silly and not funny, isn't it?
We need to abstract the details away. And reusability is not a desired goal here (what I am talking about? Check The ambiguity of abstraction).
This word, "architecture", is a nice replacement for those kind of activities we typically do to organize things so that they support or achieve desired qualities.
As mentioned, it's a nice abstraction.
But leaky one.
Next time, when you will be working on, *cough cough*, architecture in any aspect of your daily work, ask yourself:
How should I organize it to achieve/support/limit/constrain X?