Insurance software component development - using evolutionary methods and process improvement to address the real requirements
The client had acquired a small insurance software house based in Tunbridge Wells, which had developed a generic component based insurance application, using J2EE technology.
The Insurance software component project had started life about three years earlier with some staff from a defunct insurance company’s IT department. The concept was to develop a set of generic Java components which could be used to build any insurance application. The team worked in Tunbridge Wells, originally part of a local computer services company, and had been part funded by venture capitalists, prior to being taken over by the client.
My role: I joined as a consultant working for the project manager. The PM, who had joined only 3 months earlier, had already identified many issues of methodology and generic design, and had recruited me principally because of my insurance systems knowledge.
One of the first things I had to do was review the insurance business capabilities of the system. There were many deficiencies in the application design of some components, such as the lack of any version control on policy records, as well as problems with the development process itself. There were no formal product requirements, just high level marketing material. There were at least three major customers requiring components, a general insurer, a personal lines broker, and a credit card insurer. None of these customers had specified any detailed requirements, and very few of the components so far developed had rigorous functional specifications or program designs. On the positive side, a consistent technical design philosophy had been implemented, based on the Cheeseman approach.
Working from past experience, I realised that the insurance business model used for the existing components was rooted in the defunct insurance company and would not support the businesses of these new customers without major changes at both overall and detail levels.
Most notable was the lack of generalisation of customer and business partner roles, and the absence of any customer accounting capability within the Insurance Component architecture. But the whole architecture, although having many useful and clever product design features, lacked the generality needed for an insurance component set which could be used for the complete product range of the existing customers, let alone the future ones.
The PM and I worked on different areas to turn the project round. He concentrated on improving process of developing components, introducing rigorous specifications to defined quality standards, formal reviews of specifications and program design, and formal testing. He also instituted an evolutionary approach to try to speed up software delivery (c.f. Tom Gilb).
My actions: Leading a business analyst and data modeller team, a new business object model and detailed process flows were created, and I specified the central Contract Management component. But before this could happen, we had to re-establish the overall requirements for the Insurance Components. This proved very difficult to achieve as none of the application product teams serving individual customers ever developed adequately detailed customer requirements.
I also developed a high level Insurance Component architecture which included the development of business partner and customer accounting components, but these were not started. At the end of June 2002, all development work on the project was transferred to a new team of permanent staff at Whiteley, and my role and those of the existing contract team in Tunbridge Wells were finished.
The lessons we learnt:
- It is possible to deliver complex high quality software in an evolutionary manner
- A product architecture is needed before evolution starts – but it does not need to be definitive
- Both the requirements and the architecture may evolve as more user feedback is obtained.
- Client management failed to coordinate all the product development teams involved in the sale
- Lack of well defined requirements remained the single biggest issue throughout