This is one of the holy grails of vertical market application software architecture. Many have tried, most have failed. See what Sharepoint does in this regard. You can't see the architecture, but you can see the user interface.
Beyond a fairly trite level of complexity you will need to add technically literate people into the process. For example, an insurance platform called ZygoWare was released under the premise that it could be customised directly by the business. In practice this tends not to work very well on something like an insurance policy administration system and the product has a reputation for being difficult to implement.
For something like salesforce.com or an online store builder the product is simpler, so it will be easier to achieve direct end-user customisation.
At one point I was involved in specifying an insurance underwriting product. Supporting customisation in such a product has several key aspects:
Database schema - allowing the system to be configured with custom attributes. In commercial insurance a contract record can have 200 fields and may also have several complex structures sitting below it.
User interface. The system will need to record these, so a means to custom fields on a form is necessary. You may also need to set up other screens and database tables.
Business rules. You may want to use a business rules engine to support configurable business logic. This gets quite complex in its own right and the analyst designing the rule sets needs to be deeply familiar with both the business domain and the system architecture.
Workflows. Workflows are de rigeur in volume business and making inroads into large commercial business as well. In subscription markets your workflows involve third parties that may or may not actually have the facilities to participate in the workflow.
Products. A platform may need to support multiple insurance products (e.g. commericial property, life/health, marine cargo, motor, offshore energy). In order to avoid having to deploy a different policy administration system for each department in your company (A typical Lloyds syndicate employs 50-200 people) your platform must support different product lines in some way, possibly involving custom screens, workflows and business rules for the different products.
This lives at the complex end of software customisation. In practice, software like this requires analyst and development skills to sucessfully implement a business solution. The domain and product are sufficiently complex that they are not feasible to implement without specialist skills.
On that basis, my approach to customising a system has a few key pillars:
Recognise who will actually be customising the system
Build it to suit them. In the case above the right level is a team of analysts and developers working for the vendor, in-house (contractors and permanent staff) or a third party consultancy. The appropriate level of abstraction is a scripting language that allows extension (on a per-product basis), a form building tool (such as QT designer or Visual Studio), a database schema management tool and possibly a rule engine such as Ilog. In the case of an on-line store builder a power user could reasonably figure out how to do it themselves.
Address what needs to be customised
In the case of an insurance platform you will have customisation at a level that you are rolling out a substantially bespoke system. The system architecture for this should allow extensions to be plugged in without having to regression test the whole system. In the case of an online store you are substantially customising the layout of the displays and configuring account information with payment providers.
Don't delude yourself about the complexity of the problem.
Don't try to dumb down a system beyond its natural level. History is littered with people who thought they could make a platform that end users could use to build and maintain a complex business application. The only commercially successful example of such a product is a spreadsheet. If you want to see how well this works in practice, try spending some time working in the back office of a large finance company.
Most regulatory authorities such as the FSA take a dim view of 'end-user computing' and the regulatory environments of such industries drive many FTEs worth of time-consuming CYA and manual controls over such processes. It is quite common to find the same computation done redundantly in multiple areas within the back office of such an organisation and the results reconciled against each other to provide a manual control so somebody can feel safe signing off the figures.