The Challenge of Configurability

(Note: This has been cross-posted to the Guidewire Development Blog).

Every kind of software development has its own unique set of challenges: embedded software, desktop software, games, operating systems, and web applications all have their own difficulties and problems. Enterprise software is no different, and one of the main challenges there is making that software configurable.

Of course, not all enterprise software vendors try to do this; some of them go the route of essentially requiring you to fit your business to how their software works, while others basically bring in a small army of consultants to essentially do a complete custom build based loosely on some pre-existing components that they have. One of the things that sets Guidewire apart from our competitors in the insurance software market, and (I’d argue) from most enterprise vendors in general, is the level of configurability that we provide with our software. And after having worked on configurable, enterprise systems for close to six years now, I can be fully confident in telling you that the reason no one else does it to the degree that we do is that it’s really, really hard.

Why is it so hard? For one, it turns everything into a meta-problem. Think about the problem of assigning claims to users. If you were just building out a system for in-house use, you’d probably just hardcode the logic in Java (or whatever language you’re using): assign glass claims to the group with this name, injury claims to that group, etc. In our system, that’s implemented via a ruleset, where we call out to business rules that are set up to do that assignment. That means we have to think about where those callouts should occur, what the API should be for them, and what sorts of methods the person writing the business rules will need available: maybe they need to do round-robin assignments, maybe they need to do location-based assignments, or maybe they want to balance assignments based on adjuster workloads. Instead of coming across those problems and solving them as we need to, we have to think about what the API should be up front and try to provide the right amount of flexibility for our customers.

Programming that way is just harder than normal code because you’re working at another level of abstraction; instead of writing an expression like 1 + 1 in the language, you’re writing the language itself (numeric literals, additive expressions, etc.). The code for implementing a language is rarely straightforward when compared to the code written in that language.

There are other challenges too. We need good tools to ease the configuration work and help discover problems. Testing an entire framework is harder than testing code in that framework, both because of the combinatorial explosion of configuration options and because the surface area of our API is much larger than what our default application configuration actually uses. Upgrade is another challenge we always have to think about, as we don’t always know what sorts of configurations customers have performed and have to be careful to keep those configurations working as much as we can and/or to provide upgrade tools when we change the frameworks. Getting feedback from customers is more difficult than it otherwise would be, since customers have to configure the application a non-trivial amount before they can realistically use the features we want feedback on, meaning they’re less likely to give us that feedback and that it takes longer to get it. And lastly, there’s constant pressure to release early versions of the software so that customer projects can get underway with their configuration and integration work, but that means customers will start configuring on partially-complete systems, which can force us to be locked into APIs (or at least provide an upgrade path) for things we haven’t fully completed and thus need the freedom to change.

If it’s so hard, you might be thinking, then why do it? The most obvious reason is that it better serves our customers’ needs, and as a software vendor that’s obviously our top priority. Relative to minimally configurable systems, highly configurable software results in a product that (once configured) more closely matches how our customers do business. Relative to custom-built systems, configurable systems can be implemented faster and the end product can be owned and maintained by the customers rather than requiring vendor patches or consultants for any future changes. Even relative to in-house built systems, configurable software like ours will allow future changes to be made much faster and more safely.

The second reason is less obvious, and that’s that in many ways forcing us to think hard about configurability makes us write better, more flexible software. We’ve developed a huge array of tools (our scripting language, our metadata layer, our web framework, etc.) that would help us even if the end result was something that would never be configured by a customer. For example our web framework, while built with customer configuration in mind, lets us build new pages, modify existing pages, and find and fix bugs far faster than we ever could with our old struts/jsp-based web framework. Just like doing test-driven development can often lead to better-decomposed code, making things configurable and flexible often results in better tools and better frameworks that benefit application development generally.

With great challenges come great rewards. What we’re doing might be incredibly difficult, but that’s why our systems are the best ones on the market.