Using a rules engine like Drools was already mentioned.
Leaving a large part of the configuration to the end users has a typical drawback compared with programming maintenance:
- Changes have an immediate effect on the running production system;
- Versioning is absent;
- Design is ad-hoc;
- Documentation is absent;
- An end-user is not accustomed to the "logic" of a software system.
Hence sufficient and extra careful development is required.
Do a detailed design, with detailed stories: final user interfaces.
Only after having technical requirements, a technical conception, look for the correct tool(s). So the development times are distributed proportional to the work load parts.
A warning: do not store complex data (hundreds of graph nodes) in several database tables, when that data is like a document; better store such data as XML in one single table (JAXB). It is better if one can step from graph to graph, instead of having all distributed - even with JPA.
Another note: such software should typically ony assist in planning,
not necessarily be prescriptive. The client often only wants to optimize, do things fast and unbiased. This means that manual exceptions probably should be dealt with and be documentable.