How Configurable is Your Insurance Software? – Part 1
Sometime around the start of the 21st century leading market research/advisory companies – and many of the carriers who seek their opinions – started to become particularly interested in the “configurability” of a vendor’s insurance software offering.
A recent article suggests that, “94% of insurers require robust configuration capabilities, “and, “dynamic configuration capabilities have now become table stakes for core system replacement.”1
Insurance CIOs know older technology is too expensive in work effort and cost to support – it’s riddled with years of “customization”, –and they believe “configuration” enables carriers to do it the right way.
However, many Insurance CIOs learned the hard way that “configuration”, as defined variously by competing vendors, is no silver bullet.
Some technology and approaches are superior to others, but a proper evaluation needs to explore details and nuance. Asking binary questions like, “Is it configurable?”, when configuration can mean so many different things, isn’t illuminating. Legacy systems strength is production tested proof of functionality and the very risky cost proposition to convert away from them. Of course, they have major problems. When software is in production for many years, it has a complicated history of rules, data switches, different types of products, newly introduced products and product features that didn’t quite fit. Most of the people who understood and/or wrote the code have moved on or retired. Even if optimal software design principles were followed and everything was documented fully, which rarely occurs, the result is still quite a tangle of business logic.
Can a better configuration architecture mitigate this mess?
The first point to make is legacy systems have always had something – in fact it’s a very central part of their logical tangle – which they call configuration.
What’s this old configuration then?
Here are some definitions of enterprise software configuration yielded by a quick Google search:
“Customization is : Change of the code/logic of the product. Configuration is : “Tweaking” of product parameters to achieve desired functionality.2”
“When vendors describe their systems as configurable, they mean the system is essentially complete and only needs a few fine tunes to fit a client’s specific needs. Generally the fine tunes are specific tweaks in the system allowing some personalization to specific behaviors or features – a vendor provided menu of areas that can be configured, so to speak.3”
These definitions sound very much like what the old mainframe systems called configuration. The programming/algorithm code is not configurable, but differences in data parameters (e.g. plan file, rates, employee class rules) can alter behavior in the system. For example, different “plans” might calculate premiums in a different way and plan file parameter(s) can control which premium calculation logic to execute. This “data configuration” can be manipulated by a business analyst with no programming experience – and the customer will not always have to pay the software vendor to build out the differences between the carrier’s various products. When a new product is introduced, sometimes there is no need to change the programming code base.
Over time, knowing what all these parameters control and how to update them properly becomes quite a highly skilled, and difficult, job to fill. To fill the role, one needs a very solid understanding of business products and processes and how these various parameters update behavior in a quite complex enterprise application.
When a new feature is required or a product not supported by the legacy system, a modification to the base programming code is required and often new configuration parameters are introduced. If these changes are made in a customer specific branch of code, this is called “customization”. This type of customization makes new software releases difficult to install, and in almost all instances the customized code base becomes a permanently divergent branch.
The large improvement with data configuration in the insurance industry is not only that changes can be made by the carrier without the pitfalls of customization, it was that it empowered the business user to configure some of the business logic. The notion of the business user being able to have control over the functioning of vendor policy administration software has obvious appeal because the oldest problem in enterprise business software applications is a divide between business experts and technicians.
What’s this new configuration then?
In the early days, programmers had to implement 100% of the business logic. Not surprisingly some of the most comprehensive insurance product experts are Cobol programmers.
Product designers and actuaries are usually not trained programmers. These days, younger4 programmers want as little as possible to do with “the business”. Over time vendor policy administration applications began to expose more than data parameters to “business configurers”.
Some applications exposed a selection of formulae, other applications exposed selected “rules” that business analysts could configure. These rules would usually require access to certain stored data elements and sometimes the ability to execute simple logical expressions. Usually you didn’t have to type IF, AND, OR – but sometimes you could pick the logical operators from a combo box instead!
There are benefits to exposed formulae – for example to handle premium computation or commutation math.
There can be benefits to using a rules engine (another ambiguous concept) or tree decision dialog or business process management engine to attack certain problems – for example underwriting decisions.
More recently introduced No Code, Low Code systems are very good at building certain web applications quickly and with high code standards. In fact, this movement can be thought of as a natural extension of what certain “DIY” or “configure everything” vendors have been doing in the insurance space.
After attempts to create the required flexibility with various configuration wizard dialogs and revising them well beyond their original intent, limitations became evident.
If you want the business configurer to be able to build large portions of insurance enterprise software applications – work that was previously just called business programming – you need something akin to a programming language. You don’t just have one coverage, so you need a loop. It’s no good if you can’t reuse repetitive logic, so you need something like a function.
Several policy administration vendors developed proprietary scripting languages that can do much of what traditional programming languages can do. These proprietary scripting languages became the new configuration. IT programmers focus on maintaining business frameworks, tools and integration5. The business configurer can now do everything else! But hold on, should we still call this configuration? And if product parameter configuration became a very difficult job to fill, how easy would it be to find business configurers who can wield scripting languages? And if “configuration parameters” over many years and many products become a very difficult tangle to maintain, what will this new “configuration code” look like after many years? Are these insurance administration software vendors building tools to build administration systems or are they building administration systems?
There’s a lot of business code
It’s instructive to analyze what percent of a legacy enterprise insurance application (it can be Java, COBOL, or any other commercial programming language or proprietary scripting language) is business vs. technical. From our experience, we can safely say over 50% of a legacy code base is business in nature. We’ve worked with enterprise applications with well over a million lines of code. These legacy code bases might be refactored down significantly, but the amount of business code – though not technically complicated – is far from a trivial part of the application.
It’s understandable to wrest control of the business code away from the technical team, but there are tradeoffs. On one side, we have a group of business experts who know the product rules and typically a smaller group who know the calculations in detail. On the other, we have programmers who usually do not understand the business very well, but they have been trained in modern methods to write reusable, scalable, performant code. Programmers use modern programming languages with all the latest tools to support their development, debugging, and migration of their code. Programmers might implement the business code if perfectly specified. But, unfortunately, 100% foolproof step by step requirement documents are a myth – even if bad requirement documents have often been blamed for project failures.
What’s better spaghetti code or SpaghettiOs® configuration?
The scripting languages that we’ve researched, supported by the software vendor with a significant R&D budget, have syntax which is not appreciably easier to understand than traditional programming languages. IT programmers today must understand object-oriented principles, dependency injection, aspect-oriented programming, etc. that require years of practice and study. But does good business rule code require more than programming techniques that have been around since the dawn of computer programming?
First question: Is wielding a new scripting language (called a configuration language) markedly different to training business persons to write code in an existing programming language? Is it easier for a business person to work with these scripting languages than existing programming languages? Are these scripting languages better performant and more reliable than languages such as Java, C#, Ruby, and Python?
Some policy administration software vendors developed “drag and drop” scripting language generators to insulate business configurers from their own scripting languages. These tools create their own set of problems – vendors need to enhance both their proprietary scripting language and their proprietary generator tool as rule processing logic becomes more complex. And our first question still stands – do business configurers who use these “drag and drop” configuration tools require training in best practice programming technique like IT programmers?
CalcFocus’ response to the first question is that new business configuration is not appreciably different from traditional programming code – that business configuration is essentially the same as writing customized code. It is therefore legitimate to ask: are the teams who wield this powerful configuration trained programmers? Are they employing best practices? Are versioning and SDLC practices up to date?
Second question: Do these configuration scripting languages address the problems they were intended to solve? Have we solved the problem with customization?
CalcFocus’ response to the second question is that, ironically, the customization problem has worsened. Insurance carriers who license these new configuration solutions “code” large parts of their business processing logic – every carrier creates their own customized code base. The enterprise software vendors who license these new configuration solutions became tool companies. They can release updates to their tool and claim there is no customization there. That’s because they are not updating carrier customized configurations.
Battling implementation contractors may offer their own customized configurations with the enterprise software in an attempt to provide a more complete and meaningful starting point for customers who employ them. These offers appear better than each carrier having to completely reinvent the wheel. However, the incremental business configuration performed by the customer or contractor falls into the same trap. Revisions to the originally delivered customized configurations require complex retrofits for every customer. And, once again, every customer is left with their own customized “business code base”.
Quality Business Code
Software should be judged by best principles in software design, not just in configurability. This contention does not require proof that enterprise software adheres to a list of the latest technology and patterns. Our position is that all enterprise software should be evaluated against simple Computer Science 101 principles.
We like Kent Beck’s four rules (in strict priority order of importance)6:
- Passes the tests – Making testing paramount in software development is the insurance that software processes what was intended
- Reveals intention – Code should be readable and easy to understand
- No duplication – Don’t repeat yourself (“DRY”)
- Fewest elements – Remove code that is not used and do not anticipate future need
The devils in enterprise business code are in the size and the details. If you merely say that you’re in the cloud, you’re highly configurable, and you will deliver ahead of schedule, you should be asked to prove it. We question whether most modern “configurable” systems being wielded by non-programmers come close to passing the four simple rules listed above.
Computability was the real giant leap in enterprise insurance administration. And, we contend that a well-defined configurability strategy can significantly reduce implementation time, shift significant work from programmers to the business experts, and increase functionality flexibility. Our discussion has focused on solvable problems we observe with both “old configuration” and “new configuration” strategies available today. In Part II of this discussion, we declare CalcFocus’ configurability strategy, and we document how that strategy addresses the themes discussed herein. Regardless of configuration strategy, the most important question should not be how configurable you are or what language or framework you’re using, but whether your business code is of high quality: whether other people can understand it, whether it’s easy to extend and maintain, and whether it is easy it is to deliver.
Part two will show how CalcFocus decided to address these concerns – with pragmatism and quality being the two driving forces behind our design.