In this article I want to focus on Decoupled Architecture. This is the start of a small series, in the end driving the idea back to Business Applications, but this first post is going to be quite agnostic.
Very often we are faced with a project where, dues to obvious constraints, like time and budget, we have to produce an output that might not be ideal on the long run. While we’re solving the problem at hand successfully, are we really setting the customer on the right path for the future?
Let’s look at what Decoupled Architecture is in the first place.
This pattern enables layers to execute independently, but keep interfacing together.
Some of the reasons to consider Decoupled Architecture include:
Higher Performance – the ability to execute individual components independently, and in parallel.
Modularity – the ability to have separate components, in many cases written in different languages. You can split your code base into clean smaller modules.
Flexibility and ability to evolve at a faster pace – separate components can be upgrade or replaced without affecting the rest of the system.
Bug handling – you can track bugs at the separate module level, and handle them with separate teams as needed.
Scalability – for new functionality, you can easily add a new module and integrate it into your application.
Testing – unit testing, integration and performance will have separate workflows for each module. This makes testing more manageable, and allows splitting it into smaller chunks, also making the process more effective.
Increased Agility – this modular model allows for more dynamics around features release and upgrades. Only the targeted module needs to be upgraded at one time, leaving the rest of the application intact.
Rapid prototyping – you can easily build PoC’s and integrate them into the larger application without affecting existing functionality.
Team skill-set and capabilities – you can engage a specific skill-based team for a single module, with no impact on other skills required in other modules.
Cloud computing is typically an implementation of decoupled architecture.
These are good points when it comes to development, and a lot of the applications over the last few years have started to implement this pattern. It is very prevalent in open source projects. Separation between various front-ends built using AngularJS or React Js or other JavaScript frameworks, and your typical CMS platforms like Drupal or WordPress are taking advantage of Decoupling Architecture more and more.
In Enterprises, a lot of the custom applications are being designed to also take advantage of this pattern.
There are various styles that satisfy some of the decoupling requirements, and within the Microsoft stack, we gain support for some, like the Microservice Architecture which has gained some obvious popularity lately. In Microservices Architecture, each service encapsulates a small piece of well defined business functionality, and they are loosely coupled. All services communicate through APIs.
Another common model is the Web-Queue-Worker. This is the typical separate between a front-end and a back-end, where an asynchronous message queue is being used to facilitate communication.
Then, there’s the Event-driven Architecture. Here, a publish-subscribe model is enforced, and it’s commonly used for application using large volumes of real time data, like IoT implementations.
Of course, there are other styles that align with the concepts of decoupling, and it’s probably impossible to name them all. But these seem to be some of the most recognized in the Microsoft domain, as far I’ve seen.
This is all nice to know, but in the domain on Business Applications, the platforms are provided, and the extensibility is guided by the offered APIs.
I want to argue here that knowing and understanding these architectural patterns can and will allows us to deliver more value to our customers when implementing solutions.
Let’s take integrations as an example. In most cases, integrations rely on ETL (Extract, Transform, Load). Very seldom there’s no Transform.
Now, ETL can be real-time or batch.
All good now, but, how does that play into Decoupled Architecture, you might ask. As the platforms evolve, we’re seeing a growing need for integrations. Whether it’s some still remaining old legacy platforms, a lot of new modular services and platforms serving only a small specific business need, various customer channels, existing public portals, etc. the need is only growing. We have all kinds of revolutionary new platforms now to integrate, rather than going the traditional way of one single monolithic solution offering to serve the enterprise.
In the next post I’ll be looking at options for Decoupled Architecture when designing integrations. I’ll be looking at some of the tools provided by Microsoft, and how we can leverage these to create a truly decoupled integration.
See you next!
thatcrm.com 