Software Architecture Patterns – Hype vs Reality

Year end Blog - Series4 [28-Oct to 23-Dec, 2021], Part of Tech Thursdays - “Poll and Blog” series on various topics related to “Software Architecture” by Hiral (Vyas) Dave

SOFTWARE ARCHITECTURE

Hiral Dave

12/24/20219 min read

This year starting from July 2021, I got into a new venture of Poll and Blog series. I find interesting to talk to people, interact with them, get their views and learn new things from them. I am very thankful to all who participated in the Polls on my LinkedIn and everyone who supported reading the Blogs.

In July 2021, I planned to have 5 Poll and Blog Series covering various topics related to Software Architecture. But as time passed and events appeared, I could cover only 4 Series till Dec 2021.

To start on a lighter note, I myself became example of today’s topic Hype vs Reality 😊.

Though it is late let’s begin.

In simple English, a general meaning to Pattern is, it is the repeated or regular way in which something happens or is done. It could be anything from pattern for a cloth, embroidery design, car design, medical equipment design, building design… the list is endless. It is used in many industries and so has it found the space in Software world too.

Patterns is a much talked about topic in the technical software community. Whether it is architectural pattern, design pattern, data architecture pattern, mobile architecture pattern and many more such categories, when it comes to any software system design, the term Pattern plays a pivotal role. Some learn it’s usage methodically while some uses their industry experience. On other side there are many who go by books, online reading and knowledge acquired from friends and colleagues.

No matter what is the source, Pattern is a game changer for anyone who is on a technical leadership role.

 Even my Blog writing has a Pattern.

In this series I will be talking on Software Architecture Patterns – Hype vs Reality

As per my Blog writing Pattern, I would walk through Poll 1-5, analyze the result and add in my inputs to it. Unlike series 1,2,3 having 4 Poll questions followed by Blog, this series has an additional question 5.

So, let’s begin to Dive-in Poll1 to Poll5 of Series4.

Poll1 question was,
For the software systems like Finance & Banking, Insurance processing etc. which one would be your choice of Architectural Pattern?
Poll1 result:

 hiralvyasdave.com - Poll1-2 Result, part of Poll and Blog-Series4
 hiralvyasdave.com - Poll1-2 Result, part of Poll and Blog-Series4

Poll1 Dive-in:
Maximum vote is received for Option C - Microservices

Microservices has become like a teacher’s favorite student. It has become like a universal remedy or say handy solution when it comes to software architectural decisions. It was one of the most discussed architectural patterns in the recent Software Architecture Gathering that I attended in October 2021.

I like the flexibility and independence that Microservices brings in. But with the kind of responsibility that comes being a Software Architect it is always a practical, to the context choice that takes the priority.

First let us see at high level what a Finance & Banking, Insurance processing etc. software systems would require?

Here I will not talk about types of banking systems but the few basics that is relevant in today’s world.

Retail banking functionality is what we all use, like provision of savings and transactional accounts, loans, debit and credit cards and so on.

In addition, with today’s globalization, CORE (Centralized Online Real-time Exchange) banking is what plays a major role where customers may access their bank account and perform basic transactions from any of the member branch offices. Main focus here is that the bank's branches can access applications from centralized data centers.

I came across an interesting article on Core banking which says 95% of ATM transactions pass through COBOL programs. Now imagine you have this legacy system (as mentioned in the article) to convert. How challenging it is to decide on Architectural Pattern?

In general, if we see, for bank employees and customers of the bank essential functionality like opening the account, deposit and withdrawal, getting bank statement etc. would be the central functionality. Where-in, the system also needs to be able to be accessed from different environments and different devices as well as there can be addition like CORE banking.

So, for banking sector overall if we see Performance, Security and Reliability are important architectural characteristics or attributes.

Adopting the emerging technologies, the integration required would come up with a trade-off to almost all the above mentioned characteristics/attributes.

The system if designed with a main/core functionality as a central part with an option to have add-ins/plug-ins which will make modifications and adding features to the system as easy as possible in the future would be ideal in such scenario.

Now let’s see Insurance processing. Neal Ford in his book Fundamentals of Software Architecture have mentioned so well about it. He says,

Claims processing is a very complicated process. Each jurisdiction has different rules and regulations for what is and isn’t allowed in an insurance claim. In such case most of the time large and complex rules engines are used to handle much of the complexity. Adding, removing, changing rules without impacting other rules would require many human hands and it is important to make sure nothing is broken.
The core system here would be the standard process for filling and processing a claim, something that doesn’t change often. The claims rules for each jurisdiction if contained in separate standalone plug-in components, would make it easy and simple for rules to be added, removed or changed for a particular jurisdiction.

If we see Microkernel Architectural Pattern, it serves well when it comes to Core Kernel and Plug-in mechanism. For above examples it could have been a better choice.

To me surprising was there is no vote to Microkernel. I understand it is contextual to decide on Patterns but at least it could have been considered as a potential solution.

This makes me think of the Hype that Microservices holds. But it is debatable and of course one needs to opt for the best suitable solution for that given situation.

With this my vote in Poll1 would be for Option B – Microkernel or Option D – Other (Comments ☟) where I can think of a Hybrid Architecture Style.

Poll2 question was,
Keywords like Hexagonal Architecture, Onion Architecture, Domain Driven Design relates to which pattern?
Poll2 result:

hiralvyasdave.com - Poll2 Result, part of Poll and Blog-Series4
hiralvyasdave.com - Poll2 Result, part of Poll and Blog-Series4

Poll2 Dive-in:
Option C – Ports and Adapters have 50% vote and that was much expected result. It's Reality.

