I think they're overly cautious, but that's typical for IT departments.
That's are reasonable set of contraints. Most bigger companies / institutions have an "approved stack" of applicaitons and development platforms for what they consider "systems of record". If MIT does then the question becomes: what are the criteria for getting FM to be on that approved stack. Keep in mind that it may involve some sort of ongoing dialogue with FMI as part of "vendor management".
From what I'm reading between the lines, one of the requirements may be encrption of sensitive data. While FMS can encrypt data in transit, it does not natively provide encryption at rest. There are plugins that do so that is probably something to look at.
Interesting perspective, Wim. It's notable that one of my clients specifically asked about encryption at rest, which is apparently a DoD requirement. Although, DOE just did approve FileMaker for sensitive applications, so either DOE has less stringent requirements (possible), the MIT folks are just being overly proscriptive about protection of sensitive information (possible), or DOE is too lax (possible).
In my experience (nearly 25 years in DOE service), I've found that many of these decisions are driven less by the tech and more by the convenience or perception of management, often by what they've "heard" about the tech or by some other set of drivers (administrative features such as source control, two-person rule, versioning; desire to reduce the number of technologies in use; notions of scalability and whether it's appropriate for an "enterprise" - whether it's needed or not at that scale). Of course, that could just be my experience.
Just curious ... did any one requirement trip you up ?
> If your database needs fit within these constraints, developing a FileMaker solution is appropriate if your database
Encryption at rest can be handled with Disk level encryption, if I'm not mistaken. I find much of this security very frustrating. It's like requireing a steel reinforced basement, but the crooks are going to come in through the first floor windows. I believe most breaches are going to come through compromised password and access to an application itself. Once you are in a system, you have access to the data. The key focus should be on protecting sensitive data within the scope of the application interface. File level and disk level encryption are a good extra measure, but I don't believe it's the typical access point. I could be wrong though. It would be interesting if there were some statistics on this.
What DBs DOES MIT recommend/allow for use with personal information?
Interesting perspective, Wim.
In this case it seems like IT has a set of rules that they use. IMHO the best approach here is to not take that lightly and rile against them "as typical IT crap". But to work within those constraints and see if you can prove FileMaker's worth as tested by those rules.
Take monikers as "system of record" very seriously: that is the clearest indication that there are a whole slew of requirements, in a lot of different areas like support SLAs, guarantueed uptimes, redundancy, disaster recovery procedures and testing, change management processes,... Find out what they are and what it would take for you and your team to comply.
This goes way beyond FileMaker's technical capabilities so be prepared for quite a journey to get FileMaker on the approved list in an organizaton like this. Very rewarding though.
Encryption at rest can be handled with Disk level encryption, if I'm not mistaken.
Not really, because if you managed to take the database away from an encrypted disk you would have an unencrypted database. a backup tape for instance would hold an unencrypted database. The idea behind Encryption at Rest is that all the data is encrypted inside the database so that if you could hack your way into the database you would find meaningless gibberish.
You and I have very different "read between the lines" perceptions of what the MIT guidelines are saying (as if that weren't obvious).
Perhaps you're right. But it's been my experience that IT managers say things like my former CIO once said:
"Lotus Notes isn't an enterprise application." (That's a direct quote.) They often don't give good technical reasons (or even specious technical reasons), and they often don't really understand the technology. Example: I had a discussion with my server group just this week, who were completely unaware that you can't just grab a FileMaker 12 database from backup and restore it when external containers are in use. Or that you need to use the "download database" and "upload database" features of the Admin Console to retain those links.
They also insist on running virus scans on the live database directories, despite having been shown multiple times not only FileMaker's documentation recommending against this practice, but the fact that backups come up corrupted. ("It's a requirement.") They won't give developers access to the Admin Console (which is understandable, because of its lack of granularity), but then complain that they spend too much time starting and stopping databases. ("We're server engineers, not application engineers.")
All of this is driven by policies that just say, "You have too many database environments on your site" and "You shouldn't have these 'shadow' developers building apps who don't know what all the rules are" and "You must maintain separation of duties between development and production." Many of these are legitimate concerns. But because FileMaker is "different", IT departments are often reluctant to embrace it. (My server group has an active antipathy towards it.)
There are maybe a couple of the guidelines that might make sense. The 80 simultaneous connection limit; okay, that one is a "fence" around the 100 connection limit of Server (assuming everyone understands what a "connection" really is). And at our site, we also have, as you allude, very strict requirements for "system of record" - but FileMaker can meet them. (We have all the uptime, backup, restoration, testing, etc., requirement based on a graded approach for the server box. But the server group pushes back HARD if you try to make a FileMaker database a high-priority app.) Not to say that MIT's requirements are the same, of course; we don't know what those are, and it may not be possible to meet them with a FileMaker database. Storing sensitive information? Same thing; our requirements are strict, but FileMaker can be configured to meet them. But again, if encryption at rest is required, then it's a legitimate reason to say, "Nope, can't do that."
All that to say I think you're on the right track. What are the real requirements (and I can pretty much bet they don't revolve around a specific technology)? How would you implement them in a FileMaker environment? Since the average Joe can build a pretty good database with FileMaker, it smells more to me like they want to say, "It's easier just to cut you off and tell you you can't use that tech for these tasks than it is to try to train you on what all the requirements really are." There are just too many "average Joes" who might do something that doesn't meet the guidelines. (We have 11,000 users; I know about that situation.) So, IT just says, "Look, we'll just handle all the stuff that might get someone in trouble, and let the field do the low-risk stuff." Which isn't necessarily a bad thing, but tagging FileMaker as the source of the problem is, IMHO, the wrong way to go about it.
That's a good point Wim.
All I know for sure is life in IT seems to be getting more complicated instead of simpler. ;-)