Monolithic
large, powerful, difficult to work with, and resistant to change.
We all sit with this term in the company and the past – the monolithic past is coming to haunt us. So we all fear the big rewrite in the sky.
You probably spent millions on your current monolithic system. The ins-and-outs of business, including business rules and procedures, is contained within it. While this system might currently be working for you, you know that the world is moving away from monolithic systems and towards microservices. The costs for maintaining and hosting monolithic systems are increasing exponentially. Moving your business onto a microservice architecture will save you a lot of money at the end of the day.
Killing the monster
Changing from a monolithic system to microservices will require a waterfall approach. Development of the old, monolithic system will have to cease on the behemoth and the systematic, sequential development on the microservices architecture will have to start.
Developing both systems at the same time is painful. Your A-Team is busy developing a microservice architecture while Team B are still maintaining and supporting the monolithic system (all the while adding new fixes and features to accommodate everyday business). This Team A will be trying to move into a new direction while still operating on old features, causing two separate and out of sync systems. Trying to get everybody on the same version causes an endless loop of agile hell. Nobody wants this!
Buttering the toast on both sides
We all want the most optimum approach to problem-solving. A lot of companies do not yet know that the development world has started to find solutions in new ways. It is no longer simply down to either a waterfall approach or to an agile approach. Problem-solving has morphed into something new: ‘AGIFALL’. Agifall means both methodologies will be applied to different aspects of your system to ensure that consistency is maintained between all teams. Agifall might seem intimidating and scary but there are tools to help with its implementation. One such tool is Revier, an intelligent process automation system.
No, it’s not nonsense
At first glance, agifall might seem like a foreign concept and one that is difficult to manage. If you want to move your software away from a monolithic architecture, however, you need to shift your perspective away from a monolithic state. You need to break up the tasks at hand into chunks, starting with the big blocks and moving steadily down to the smaller blocks.
Your monolithic system might consist of, for example, three modules, like Customer, Loans, Accounts. And each of these modules will respectively contain many functions and procedures. If you view the management of these modules (and their components) globally, you might feel like running away and hiding. But being intimidated is merely a sign of monolithic thinking patterns and habits.
I’m convinced! How do I change?
Change comes from within and through hours of meditation, Zen, and being one with the universe you rise a micro thinking butterfly. Hogwash! As stated in the previous section, simply start with the big blocks first. The biggest block being business rules. Let’s remove business rules (our first waterfall effect) and let’s map out our business rules in Revier and expose all the actions needed for these business rules to complete. Doing so means we give the power of business rules back to the BA’s, and liberate developers to actually implement components. See how good a “Microversic Zen” restructuring can be?
Next, set up your front-end flows in Revier. This will free up that front-end interface from business rules. After this, set up your lookups in Revier so that all your front-end data reflects your system (like lists of journals or loan products). Why do this? Because your front-end is interchangeable (meaning you can throw away your front-end every six months in order to stay fresh and up-to-date). And because you can start managing what your client experiences though process-modelling. This means changes can happen instantaneously without you having to develop and deploy new code – of course praying all the while that the consistency of your code has been maintained by the new junior developers! (The caveat here is that testing should be looked at as a gravity of sorts: you can try to bend the rules but the laws of nature remain).
When all of this is done, start using words like ‘namaste’ and walk around the office in peach-coloured robes and a shaved head for you are approaching enlightenment.
Am I done?
Nope. Now that you have exposed that monolithic system and found it is actually a whole bunch of bunnies all snuggled up next to each other, you can start waterfalling your way and remove those bunnies one by one. Until you have a microservice. Your action path in the process model will have been moved into its own little containerized world of awesome – ensuring maintenance and support stops on a process in the monolithic system while moving to the microservice.
Life is good
Yes it is, the monolithic system has been morphed in a smaller more manageable and cheaper system. One in which one feature-change does not break another feature-change. One in which change of business is not a costly procedure and the people in your company really do look like those corporate pictures we all display on our websites to show how happy and productive the people in the company are.