I will try to describe my understanding of the software architecture in this topic.
Before I do that, please be informed that there are numbers of different definitions of this same term. They differ from author to author, and obviously enough, I am providing my own definition here.
Term "Software Architecture" takes its beginnings from the combination of the Software and Architecture, which should give some context to our thoughts already. While we (technical people) know more or less what Software is, we also know what Architecture is approximately. Since it is the basis of my thoughts when thinking about the definition to provide here, I might as well use this definition to define an Architecture as I understand it.
So, here is the basic definition of the Software Architecture, which we will discuss a bit afterwards:
- Software Architecture is a set of base principles used to build a product at hand; it's a combination of style, rules, and instructions working in tact to create a feeling of integrity of the overall system.
Every part of the definition was put together with the particular intention, so let me depict this into sub-principles of the software architecture (describing almost each word from the above statement):
1. Productized: Software Architecture exists to support existence and functionality of the product (Software). Without a product, an Architecture does not really exist.
2. Principle-based: Software Architecture is a set of principles that derive either from the expectations for the product it supports, or from the experience and practices of the similar works.
3. Styled: Software Architecture follows style of the author (Software Architect), as well as shows signatures of the implementers (Software Development team). Since it is an outcome of the authoring and writing activities, its style can be distinguished from those of the other authoring and writings. Good architectural style grabs more attention and delivers a better product.
4. Ruled: Software Architecture introduces rules; meaning, it cannot be used in any way possible. Rules that I see can be divided into two kinds.
a) Rules for implementers: developers cannot make drastic changes to the initial idea behind the Software Architecture given to them. They can extend to some extent, but cannot change.
b) Rules for stakeholders: if conflicts of interests are not identified on early stages, they will hardly make it to life. If stakeholders decide to make a banking software behave as an airline ticket booking system - that will be unlikely to happen - not within the same architecture.
5. Instructional: Software Architecture should be modeled the way that it is self explanatory enough; this is to properly instruct its consumers about the ways it can be used and extended.
6. Integrity-bounded: Integrity of the Software Architecture must be ensured by providing things in the inter-connected manner. There is no Software Architecture if we provide 100s of classes that happen to be completely unrelated to each other. So, integrity draws a boundary of the system that is supported and built by using given Software Architecture.
You should have picked the idea of software architecture, and I think you can be interested in learning about my definition of software architect.
Also, I wanted to quickly mention that I teach training classes on topics around software architecture. Check them out by clicking here.
The author of the above content is Tengiz Tutisani.
If you agree with the provided thoughts and want to learn more, here are a couple of suggestions: