Ideally build some of your main functionality as an extensions. You'll quickly discover pain points if you have to live with the same API and contexts as a 3rd party. I just recently rewrote TaffyDB to a version allowing extensions and a key goal was to build most if not all of the public default methods as extensions.

Thanks for the suggestion. The system is already mostly module-ized with a few glaring exceptions that need to be fixed.

My big problem is how do I let customers modify the modules themselves, without actually modifying the module? E.g. I'd like to some how give them the ability to, say, add company specific fields to the pre-existing User module and database, without actually modifying the User module source. I'm not sure how to handle the database.

This is the goal for me so future updates can be seamless, no matter how extensively customized their actual version of the application is.

Agreed, eating your own dog food is a great way to find pain points in your api.

Decouple it as best as you can. For example, authentication; make an API/Library/Class for that. Means better development security as no one can write a class that pulls all the username+passwords because that API has the configuration. (I don't know SSN that well to give a more relevant example)

Tons and tons of hooks sounds like very tight integration. While fast and procedural like, maintenance will be hard down the road. If management really want the cheap quick solution, go procedural.

Recommended reading: Object Oriented programming, Case study of Amazon's decoupling.

Thank you for the suggestion and recommendation. Right now the application is broken up into decoupled modules pretty well (though it could certainly be improved).

I think I gave a pretty poor example in the question, not explaining exactly what I was confused about. Say I have an Auth module with a full suite of methods (login, logout, etc.). Supposed I had a client request a customization that not only requires a username/password for login, but also (as a contrived example) the user's employee number. I'm not sure how to setup the application architecture to (1) easily allow modification of the Users table to include an "employee_number" field (2) update the Auth module to check for employee number in the login function and (3) modify, say, the Login module to update the form that displays the username/password/employee number fields.

My ultimate goal is to work some system where the Auth module/Login module/database tables did not have to be directly changed, so software can still easily be updated.

Hard to tell without seeing the code: Employee_Auth(Username, EmployeeID) and User_Auth(Username, Password)

If both are true, then authenticated?

The ExpressionEngine CMS uses the idea of "hooks" [1], which are basically global events that are fired at key points in other modules and extensions. Extensions can register to be notified of these hooks, which allows them to modify data at those key points, or modify output.

Extensions can check when they are first instantiated if their schema changes have been made, and if not, apply them.

It works out pretty well.

[1] http://expressionengine.com/user_guide/development/extension...

You can setup a dev account in salesforce.com and make some customization to contact, account objects with custom fields, etc. This will give you some ideas on how to architect your system for easy customization.