Why Your Application Should Be Built with a Component-Based Architecture


on July 3, 2017

In an ever-changing app development and delivery landscape, organizations are consistently assessing what the right path is, who they should listen to, and how that can impact their business. From the large strategic tech consultancies like Accenture and Deloitte to the analyst firms of Forrester and Gartner, everyone has an opinion on what’s best, but there is no silver bullet.

Those of you that know me personally know that I am quite passionate about technology and ultimately the success of my clients. In doing so, I work closely with Application and Enterprise Architects at Mendix’s largest customers to ensure the Mendix Platform is a good fit, as well as set them up for success with a solid Mendix foundation. With a broad range of strategic platforms, cloud providers, and the latest and greatest open source software – I consistently hear: “Where do I start and what’s the right architecture?”.

One of the common trends in the app development space today is the pattern of microservices and component-based architectures, which when done correctly, gives you ultimate flexibility and scalability where it matters. The fact that Mendix applications are built to be cloud native and containerized creates an ideal ecosystem for creating complex applications with the right level of componentization and flexibility to grow the application over time. With the adoption of Cloud Foundry in the market (and by Mendix for our entire cloud ecosystem), organizations can easily take advantage of these modern patterns and component-based architectures with a much smaller degree of complexity.

One of the common trends in the app development space today is the pattern of microservices and component-based architectures, which when done correctly, gives you ultimate flexibility and scalability where it matters.”

Let’s look at historic patterns and approaches of other RAD platforms: it’s traditionally a monolithic development and implementation that becomes quite rigid over time. This is great for stand-alone applications without a lot of heavy lifting, but when you get into high levels of complexity, you want to be able to scale application components, regardless of dependencies. This is becoming a must-have in enterprise software development, and something Mendix uniquely helps its customers do.

An example of how this works in the real world could be a direct-to-consumer Quote and Bind portal for an insurance customer. These are often highly complex systems, including integrations, underwriting, payment capture, topped off with the need for a great user experience. In traditional app development and in other platforms, this would all be built in one monolithic application, sharing the same hardware, and creating one point of failure.

What Mendix enables customers to do is containerize the aspects of the application into pieces to create independent containers that can scale horizontally or vertically as needed to manage the load. In our example below, we could logically split this into four main components:

  1. The Portal itself where the customers interact
  2. An underwriting component that is deployed as a Mendix App Service
  3. A payment capture component that is deployed as a Mendix App Service
  4. An integration component that ties the Mendix Cloud to the back-end Policy Admin system

Why is this relevant? Well, think of a scenario that we all know is real: you have a large rush of users hitting the app all at once, and the user experience deteriorates and comes to a crawl because of long-running threads in the background and large computations that are stealing memory away from the user’s session. Sure, you could scale the entire application, but scaling an entire app just because one process is slowing performance is an egregious waste of resources.

Instead, we could build each component to horizontally scale on the Mendix Cloud as the resources are needed. That way, if the underwriting engine is taking more time than expected and needs extra horsepower, that component can scale up as needed without taking away from the user’s experience. Alternately, if an application has a lot of front end traffic, but not a lot of back end processing, the portal itself can scale to the right level and leave the payment, integration, and underwriting engines alone.

At the end of the day, the adoption of a low-code/high-productivity platform all comes back to time-to-value, cost savings, and the ability to be agile and nimble.”

The architecture also lends itself to an easier ability to remove and replace functionality down the road. If in a couple of years a customer decides they want to buy a brand new underwriting engine, you could replace just that one component without disrupting the entire app ecosystem, which is an incredibly valuable piece of flexibility for long-term success.

At the end of the day, the adoption of a low-code/high-productivity platform all comes back to time-to-value, cost savings, and the ability to be agile and nimble. Paired with the right architectural decisions, you can take low-code applications to the next level and keep the apps running as efficiently as possible.

  • Axel Brink

    If the customer decides to replace one of the components by something else, would you advise to replace the integration method (Mendix App services) too?