Decoupled Architecture–Integrations

As we’ve seen in the previous article, Decoupled Architecture is a model that allows various layers of a platform to execute independently, but interface together.

In this article I want to focus a little deeper, and tackle the Decoupled Architecture model when it comes to integrations.

Imagine this typical scenario:

You’re implementing a solution in a client environment. During the discovery phase, you identify that the client has several silo-ed platforms serving different business purposes. They obviously have a financial system in place, they have an inventory management platform, an HR system, a platform integrated to the HR system to provide enhanced value to employees, a project management platform, a marketing platform, as well as a few legacy platforms slated to get replaced over the next 5 years. They could also have a few smaller online platforms for very specific business needs. In a true onmichannel approach to sales, they have developer several custom apps, including extending their current site, providing customers with a mobile application, etc.

For now, I just want to focus on the integration to the other major platforms. For the sake of separation, I will call this Platform/Application Integration, versus other topics of integration that we’ll tackle in the future, which include Messaging, Services and Portals among others.

First look at this, we might be tempted to think of this integration in a format somewhat similar to the visual depiction below:

This is just a theoretical example, but it could as well be very real. We have various direct integrations between the platforms, each built at different times in the evolution of the organization, using various toolsets, and very specific for each integration. Over time, this can easily become a bowl of spaghetti hard to keep track of, and hard to manage. As certain 3rd Party Toolsets become old and loose support, a challenge is presented when it comes time to maintaining or extending these integrations. As the organization grows and introduces more platforms, new integrations are required. There is no standardized mechanism in place to control this growth, and the skillsets required to support all these integrations grows exponentially.

Furthermore, some of these platforms can be on-premise, while others are cloud offerings. And to complicate things even more, most of these integration are tightly coupled. One system goes down temporarily, or needs to be upgraded or replaced, like the financial system for example, and now you’re faced with rebuilding multiple integrations to various end-points.

But what if this could be simplified, and re-organized in a decoupled fashion? What if a standard can be brought across all integrations?

From a toolset perspective, we have several options to achieve this. Depending on complexity, we could use something as simple as Azure WebJobs, part of the Azure App Service. For those of you old enough like me, that have worked in on-premise environments for a long time, this is basically just running a script.

One level up, you can leverage Azure Functions. These are basically HTTP-based API endpoints. The beauty here is that they can be accessed by regular applications, mobile applications and can be leveraged in IoT scenarios. Data model is still a simplified one though.

Moving one more step up, we can leverage something like Logic Apps. Trading some efficiency for usability and simplicity, this is a powerful platform to build integrations.

Finally, at the top of the complexity scale, you probably guessed, BizTalk stands tall. A very robust approach to integrations, allowing complex orchestrations and spanning across multiple domains.

But, toolset aside, architecting a decoupled integration boils down to the Message Queue concepts. You are passing messages of data from one application to a queue, where they are picked up by another application for processing. This is the Service Bus Messaging approach supported by Azure Service Bus.

Now, with this approach to our architecture, in a very simplistic form, this could look something like this:

You would obviously have multiple publishers, and multiple subscribers, depending on the various platforms participating and the data flow.

At a more detailed level, you could be looking at something along these lines, leveraging Logic Apps and the Azure Service Bus:

Now, scale that to a more complex scenario (not as complex as the original image as that would make the example too busy), and you could have something like this:

Observe the beauty of it though. If the 3rd party toolset used for the Inventory Management System needs to be replaced, it does not affect any of the other components of the overall design. There is no impact to the rest of the design, and the Inventory Management System can be brought back online and resume at the last captured message in the relevant Service Bus Topics.

And the same applies for each of the components. A single failure only restrict access to a small part of the ecosystem, and it resumes where it left off as soon as it’s back online. Furthermore, the skillset required to maintain this could be greatly reduced as standardizations are applied across the board.

In the next post I’m going to drill a little deeper into Portals and the Decoupled Architecture pattern.

Until then, have fun!