The product configuration report dilemma

For those who follow our report agendas here at Celent you will have seen product configuration on there for a while now, finally culminating in the report Designing for Product Agility. I thought I'd use the blog to offer a perspective on my own journey through product engines and product configuration to explain how the report came about and what question it attempts to answer. The report originates from two sources really. The first is in my work with insurers both selecting new systems and in evaluating existing systems. In this work I and my colleagues at Celent have spent some time educating the market that in buying a new core system they're not just buying software but a pre-thought out design for how things should be done at an insurer. The software is configurable and can be customised but ingrained in there is a model or a map for how an insurer operates. No where is this more clear than in the definition of a product, the definition of sets of products and how products are managed. The second source is my work with the vendors themselves. As an analyst at Celent I have the benefit and honour of seeing many demos (a guide available here) and this provides me with an opportunity to see many different models regarding workflow, business rules, screens - all these things related to a product. From these two sources the idea for the report was born - to compare different structures, different ways of assembling products, the different ingredients and different ethos of the vendors to give insurers some insight into the complexity of the problem and how they should navigate their way to their perfect match. Also I hoped to offer a tool for introspectionism for the vendors. As I started to write this though I found that while these different structures are innately interesting to an abstract thinker like myself, they were on the periphery of the real problem: How do I make best use of product configuration capability to achieve the objectives of my organisation? This then is the focus of the report and why it was renamed to Designing for Product Agility. There is some discussion of how product components are assembled, how collections of products can relate to each other, how tooling can make up for poor structure, how having a single team can improve speed but having many systems can make change even faster again - but the focus is on applying these things to achieve a business goal. The title comes from the focus on designing not just the IT systems but the business to match the goals, to design the human and software systems to achieve agility in line with their particular balance of autonomy versus efficiency. We will look more directly at the issue of product agility in future reports, particularly with the advent of the digital insurer. In the meantime, Donald Light's long standing works on the subject (P&C edition and Life edition) remain relevant companions to the designing report.