Adaptive Object-Model Architectural Style

Trying to make a system dynamic and easily configurable can be hard, but the payoff can be large. The Adaptive Object-Model is an architectural style that relies on storing the business or domain model separately from the code. Implementation of the model can lead to system that allows users to "program without programming".

It is interesting to see how each example system implemented the concept differently based on their domain. The Illinois Department of Health is a good example of how a system needs to be able to adapt quickly when additional data is required to be collected. Your customer does not want to be delayed and have to wait for the next software version to be released in order to capture the necessary data.

Thinking about how complicated our tax code is in the United States, you have to wonder how all the various rules and data are stored for online software programs like eTax. The tax code changes regularly and the tax software developers need to implement the changes quickly. Do you add a new table in the database for each tax form with every "blank line" as a database field?

I would be curious to know how much more upfront design might be required for implementing the AOM into a system. The architect may not immediately recognize or notice the system design has greater flexibility when adopting this model. A paper detailing the growing pains or benefits of a system that has converted from a "traditional" relational-database design to an AOM design might spark some additional interest.

Even though the concept of using the AOM is to make it possible to develop and to change software quickly, are there any noticeable side-effects or performance degradations on the database when being used this way? How does the number of reads and writes on a normalized table schema differ from the number of reads and writes on tables using the AOM schema?

I should note the co-author of this paper, Joseph Yoder, is hosting a half-day tutorial on the AOM at OOPSLA in October 2009. It is unfortunate I will not get a chance to attend.