Technology vs. Architecture
When speaking about “Architecture”, the conversation usually moves to to technologies discussion. Is Java better, or maybe C++? Should we use Windows, or maybe Linux? Which is superior, AWS or Google Cloud? I have even seen a few schools that suggest syllabuses consist of many technologies and call it “Architecture Course”.
Technologies are highly important. They clearly influence the shape of the final product. They might allow or block various development approaches. But still – technology is not architecture. In the most fundamental, simple mean – architecture defines “what”; technology defines “how”. The symbiosis of the two will dictate the final result.
What is “What”?
- Should the system use parallel processes or threads, or be written using simple, linear logic?
- Is a distributed system better than a monolithic one?
- What should two modules in our system share and sync?
These are examples for the questions that the architecture presents to us. Answering them might lead us to choose certain technologies, that allows supporting our requirements.
There will be cases, though, where some of the requirements will be using specific technologies. There might be many reasons for that. For example, preferring open-source solutions, supporting end-users platforms, or even prosaic reasons like leveraging the knowledge and the experience of the team. But even in the above cases, those are only constraints on the architecture; not the architecture itself.
Architecture as an Approach
Being a matter of concepts rather than technologies, the architecture might be applied in various ways, forms and levels. I call it “the fractal form of architecture”. By the term “fractal”, I refer to a system that presents the same principles on whatever scale we look at it. Thus, for example, a design-pattern that offers an effective solution for the coding level, might, many times, become an effective architecture in the system level.
In my other posts, I will provide a few details for that “fractal” form.