When do you stop with the extensibility?

The current project I'm on is with a major insurance company replacing, over the next four years, its old mainframe policy processing system. It's all fairly organized, but there are two problems that are making it less than fun.

The first is that they want to make so sure that they don't get locked into anything long term (the new system is all .NET-based) that they've created custom tools in-house to create rules and work flows and store them as XML. These tools also in many cases generate code to do some of the grunt work.

It's a good idea in a lot of ways because these simple GUI tools let non-coders develop the rules and work flows The problem is that these tools don't have the same requirements process as the bigger project. The tools are written by two or three people as a continuous work-in-progress. Just starting the tools cause five or six exceptions, and a lot of actions do the same thing. It's really annoying.

The second problem is that I question how necessary a lot of this is. Having the rules in some kind of XML format makes sense, but doing so for the work flows is overkill. There are only a couple dozen processes in the big picture, and each one has a handful of work flows.

Not that I can change anything, but what do you think?

No Comments