The Access/Filemaker thing is frequently an "actual" problem at the enterprise level, because in large-enough companies, the concern isn't just "does it get the job done" but also:
• Is the data being backed up? Is that backup process actually correct (i.e. if the backing data-store is a file on a SAN, and we perform filesystem-level snapshots of that SAN, can all the data actually be restored from such a snapshot, or will it be partially corrupt?)
• For that matter, is there a documented process for restoring from such a backup, such that whoever's on the ops shift could do it if need be?
• Is the backing store transparent/auditable, esp. for compliance to our privacy policy—i.e., can we write an indexing agent to determine whether any Personally Identifiable Information is being stored, without needing to ask the software's ISV for their format spec?
• Can the backing store be locked down with ACLs such that getting access to the app's connection to its backing store as an unprivileged user, doesn't let them grab our entire database, or execute arbitrary storage changes (e.g. DROP TABLE)?
• Can audit-trail logic be installed in the backing store (rather than in the app layer by the ISV), so that we will know if some contractor takes a copy of the data home with them?
When your software speaks to a formal DBMS, all these questions have easy answers. When it manages its own little proprietary DB/file-format thing, they're up in the air.
I've been in enterprise IT for a long time. These issues only exist because the governance/funding model is broken, and IT is incapable of delivering scaled down solutions at a reasonable price.
Then when the access app gets "important", IT uses it as a hostage for more funding, using the absurdly expensive cost model that they build.
Well true, but I expect the crane operator guys will say that this crane sounds all super-cool until one of them collapses and kills a dozen people, and then we'd all ask why they aren't subject to the same requirements as the bigger cranes.
I do get what you mean, but I assume a crane operator union has similar worries about this small crane and the potential safety, work rule, etc, issues. :)
• Is the data being backed up? Is that backup process actually correct (i.e. if the backing data-store is a file on a SAN, and we perform filesystem-level snapshots of that SAN, can all the data actually be restored from such a snapshot, or will it be partially corrupt?)
• For that matter, is there a documented process for restoring from such a backup, such that whoever's on the ops shift could do it if need be?
• Is the backing store transparent/auditable, esp. for compliance to our privacy policy—i.e., can we write an indexing agent to determine whether any Personally Identifiable Information is being stored, without needing to ask the software's ISV for their format spec?
• Can the backing store be locked down with ACLs such that getting access to the app's connection to its backing store as an unprivileged user, doesn't let them grab our entire database, or execute arbitrary storage changes (e.g. DROP TABLE)?
• Can audit-trail logic be installed in the backing store (rather than in the app layer by the ISV), so that we will know if some contractor takes a copy of the data home with them?
When your software speaks to a formal DBMS, all these questions have easy answers. When it manages its own little proprietary DB/file-format thing, they're up in the air.