Microkernel architectural pattern and applicability for business applications

Question

We are in the business of building customizable web applications. We have the core team that provides what we call as the core platform (provides services like security, billing etc.) on top of which core products are built. These core products are industry specific solutions like telecom, utility etc. These core products are later used by other teams to build customer specific solutions in a particular industry.

Until now we have a loose separation between platform and core product. The customer specific solutions are built by customizing 20-40% of the core offering and re-packaging. The core-platform and core products are released together as monolithic apps (ear).

I am looking to improve the current situation so that there is a cleaner separation on these 3. This allows us to have evolve each of these 3 separately etc.

I've read through the Microkernel architecture and kind of felt that I can take and apply the principles in my context. But most of my reading about this pattern is always in the context of operating systems or application servers etc. I am wondering if there are any examples on how that pattern was used for architecting business applications. Or you could provide some insight on how to apply that pattern to my problem.

Answer 1

This is a "Module" pattern, as well as a "People" pattern - your code may look different as well but that's not where the meat of the difference lies. I think you understand what the pattern is given the situation you're trying to apply it to.

Actually applying it would look like the following:

Assume the Core Platform's the lowest layer in your "stack".

In code, these three layers would be in different packages - which you probably already have. Make certain that no layer below makes any specific reference to or has a dependence on something in the layers above. That will protect your Platform from complexities of your Products and Customer specific stuff. Create some series of Facades and other simple abstractions between any layer and the ones below it. For example, my Facade to a database Module in the Core Platform may consist of a Factory that will generate an instance that adheres to a "DataSource" interface, as opposed to someone on your Core Product team directly reaching into the Core Platform (not through the Facade) and concretely instantiating a SQLDatabaseSource instead. This will protect your Product and Customer layers from changes in the implementation of your Platform.

Secondly, the teams must be structured to communicate effectively in a manner conceptually matching this "downstream" approach. The Platform team must show interest in what features the Product teams need the most, cleanly document how to use them, and cleanly design them so that the Customer team doesn't have to tightly couple their implementation to it. They also have to make it clear the ways in which they are unwilling or unable to accomodate the teams downstream. Perhaps they will have the slowest cycles, as opposed to your Customer team, whose lower number of stakeholders (1 customer company as opposed to the 100 your platform team may ultimately serve) allows for faster iterations.

In light of all this, I think you may want to re-think the name "Core Products", because it's just confusing that you're building "Core" products on top of "Core" platform. Core means inside, so only one can be that.

Cant believe they took this off stackoverflow