Assessing Relative Maintainability

Question

We (a contractor, actually) are implementing an off the shelf system to replace a legacy homegrown system for the core domain of the company (designing widgets). Unfortunately both systems will have to run concurrently for some time, as the product just isn't ready yet. Also, the decision was made to only migrate some of the widgets from the legacy system, based on date of last sale activity.

Later on a new requirement came down: certain people in the company, most of them outside of the widget development context, want to search all widgets. The search results screen has 3 pieces of data: a GUID, a human readable id that is searchable, and a brief description (may need to be searchable in the future). In the widget details, there will be multiple screens. These screens align very well along SOA / bounded context lines - a screen for marketing data, a screen for sales history, etc.

UML ahead! I am probably using the wrong kind of arrows here so please forgive me. The current solution - which is not in production yet - is something like the following:

Both systems will be queried and the controller will merge the results.

The new system has its own proprietary query language (we've alleviated this a bit with a LINQ provider). It also puts a lot of data on the wire. 15 search results typically run about 60k of unintelligible SOAP-wrapped xml. So I would prefer to avoid querying this system directly.

These two systems publish events to help us integrate with other systems, mainly an ERP system. One of these events contains all the data necessary for the search screen. I proposed the following alternative:

However I am being told that 'adding another database' will create more maintenance down the road. However, I believe this to be false, as I had to add a relatively simple feature that took several hours longer than anticipated because of this merging code.

I want to get a feel for which system is more maintainable in the long run. I personally have not had the burden of maintaining any large system. I want something more than my gut. Specifically I'd like to know if having more, specialized physical databases is more or less maintainable than having less larger physical databases.

Answer 1

The 'search database' introduces an additional point of failure in the total system, and the failures introduced there might go unnoticed for a very long time.

The problem that I see is that the 'search database' might miss or otherwise fail to process a widget_event and get out of sync with the two sub-systems that it provides a front-end for. Such an inconsistency will happen in the long run and won't be noticed until someone notices a particular widget being missing from the search results, while it is known to be present.

The 'search database' could work if you design it such that it periodically performs a full synchronization with the back-end systems, but then the added value diminishes to nearly zero, because you haven't skipped out on the queries to the back-end systems, while you still need to maintain an additional system.