Ways to get past the Inner-platform effect while still building highly customized web apps?

Question

Feel free to answer the question in the title as generally as I posed it, I offer some more details and specifics below.

Currently I develop and maintain a somewhat legacy business app (ASP/SQL) that is highly customizable allowing for moderate to full customization on: custom fields, forms, views, reports, actions, events, workflows, etc. This customization is necessary in the domain we develop for and has allowed us to build a niche.

I have been reading up on the inner-platform effect and ways of implementing high level user defined customization and have concluded that we do suffer from many of the inner-platform effect problems because essentially we have created a high level abstraction on top of the SQL. The organization of custom fields is implemented in a similar way to the approach found here

http://blog.springsource.com/arjen/archives/2008/01/24/storing-custom-fields-in-the-database/

We use something similar to the meta database method described in that article. All customization is built around this approach and in many ways we suffer from database on top of a database.

The end result is something that looks fantastic on paper yet the more features are added and custom coding is done for clients the more of a mess everything becomes. It seems that the more I read the more I realize this is somewhat of an anti-pattern. It also seems that the more I try to read the more I find so little has been written on the topic. Anyways, I am trying to learn modern approaches to this problem and trying to find more discussion/articles on the topic. Are Database systems such as CouchDB relevant to this type of application?

My question is clearly pretty general. It seems like there is a lot against this kind of application in favor of just "knowing and defining your domain better". Are there any good/better ways to implement this kind of application? I'm not looking for black and white answers, and any further readings on the subject would be fantastic. Thanks for any help.

Answer 1

My answer is be conscious and clear about what is for a plugin to do and what is a user setting. In that case, your platform and your settings are different. Your application provides basic services and is unabashedly a platform. It may also provide an application built on that platform.

So in that case you focus on programmer interfaces instead of implementation possibilities.

Answer 2

The standard advice in CS is to create another level of abstraction, not sure if that's not the problem here. The only advice I could give is to push as much functionality onto the database, given it's the platform. SQL Server supports custom functions, fields and stored (SQL) procedures. Either that or try to pull repeated functionality into separate functions in ASP.