I often speak about our strategy of building a suite of software components as microservices and being able to deploy them independently or for them to be able to co-exist together and interact with each other.
There are very few players in the Wealth Management software arena who are genuinely building to this architectural pattern.
Of late, I am finding many organisations getting on the band-wagon and speaking of component based architecture. But when you really dig beneath the surface it doesn’t take long to identify that Lipstick on a Pig does not maketh the Supermodel.
There are many benefits to implementing microservice architecture. These include
- Gaining massive agility and efficiency in amending, testing and deploying software updates;
- Enabling automated isolated testing both within microservices and for all interfaces around the microservices;
- Getting incredible gains in quality as a result of very defined boundaries of responsibility between microservices along with the increase ability to automate testing;
- Having the ability to pick and choose components and use the best of breed; including the ability to pull out and replace components if a better solution if available.
In order to implement a microservice architecture, there are some very key design principles that should be adopted and these are a few of my tips.
Have a Guiding Vision of the Future
Whilst software development can be an opportunistic enterprise, it is also great to have a vision and strategy of where you are heading. By taking a microservice view of your long-term development scope, it can really assist you to in prioritising the sequence of development and in defining the boundaries of all microservices in your eco-system. By preparing this future microservice map you can look at the scope at a high level and focus on the detail as you address each microservice in your development cycle.
Don’t be Afraid of Separate Database Schema
To truly segregate microservice components, it is important for your DB schema to be isolated and stand alone. To be a fully self-reliant component, it should not have a dependency on being a part of a greater schema. If a component requires access to other data it should be integrated using service layers or data pumps.
Sometimes this will feel foreign to not rely on DB level referential integrity and sometimes it will feel foreign to have some duplication and synchronisation of data. But don’t worry – correctly designed microservice applications will synchronise, reconcile and enforce data integrity.
You will also get massive performance benefits from distributed parallel processing.
Don’t Fall Into the Trap of Microservice Boundary Creep
It can be tough when times are stressful and deadlines tight to jam changes in quickly and without consideration to the boundary of responsibilities of your microservices.
Each microservice should be excellent at doing what it does. It is the software designer’s responsibility to make it stay that way. When a change comes through that takes a component away from its intended responsibility, it may be better to step back, re-assess and perhaps create a new microservice that interacts with the existing component.
Of course, sometimes there are grey zones and such a decision is not always easy. Importantly, though, it may cost slightly more and take slightly longer to implement it in an architecturally correct manner. The benefits of those decisions will pay dividends every day afterwards both to the development team and the clients who use the software.
Software Sales Reps who Say “We Have a Component Based Eco-System” – When to Call BullSh*t
Without wanting to detract from the credibility of some software sales people, it is good to drill in to claims of Component Based Eco-systems.
Here are a few things often said that do not constitute Microservice architecture…
- “We have a Separate Web Portal component from the core administration system component” – these are not microservices.
- “We have separate REST services for each component” – but behind the scenes its all just one big monolithic system – separate REST services for different functions are not microservices.
- “We have a microservice architecture and its bundled together to form a complete solution” – probably cannot be unbundled and therefore not microservices.
I personally always ask a few telling questions to really assess any such claims:
- Can I implement a single element of the total software scope that I would consider to be a discreet microservice independently and without having to take the rest of the solution?
- If I can implement a single microservice, can you provide integration documentation to allow me to integrate it to my existing systems?
- Does the database schema for the claimed microservice reside independently of the other microservices?
- Can you give me the automated test coverage percentage?
If you get a No to any of these questions, then its time to call it!
Summary
I am really excited by opportunities provided by microservice software architecture. Its what has allowed the likes of Amazon, Netflix, Google and others to achieve amazing agility and quality.
This mindset has not permeated into the Wealth Management sector and much of the software servicing our market is monolithic, inflexible and legacy.
Talk is cheap and as much as software suppliers are claiming this architectural pattern, in many cases it is simply incorrect.
When our industry catches up with others, we will find that a true Microservice architecture will transform this space. It will allow the best solution to be selected for each process and each task in the wealth management scope. Microservices will be able to be selected from disparate vendors who will specialise in dedicated areas of functionality in which they excel or they will be built independently and integrated by the Wealth Management firms themselves. Wealth Management firms will be able to replace components easily and at will and without the risks of huge migration events. Wealth Management firms will not have to put up with poor quality products or services from technology companies.
This architecture is a game changer. It will allow small, agile tech companies to upset the status quo and will ultimately lead to greater efficiency, quality and costs to the end consumer.
This is the basis on which FinoComp has been found and its principles are close to our heart.
