Micro-frontends Architecture Decision Matrix
What is a decision matrix?
A decision matrix takes typically the form of a table, where we can list all the different options we may be evaluating at the time of designing an implementing a system.
How exactly is a decision matrix useful?
For large systems that would require decoupling or decomposition to become more manageable and maintainable, as I mentioned already is the main objective of any micro-* architecture, we probably have multiple stakeholders, teams, and many problems to solve.
Putting together a decision matrix is a way to centralize the evaluation of the multiple solutions, and score them in a way that we can compare the results, and see the pros and cons of every one of the options discussed.
There are different ways to compare solutions. We can define a set of requirements or constraints and then use scores or weight, for each one of them, for each technology.
| Criteria | Current | Modular | Decoupled |
|---|---|---|---|
| (Sys) Non-functional requirements | |||
| High Availability | N | N | N |
| Fault tolerance | N | N | N |
| Reliability | N | N | N |
| Scalability | N | N | N |
| Modularity | N | N | N |
| Reusability | N | N | N |
| Flexibility | N | N | N |
| Portability | N | N | N |
| Interoperability | N | N | N |
| Extensibility | N | N | N |
| Level of Encapsulation | N | N | N |
| Level of Decoupling | N | N | N |
| Testability | N | N | N |
| Time | N | N | N |
| Cost | N | N | N |
| Risk | N | N | N |
| Reqs. Framework/Library | |||
| Learning Path | |||
| General learning curve | N | N | N |
| Quality of documentation | N | N | N |
| Quality of support | N | N | N |
| Quality of community | N | N | N |
| Developer experience | |||
| Code Maturity | N | N | N |
| Quality of dev tools | N | N | N |
| Migration path/compatibility | N | N | N |
| Team independence | N | N | N |
| Performance | N | N | N |
| Implementation | |||
| Complexity | N | N | N |
| XYZ feature support | N | N | N |
| Usability | |||
| Performance | N | N | N |
| Accessibility | N | N | N |
| SEO | N | N | N |
| Total Score | TS1 | TS2 | TS3 |
When is a decision matrix used?
A decision matrix is typically used by architects and developers during the discovery phase of a new or migration project.
You can learn more about becoming an architect and the different processes an architect participates of, in my post From developer to (solutions) architect. A simple guide.
I used three random options like ‘Current or Monolith’, ‘Modular’ or ‘Decoupled’, but you can use whatever amount and type of options you’re evaluating, as long as they are of the same type: like frameworks, libraries, patterns, etc.
Some of the criteria I use in the example are more fit for architecture decisions. And some are more fit to compare technologies such as frameworks.
Types of requirement
In the matrix above I have made a distinction between criteria that map to system-wide constraints, at an architecture level, and critertia that may map to technical stack decisions.
For example, a business requirement could be that we need to REDUCE THE TIME TO MARKET FOR CERTAIN FEATURES OF THE APPLICATION, LIKE THE E-COMMERCE CAPABILITY. If we need to make sure that the e-commerce has a faster iteration cycle, we may want to consider decoupling it.
Non-functional requirements
As we can deduce from the matrix above, non-functional requirements apply to the whole system and are technology agnostic. They are tightly bound (kind of monolithic -pun intended-) to the business requirements.
For example, a non-functional requirement is to have GLOBAL AVAILABILTY.
Functional requirements
Functional requirements are those that define how the system will behave. Following the example I set before for a non-functional requirement, we can say that the functional requirement is to have a global e-commerce capability. This is when we start thinking about the pieces of the system, that will make sure that the e-commerce functionality is deployed closer to the user, and that’s precisely when we make more technical decisions, like: WE WILL DECOUPLE THE E-COMMERCE FUNCTIONALITY, AND DEPLOY THE BUSINESS LOGIC AS SERVERLESS FUNCTIONS AT THE EDGE OF THE NETWORK.
Comparing technologies
When we understand the ‘why’, which means we have the business requirements defined, and the ‘what’, which means we have a clear idea of the functional requirements in our roadmap, we can start thinking about the ‘how’, or how we are going to make all this possible.
I am a great fan of making a lot of questions before making technical stack decisions. You can put down everything you want to expolore and evaluate, in your matrix.
| Criteria | Framework A | Framework B | Framework C |
|---|---|---|---|
| Capabilities/support | |||
| Server Side Rendering | N | N | N |
| Island Architecture | N | N | N |
| Integration with D (XYZ library) | N | N | N |
| Integration with E (XYZ database) | N | N | N |
And you can also use a matrix to compare the level of maturity of the frameworks community, ecosystem, documentation, etc.
As you may have guessed, when we’re evaluating potential solutions for composable architectures, we may need to create a matrix for non-functional requirements for each infrastructure component, instead of a system-wide one.