Mini service architectures break monolithic applications into services at a functional level whereas micro services break that down to individual threads of business logic.
Software leaders recognise the need to break the monolith; over 60% of complex software solutions as typified by most core banking and payments systems are potentially suitable for decomposed architecture.
Faced with growing legacy challenges – as cited by UK regulators – many firms have begun to investigate the potential for mini or micro services solutions. But the question of where to draw the line looms large.
Modernising the core is a critical challenge for financials – and mini service architectures present a quick path to value. The head of architecture at a US insurance major concurs: “We don’t want to build something likely to have a modern legacy.” By establishing effective, reusable patterns, mini services architectures can be built that are understandable, reusable and therefore reduce risk.
Micro services – segmenting code into individual stateless service threads – may deliver strong competitive advantage when deployed effectively, but require substantial investments to be fully successful. As the head of system reliability engineering at an emerging US exchange puts it, “If properly defined, micro services deliver close coupling to business logic and increased reliability.”
Mini services architectures are more achievable and quicker to deliver than micro services; this lighter approach to decomposition offers many of the benefits financial firms are seeking.
So is this the end for the monolith? Not according to the head of architecture at a technology enabled European exchange: “Developing proofs of concept is best done monolithically, enabling the business, product owners and DevOps leaders to create the right architecture for minimum viable product.”
Aside from greenfield opportunities like these, software leaders at financial firms have a clear choice in modernising their legacy application portfolio. To micro or to mini is indeed the question – and the answer lies in how effective firms measure overall software performance and suitability for decomposed architecture.
Software leaders must decide which architectural style will have the greatest impact on overall software performance against investment required. Measuring app suitability – evaluating required release frequency, effort to remediate, interconnectivity and reliability – enable firms to select the most appropriate initial style. We recommend firms regularly reassess as their app portfolio evolves.
To learn more about how QA Vector® Research can assist your firm, contact our team to arrange a bespoke evaluation.
