With every Insbridge implementation, we always have to wrestle with determining when elements should be built at a Universal, Global, or Local level. Over the years at Second Phase, we’ve come up with best practices that we try to adhere to when designing and building rating programs for customers. Here are some of our best practices and hopefully it will give you some guidance when confronted with this decision.
What are Universal, Global, and Local elements?
When talking about Universals, Globals, and Locals, we’re really talking about scope and how elements are used across the system. Insbridge allows you to define variables and algorithms at varying levels of scope to make reusability and maintenance easier. Instead of creating the same piece of logic multiple times, you might be able to create it once and reference it across all of the rating programs that use it.
Universal elements are a relatively new concept to Insbridge. As the name implies, Universals are at the highest level of scope. Universals are variables and algorithms that can be shared across multiple products in Insbridge. From a multi-line rating perspective, you might have multiple products defined within a single project. You would create variables and algorithms at a Universal level if you want to use those elements across both Personal Auto and Home products, for instance.
Global elements are the next level down from Universals. Globals are shared across multiple programs within a single product. You may have 50 state-specific programs within your Personal Auto product. Variables or algorithms created at a Global level would be available for use within any of the 50 state programs. Global elements created within the Auto product would not be available for any other product.
Local elements are at the lowest level and only available within a single program. Continuing with the Auto theme and 50 state-specific programs, Local variables or algorithms defined in the Texas program would only be available in Texas. No other state or program would be able to reference them. You also can’t use Local variables in Global or Universal algorithms. However, you can use Global or Universal variables in Local algorithms.
So where should I define my variables and algorithms?
If you have visibility into how you rate across all products and states, this question becomes pretty easy – you’ll know exactly what logic is and isn’t shared. More often than not though, you’re only implementing a single product or maybe even a single state at a time within Insbridge. Here are the different options to consider based on the type of element you’re defining:
Field Variables (or inputs) can only be created at a Universal level. No decision to make here!
Table Variables, Calculated Variables, and Algorithms can be created at a Universal, Global, or Local level. Any elements that are known to be shared across products should be created at the Universal level. For all other elements, Second Phase recommends creating them at the Global level unless there are specific use cases or maintenance strategies that call for them to be at the Local level.
We recently had a customer that implemented only 1 countrywide program per product. For this scenario, the best option was to create all of these elements at a Global level, despite only 1 program using them. Why was that the best option? It provides the most flexibility for any future changes. If the customer wants to deviate from countrywide rating and introduce state-specific programs, they would instantly have all of the Global elements at their disposal without duplicating any logic. Any elements that are unique to one of the state-specific programs could be created at the Local or Global level and could be created either from scratch or by copying the Global version. If everything was initially defined as Local to the countrywide program, you could certainly copy the countrywide program and use that as the base for any state-specific changes. The problem with this approach is you could have multiple copies of the same logic to maintain. A simple change to 1 table or algorithm for all states quickly turns into a larger-than-expected effort.
A second benefit to having the elements at the Global level is that larger programs can be split into smaller programs for faster unit testing and debugging purposes. Let’s say you have a program with hundreds of algorithms but you only want to test one or two. You can create a new program, add the one or two Global algorithms to your sequence, and test them out. This is a less common use case, but it can be extremely valuable for large, complex programs with large debug reports.
Result Variables can be created at a Universal or Global level. At Second Phase, we typically create Result Variables exclusively at a Universal level. The main reason for this is to maintain the most flexibility when implementing rating across multiple products. The mapping of data across products becomes a little more complex when using Global Result Variables. We also haven’t come across a scenario where you would want to introduce a mix of Global and Universal Result Variables.
Conclusion
Understanding how Universal, Global, and Local elements work in Insbridge can make maintenance of your rating programs much easier. At Second Phase, we’ve leaned towards limiting the use of Locals to those elements that are truly unique to a program and will likely stay unique. Everything else should be Global or Universal, depending on the type of element and their use across your lines of business.
It’s almost impossible to predict change, but there are ways to set yourself up to handle change as efficiently as possible. Hopefully we’ve provided some food for thought when you’re designing and developing your Insbridge rating programs. If you have any questions or thoughts on this topic, feel free to leave a response below!