Software Architecture - How well we practice it?

My Series2-Blog on Software Architecture – General Viewpoint dated 16-Sep-2021, was concluded with following notes,

1.    There is a need to increase the awareness about the importance of “Software Architecture”.
2.    If one is keen and want to climb the technical ladder and be a “Software Architect”, one should have a good knowledge of other technical and non-technical areas along with their area of expertise.

This made me curious to know How well we practice Software Architecture? Poll and Blog-Series3 is all about it. In this blog like my earlier ones, I will walk through the poll questions and the results. With it will try to infer How well we practice Software Architecture?

Let’s see what poll results say:

Poll1 question was,
For the development of “Software Architecture Specifications” for a project/product who do you think should be involved?
Poll1 result:

Poll1 Dive in:
Option B and C have equal weightage, so let’s dive in and see which one is the winner. Or do we have some unexpected winner 😊?

We all know the famous saying Too many cooks spoil the broth.

This saying is applicable to various industries and related domains. How? We will see it as an inference to the Poll1 result.

We know that in the democratic world, we have president, prime minister and cabinet ministers to help in the smooth functioning of a country.

When it comes to software industry we have architects, designers, developers, project managers, IT infrastructure teams, database management teams and so on. They all have their own role to play and their own area of expertise to leverage their creativity for the smooth functioning of a software system.

So, is it true for software architect role, Software Architecture specifications, it’s design and development task? It when done with
Architect + Small Tech Team brings in better results. When a small group of like-minded people having a common goal works under a visionary leadership, they complement each other and bring in wonders.

This doesn’t mean there is no interaction with other teams and others are just given the specification to implement. It means there is a decision maker, a technical helper who has wide knowledge and who can be a good guide for smooth design, development and deployment of the software system.

He/She is a moderator who helps connect the Right Piece at Right Time and in Right Place. In project management language I would say Software Architect is more like a Servant Leader who keeps Us before I. He/She works with a small group of people to build the Software Architecture which is useful to build and have a robust and long-lasting software system. This team would be the main group involved in development of Software Architecture Specifications, however they interact with other stakeholders (business teams as well as internal technical teams like dev, test, IT infrastructure and so on) to get the clear insight on business and strategic context thus keeping them inline.

This concept is even well explained in my personal favorite book “The Mythical Man-Month” by Fred Brooks. It’s written many years ago but the ideas mentioned in the book still applies to the current scenarios.

Having said above points, I would relate the saying that rather than having too many cooks to spoil the broth, it is beneficial to have involvement of Software Architect with small group of members to develop Software Architecture.

With this my vote in Poll1 goes for Option B [Architect + Small Tech Team]

Poll2 question was,
What factors would you consider on initiation and in defining of “Software Architecture Specifications” for a project/product?
Poll2 result:

Poll2 Dive in:
Option D have more weightage, which made me think that we are on path of practicing Software Architecture well.

There is a short note which I felt relates to our Poll2. Let’s see what it is?

We were all comfortable using landline phones few decades ago. Then came in pagers, followed by mobile phones, followed by smart phones. Happy human faces with new advancements.

Advancement is good, however old things, experience with it, hurdles faced using it have always helped us value the new thing that is in trend.

Smart phones are great but expensive. Their life is limited. Requires change in 2-3 years. Sometimes there is an issue with speed, sometimes with battery, sometimes with network and so on. But landline is our old-time pal. It has always remained with us during all weathers and have passed the test of time since the time of Alexander Graham Bell.

We human beings have an apt to adapt the change and go with the flow. It’s the Theory of Survival. But that change when adapted with keeping strong old roots in mind always take us ahead in the journey.

Option A - Ongoing Tech. Trend is like our smart phones. Option C - Old & New Tech. is like our pagers and mobile phones. Option B - Past Experience is like our landline phones.

Past experience is a strong root, while new trends are helpful to keep us in the market. Past experience brings in depth while latest trends bring in width of the knowledge. Together they keep us well rooted and stable. Together they help us design a robust and well-connected Software Architecture.

So, all of the above is a more suitable answer. With this my vote in Poll2 goes for Option D [All / Other (Comments ☟)].

Poll3 question was,
Do you prefer to consider and refer available standards and practices before working on Architecture of any software/systems?
Poll3 result:

Poll3 Dive in:
Option A have more weightage, which shows we trust standards.

Many of us are brand loving people and will agree that we relate the quality of any product with the brand name. Bigger the brand, bigger the standardization, bigger the value.

ISO, IEC, IEEE all are valid and valued standards. Afterall, all these standards are well-defined as a result of discussion and through review by experts. Great human brains are behind it. They do hold a great value. When not sure what would be beneficial and how should it be done, standards have always come in handy.

So certainly, it goes without saying that referring the available standards and utilizing it with a level of customization and flexibility to fit it into our business and strategic context, is always a wise choice while proceeding for any important task. And so is it true while working with Software Architecture of any software/system.

With this my vote in Poll3 goes for Option A - Yes

Poll4 question was,
Out of the few listed "Software Architectural Patterns" which is your preferred choice and why (please write few lines in comment)?
Poll4 result:

Poll4 Dive in:
Poll4 got a very much expected voting. Option D most talked about pattern Microservices.

Microservices is the new normal now a days when architectural patterns are talked about. A much-hyped pattern.

Microservices is of course good but not the solution for all the issues. It may be good for new software/systems like OTT platform to load user preferences but may not be useful to convert tightly coupled legacy system to solve its issues. It comes with increased complexity and tradeoffs to security and performance. Of course, there are work around for tradeoffs too. But we will talk about it separately in some another blog.

Layered and MVC have its own benefits. Sometimes in MVC one may end up with wrong distribution of the task and add more complexity.

An architectural pattern in general is a reusable solution to a commonly occurring problem in Software Architecture within a given context. So, patterns are certainly useful but one needs to be thoughtful to use it at right place.

I am going to have a separate blog on patterns soon but Poll4 question was to understand how we choose patterns? Is it more by trend or more by our business context? That is the reason I asked for a preference and the reason to use it. I didn’t get answer on Why during the poll? But choice itself was sufficient to come to a conclusion on this Poll.

With this, I would say we may have liking for specific pattern but it might not fit in our context and as a result though it being popular and preferred one in the market, we have to let go it’s use and opt for something that suits our context.

Having said this, my vote in Poll4 goes for Option D - Other (Please mention ☟) which would be to select pattern that is more relevant to my business and strategic goals.

Summary:
We do practice Software Architecture but many of us get influenced with ongoing trends. It should be practiced with thorough knowledge of past, present events and considering future outcomes.

More awareness on the subject Software Architecture, it’s value and its correct implementation is the need of hour.

If you have any comments, I will be happy to hear from you. Do write to me at hiralbd19@gmail.com. Visit https://www.hiralvyasdave.com

Note:
There are well crafted courses available to learn and master the art of Software Architecture. They are created by the Software Architects for the Architects like iSAQB-CPSA certifications and related accredited trainings.