An Old Cliché: Less is More

“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.

Tom Famularo

FAST

3 Responses to “An Old Cliché: Less is More”

  1. Jeff Simpson says:

    I agree with Tom. One of the other things I would point out is that vendors need to also react to technology and architecture trends (example browsers in 2000, rules engines in 2005, SOA today). It is a major investment to properly re-architect larger systems to adequately meet these trends, so vendors either don’t do it or just end up “wrapping” their existing code – net result is “check the box” for the latest trend, but really doesn’t meet the spirit of it and it makes it that much more difficult to manage moving forward (compounding the problem Tom refers to).

  2. John,
    Tom paints a very relaistic picture of how we got to where we are with life policy admin systems. Many of the domain experts for earlier systems have moved on, retired or died. Off-shore vendors are recruited to maintain the old with less domain knowledge and limited skills in vintage technologies. Meanwhile the cost to maintain these beasts is “dead money” and contributes nothing to business growth. The vendor challenge as I view it, is to help the customers sort through a strategy of legacy systems versus new product roll-out. Many buyers attempt a strategy of converting old systems to new technology platforms only to learn the economics won’t work. Also, the current IT and business folks haven’t got the skills necessary to implement the new technologies (e.g rules engines). While many carriers are learning their dilema, trying to help them think through a strategy to address old and new is critical.

  3. Garima Jain says:

    This is so real and so well consolidated.

    Also, more often than not, vendors do not conduct regular performance tests during the course of customization.

    When the performance deterioration becomes visible, this becomes another area of development and hence another cost addition for the customer.

    The focus of the product development group should be to build a strong basic design keeping the basic business logic in consideration.

    Keeping a robust yet basic design will help making customizations without compromising on stability and keeping costs iin control.