Skip to main content

Extensibility in your applications

Extensibility is one of the possible architecture qualities that you can strive for in your software architecture.

Wikipedia gives us the following definition for extensibility:

Extensibility is a software engineering and systems design principle that provides for future growth. An extensible system is one whose internal structure and dataflow are minimally or not affected by new or modified functionality, for example recompiling or changing the original source code might be unnecessary when changing a system’s behavior, either by the creator or other programmers.

I would have asked ChatGPT for a definition but it was overloaded at the moment of writing this post.

A typical (but certainly not the only) way to achieve this is through a plug-in architecture.

If you want a way on how to do this in .NET, you can have a look here:

Create a .NET Core application with plugins - .NET | Microsoft Learn

But it is not about the technical implementation details I want to talk. Instead I want to focus on the design heuristics when building an extensible architecture.

I think we all agree that extensibility is a nice quality to have in your architecture but the way you design it can have a large impact on the evolvability of your solution.

My main advice here is the following:

Isolate your extensions(plugins?) from the core system.

Maybe this sounds obvious but let me explain this further. It is important that your core system can evolve without requiring all your plugins to evolve as well. If you have a large ecosystem where a lot of extensions are created, you don’t want the authors of these extensions to have to upgrade to keep supporting your core solution.

I’ll give you an example. Maybe it is not a completely correct one but it is how I perceive it from the outside. I’ll use SAP as an example. The claim has always been that SAP was very extensible. Through ABAP you could extend almost every part of the ERP solution. It gave you a lot of flexibility. But this flexibility came with a cost, it was very expensive to upgrade SAP.

A friend of mine always worked as an SAP consultant and as long as I know him the only thing he did was working on big migration projects to move from one SAP version to the next. It was and maybe even is today a big cash cow.

With the move to the cloud and S/4HANA they moved to a ‘clean core’ approach where the extensions strictly separate from the core application and extensions can only interact through well defined upgrade-stable interfaces. This allows SAP to evolve their core product without breaking the extensions created by customers and other suppliers.

I find this approach similar to the way that Microsoft took with Dynamics where they expose data and functionality through the DataVerse and allow you to build extensions using Power Platform.

Popular posts from this blog

XUnit - Assert.Collection

A colleague asked me to take a look at the following code inside a test project: My first guess would be that this code checks that the specified condition(the contains) is true for every element in the list.  This turns out not to be the case. The Assert.Collection expects a list of element inspectors, one for every item in the list. The first inspector is used to check the first item, the second inspector the second item and so on. The number of inspectors should match the number of elements in the list. An example: The behavior I expected could be achieved using the Assert.All method:

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Angular --deploy-url and --base-href

As long you are running your Angular application at a root URL (e.g. ) you don’t need to worry that much about either the ‘--deploy-url’ and ‘--base-href’ parameters. But once you want to serve your Angular application from a server sub folder(e.g. ) these parameters become important. --base-href If you deploy your Angular app to a subfolder, the ‘--base-href’ is important to generate the correct routes. This parameter will update the <base href> tag inside the index.html. For example, if the index.html is on the server at /angularapp/index.html , the base href should be set to <base href="/angularapp/"> . More information: --deploy-url A second parameter that is important is ‘--deploy-url’. This parameter will update the generated url’s for our assets(scripts, css) inside the index.html. To make your assets available at /angularapp/, the deploy url should