On Reference Implementations
This is a personal opinion post and a mild rant.
Introduction and Context
I have been working for the past few weeks on understanding the microsoft provided reference implementations for a microservice architecture. And I have been thinking about why I am doing it.
There have been a few times that I have been part of a project launched with a kick off meeting and all that jazz.
However, the first task on the board will usually be "Integrate Logging framework" or some variant of it like "Add Repository base".
This is when I feel that the project is in trouble already.
The business is expecting their requirements to be produced in software form while the developers are starting with cross cutting plumbing code.
Maybe this is not your experience, but this has happened to me a few times.
This is why I think technology reference implementations are a good idea.
Application architects should have these on their shelf and collect these like railway model enthusiasts collect model trains.
Reference Implementation Shelf
The great thing about open-source is that it is a boon for the lazies like me.
The team at Microsoft have had intense discussions on how to implement a microservice archtitecture.
I just want to use what they have already done. Pick it up from the shelf.
Delete Delete Delete
Also, Why write code from scratch when you can copy?
Deleting code is an entirely different beast.
Your business will have requirements where you do not need everything that is on offer in the reference implementation.
Deleting is easier and also a very pleasurable activity. Just make sure things are still working after deletion.
Focus on the business
Application architects can focus on modeling the business domain or the business workflow.
From day one, you and your team are working on business problems.
Everyone is focused on writing software based on the requirements.
Not Fun
It is hard work collecting and learning all these reference implementations.
Take a look at the microsoft provided reference implementations or the awesome-angular list.
There are so many ways you can create one angular application with different styles and patterns.
There are so many ways to design a microservice system. Even for monoliths there are so many different patterns and practices.
The application architects must know all the options and when and why they are useful and converge on one based on the business requirements.
It is their responsibility and it is also a lot of study.
Preferably, this is a constant activity that is done everyday.
Keep adding things on the shelf and be ready.
For any new project, read the requirements and check the shelf to see which one makes sense and make the changes accordingly.
A new project is no time to decide what and how we should implement Observability.
It should be there on the shelf.
Not Proof of Concept
The implementations you add on the shelf are not proof of concepts.
They are not throw away code.
They have to be real, ready to go live when called upon.
These may start as pocs when you want to understand or experiment with a new framework or technology.
However, once that is done, you must have a real working implementation which you can plug into your application.
Treat this like the application architect’s answer to low-code platforms.
Low-code platforms help citizens developers create an app for their specific requirements quickly
The Reference Implementation Shelf helps application architects get started on business workflows and business problems quickly.
Organization Responsibility
Organizations have a responsibility here too.
Organizations, especially large ones, usually have a hundred applications live.
Application architects should be allowed to explore these applications, document them and add their architecture and implementations to the shelf.
A study like this will help application architects understand the application standards of the organization and compare them with the latest best practices.
While the Microsoft ones are generic solutions, each organization can have its own shelf of reference implementations that is specific to them.
A Center of Excellence or Study?
A Center of Excellence or something similar can be created within the organization.
The documents and implementations they produce can be used across product teams in your organization.
This will help them move faster and produce higher quality.
Make the time
Organizations must also provide their application architects the time to do this.
Application architects should be encouraged and given time to investigate and experiment.
20% time perhaps can be enough or something like Architecture Fridays can help.
In Summary
To end this minor rant, all the above just came out of my head and I have no documented proof that this will work or if this works or if there are already organizations that are mature enough that do this or if there are organizations that have a system that is better than this idea. Feel free to drop me a line. Live and Learn, as they say.