Hexagonal Architecture an alternative name to Ports and Adapters. By the man himself, the inventor Alistair Cockburn.

The Hexagonal Architecture divides the system into loosely-coupled interchangeable components; such as application core, user interface, data repositories, test scripts and other system interfaces etc.

The application core contains the business Domain information and it is surrounded by a layer that contains adapters handling communication with other components in a common way.

The Onion Architecture proposed by Jeffrey Palermo in 2008 is similar to the Hexagonal Architecture. It also has emphasis on loose coupling. In the very center is the Domain model and around the Domain model are other layers with more behavior.  

Both Hexagonal and Onion share a common understanding:

Externalize infrastructure and write adapter code so that the infrastructure does not become tightly coupled.

Even the Clean Architecture which is not part of the poll but is on similar concept is mentioned here. It was proposed by Robert C. Martin in 2012 and it combines the principles of the hexagonal architecture, the onion architecture and several other variants.

Domain Driven Design (DDD) is about mapping business domain concepts into software artifacts.  DDD is an approach to software development that centres the development on programming a Domain model that has a rich understanding of the processes and rules of a domain. 

To know more about Domain Driven Design, explore https://www.domainlanguage.com/ , a consultancy focused on Domain-Driven Design (DDD) and led by Eric Evans, who wrote the first book on DDD, Domain-Driven Design: Tackling Complexity in the Heart of Software, 2004.

If we see one thing which is common to all the keywords of the Poll2 is, they are Domain centric and some or other way they contribute to the concept of how internal core and external infrastructure interacts which points to the ideology behind Ports and Adapters.

With this my vote in Poll2 goes for Option C - Ports and Adapters

Poll3 question was,
For changing or upgrading Legacy Monolith system which approach would be a better choice and Why? For "Why" please comment if possible.
Poll3 result:

hiralvyasdave.com - Poll3 Result, part of Poll and Blog-Series4
hiralvyasdave.com - Poll3 Result, part of Poll and Blog-Series4

Poll3 Dive-in:
Result of Poll3 is a very much expected one and makes me think of the Hype associated with the Microservices.

There is no one size those fits all and that applies to our current context and understanding with Microservices too. Microservices is not an answer to all type of needs or it is not a solution for all the legacy monolith’s being changed/upgraded.

Recently, in Oct 2021 I attended a Microservices workshop and even our workshop conductor was of an opinion that there are situations where Microservices may not be a fit.

Microservices comes with operational complexities to manage the services and the infrastructure. Versioning, releasing, scaling, communication of services has its own challenges. It requires skilled team members and sometimes even in more numbers. Again, if security, performance etc. is your top architectural requirement definitely it adds to another level of complexity. All these would certainly impact the overall project cost too.

If your scalability needs are manageable, your team size is less may be Modular Monolith can be a better alternative choice.

With this my vote in Poll3 goes for Option C - Other (Comment ☟)

Based on my context, the existing state of the environment, I would decide on Modular Monolith, Microservices or may be a better alternative for the change/upgrade of my Legacy Monolith system.

Poll4 question was,
In today’s world of mobile technology which Software Architectural Pattern would be preferred one for developing mobile applications?
Poll4 result:

hiralvyasdave.com - Poll4 Result, part of Poll and Blog-Series4
hiralvyasdave.com - Poll4 Result, part of Poll and Blog-Series4

Poll4 Dive-in:
Option C has more weightage. With each Poll having higher vote for Microservices, Hype is taking a control. Patterns are always used as a support solution to a given scenario/situation/context. So here there is no comparison of patterns but it is more about how well we handle the given scope/situation.

As we discussed earlier, Microservices comes with its own overheads and trade-offs.

MVC, MVVM are preferred Software Architectural Patterns when it comes to mobile design.

It also depends on whether it is a Native, Hybrid or Web based mobile application that is being worked on?

Model-View-Presenter (MVP) which is a derivation from the Model-View-Controller (MVC) is another popular pattern.


For MVP I would say a design pattern used mostly for building user interfaces in mobile apps.

Then there is much talked about VIPER [View-Interactor-Presenter-Entity-Router] a design pattern mostly used on the development of iOS applications.

 With this my vote in Poll4 would have been for Option B – MVVM or D: (Comment ☟)

Poll5 question was,
Which Software Architectural Pattern relates to keywords Data Flow, Data Processing, Series of Independent Computations and so on?
Poll5 result:

hiralvyasdave.com - Poll5 Result, part of Poll and Blog-Series4
hiralvyasdave.com - Poll5 Result, part of Poll and Blog-Series4

Poll5 Dive-in:
Maximum vote is given to Option A – Pipes and Filters. A Reality one believes in.

Of course, all the keywords take our attention towards Pipes and Filters.

It’s a very old one and well-defined Software Architecture Pattern when it comes to data processing, stream processing, independent computations and so on.

It is a simple architectural style that connects a number of components, more precisely independent processing steps (called Filters) that process a stream of data, each connected to the next component in the processing pipeline via a Pipe.

Unix is the one of the most popular examples where Pipes and Filters architecture is used.

With this my vote in Poll5 also goes for Option A – Pipes and Filters

Summary:
An Architectural Pattern is a general, reusable solution to a commonly occurring problem in Software Architecture. It depends on multiple factors which will influence our approach to select the particular Software Architecture Pattern. It depends on the context. Knowing and applying the right Pattern or a combination of Patterns for your software systems is a pivotal task.

Today the need of hour is we must understand the Reality and have an awareness on the Hype. Always have a check on Hype vs Reality when it comes to using Software Architecture Patterns.

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

Wish you a Happy and Healthy 2022...

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.