“Simplicity means the achievement of maximum effect with minimum means.” – Albert Einstein
In the book “Rework”, by Jason Fried, he boasts how his company’s software has far less features than its competitors. When I first read that, I found it odd, but it got me thinking.
There are many reasons why I think larger software packages or systems are “on their way out” in favor of a combination of smaller components, calculation services, and rules engines orchestrated together. The area I’d like to highlight here is related to “feature bloat” in those software larger packages.
Having been a Product Manager for various Life Insurance software products and reviewing many others, I would estimate that at least 50% of the overall functionality is not needed or used by the average customer (and up to 75% of the domain specific functionality). Over the past 20 years, one of the objectives for many insurers has been to consolidate legacy systems onto a single platform. As a result, the vendors were forced into supporting all different types of products and business processes. In order to be considered for such consolidation projects, vendors had to be able to support traditional product, universal life, annuities – fixed and variable. Then, when vendors needed to expand they either went into other markets (health, disability, LTC ) or geographies (Asia-Pac, Europe, South America). This caused their systems to grow more and more. In addition, Policy Administration wasn’t enough, companies had to expand their breadth of functionality to the front office, underwriting, claims, billing, and so on. In addition, over the years, they’ve chased whatever the cool feature of the day was or whatever some programmer developed over any given weekend.
To say the least, for these vendors to keep up in the features and functions race, the size of the systems grew immensely. This is not even taking into consideration the vendors who were acquired and their software was “merged into a larger enterprise”.
On the surface, it sounds like a good thing to have all of this functionality in one place. So, why is all of this a problem?
1. The systems were initially architected for a purpose that wasn’t different than accommodating everything it ended up accommodating. So each step of the way, more and more code was layered on top its foundation (similar to a foundation that wasn’t big enough for the building sitting on top of it)
2. Each of the major additions usually resulted in some re-architecture or software pattern changes that left the system with a lot of inconsistent ways of doing things.
3. In addition to all of that extra functionality that isn’t really needed, there’s always a ton of customization required to meet the customer’s real needs. As a result of navigating through all of this extra code and configuration (the aforementioned feature bloat), the cost, effort, and risk of doing the customization is extremely high. One could argue, it’s 50/50 as to whether it’s just easier to start from scratch.
4. The end result of all of the customization (configuration or code) wrapped around all of the code in this large system is very difficult and costly to maintain. So, you’re now stuck with dealing with this problem for the life of the software.
5. Performance usually suffers from having to perform more operations than necessary to support the business as well as a larger memory footprint. The answer is usually “add more servers” – which then blows up the infrastructure costs (both hardware and additional software licenses)
6. Tons of inconsistent code and inter-dependencies makes it difficult to use lower cost resources (off-shore or less experienced) and usually results in requiring expert developers or significant ties to the vendor.
7. The vendors have to keep up with their diverse customer group and spread their investments pretty thinly. In addition, the hottest new topics are where the majority of the investment dollars end up going – which leaves the average customer not getting a good return on the recurring license/maintenance they’re paying the vendor…which probably doesn’t matter because the combination of the software architecture and all of the customizations make real upgrades too difficult anyway.
By moving to a model with smaller components and services, companies can meet their immediate business needs with a lot less code, configuration hardware, and headaches. It allows them to have an evolutionary expansion plan where they’re adding only what they need. The net result is smaller implementations, lower cost maintenance and more technology choices over the long run.