Features Business Application Platforms Should Have

There are a lot of software packages that go way beyond being mere applications and become development platforms in their own right. WebSphere Portal, SharePoint, Lotus Notes, and Dynamics AX come to mind.

These "apps" allow you to drastically customize the way they work and add your own functionality. In fact, they probably won't be very useful for you unless you do treat them as a platform rather than a finished app.

Unfortunately, in many cases these business application platforms don't follow through when it comes to rounding out their platform features. Here's a short list of just some of the things that seem to slip vendors minds for at least the first dozen releases.

Application Modes
There are times when you want to take the application down for maintenance or upgrades, and you don't want users to just get a "server not available" message. You should be able to put your application into "Offline" mode. When end users try to access the system they should see a nice message like "The system is currently not available" or a custom message provided by the administrator. Obviously this mode can't be dependent at all on the database and only trivially dependent on the application server.

There are other times when you need to get into the application to make configuration changes or troubleshoot a serious problem, and you don't want end users mucking around with the data or doing real work they may lose. So all applications need an "Admin Only" mode. People with administrator rights should be able to get into the system, but a "not available" message should be displayed to all other users. There should be an option to let end users in with "read only" access.

Deployment and Change Management
It still never ceases to amaze me how, in this Sarbanes-Oxley world, source control and deploying customizations from development to test to production is still an afterthought for many software vendors.

The next time that sales guy is showing you how easily the application can be customized, ask him "where's the deploy customizations button?" and watch the blank stares. If he tells you the changes need to be manually repeated in production, show him the door. If he shows you some convoluted export and import procedure ask for a demonstration that takes 15 minutes or less with zero manual editing of the export file.

Also make sure he shows you how your development environment can be hooked into your source control system. Have him demonstrate labeling (tagging), branching, concurrent checkouts, and merging. If you get more blank stares, show him the door.

Data Refresh
This one would be a huge bonus. You normally want your test, training, and development environments to have data that is fairly fresh. This is rarely a matter of just doing a backup + restore of the production database, since the non-production environments probably have configuration information in the database that is different from the production environment. So having a "data refresh" utility that knows which data not to refresh would be wonderful.

Yes, you can use tools like Red-Gate Data Compare. But that requires you to dig through the hundreds, or maybe thousands of poorly documented tables the vendor has created.

Any vendors that really want to work magic should incorporate data obfuscation so the non-production environments contain data that is "real" but has fictitious values for things like customer names, bank account numbers, phone numbers, etc.