1 of 1 people found this helpful
One thing the "standardization" zealots ALWAYS overlook is the relative cost of development.
In recent years I did a significant amount of work at a major Australian University where FileMaker was widely used by "real people" but despised by the IT dept. Whenever discussion came up about migrating system X from FileMaker to some "standard platform", the answer to "how much will it cost to migrate?" often came back in the 6-figure range.
Make sure you have a clear understanding of the full range of functions and services your FileMaker systems provide, and make sure management understand the development and maintenance costs involved in replacing those functions with something other than FileMaker.
As far as security goes, with proper physical security of data files and backups, FileMaker is no worse (and in some ways better) than alternatives, so others with more knowledge of this will probably chime in with info on this side of things. The way to fight their ignorance is with proper information. GO to filemaker.com and search for 'security'. There's plenty of info there.
Another point is that many IT service provider-type companies have heard about older versions of FileMaker, and are basing their opposition to it on outdated info. Reputation *always* lags reality.
The bottom line: those who wish to "run FileMaker out of town" are generally doing so from a position of ignorance and/or blindness. Another factor is that generally FileMaker requires less oversight, intervention and management than their "standard alternatives", so they may well be just looking to improve their bottom line by having more things to charge your facility for.
I can't advise you on tactics, but I hope these points give you some ideas on how to best man the barricades!
1 of 1 people found this helpful
I couldn't agree more. I've had this one client for over 20 years and each year, the management decides they will replace FileMaker with a 'real' system. It doesn't help that the CEO is a former GM of a major multinational computer company (whose three letter name shall remain nameless), still believes that FileMaker is owned by Claris (seriously). The last quote they got to replace it was $250K and the developers said that would only include half the functionality of the current system and would take years to develop. The cumulative total for 20 years of development of the current system hasn't even come close to that figure.
So John D, you just need to come up with strong arguments based on fact. One is the cost of a replacement solution and the other is security. Best of luck.
I feel your pain. I work at a large DOE site, so we are experiencing the same phenomenon to a certain degree. While the IT department hasn't really come out with a stated intent to run FileMaker out of town, there is always an undercurrent that we need to "reduce our tool set" and "standardize" - and an expressed perception by DOE that we have "too many database environments".
Marc and Rob have given you a good start. As they point out, most arguments against FileMaker are based in perceptions that are usually either outdated or simply wrong. However, in order to combat them, you'll need to address more than just the factual issues. You'll need to answer the question:
"What's in it for me?"
In other words, IT will often have legitimate issues with supporting FileMaker. And those questions often are based in the fact that FileMaker is, well, different from other applications in significant ways. Examples:
1) When you're stopping the FileMaker service, you can't just stop the FileMaker service. You should stop the databases first through the Admin Console. (Why? This imposes extra work on my server admin.)
2) You shouldn't run virus scanning on live FileMaker databases. (Why not? And does this leave my server vulnerable?)
3) Does FileMaker support single sign-on? (Yes. But the developers have to configure their databases to use it.)
4) What about cross-training costs? I have a hard enough time keeping developers trained on one or two technologies. If I have to keep up with half a dozen, it's going to make my personnel management a nightmare. (This is a real sticky wicket, and will depend on how your site is configured.)
5) When we have all these different database environments, getting them to talk to each other is a huge problem. We need to standardize so our systems can communicate. (With FileMaker's ODBC, JDBC, ESS, web viewer, and related capabilities, this is less of a problem than they think ... but they usually don't know it.)
In other words, you'll need to have a policy in place for your FileMaker developers that addresses real IT concerns. I had to do this here, and I also (try to) enforce it through the site's User Group.
The issue of cross-training is huge in standardization. There's not an easy answer, except when you start looking at two factors: One is the cost, and the other is the developer base. If you have nothing but professional developers, then the standardization issue tends to make more sense. However, in most circumstances, FileMaker is part of the standard desktop, and you have lots of "shadow" developers - people who have a "regular" job and build databases for their workgroups part-time. Those folks probably don't have either the time, the inclination, or maybe even the skills to learn something like Oracle or .NET. Their solutions are simple, very quickly deployed, and would cost orders of magnitude more to develop and deploy in another environment using a full-time IT developer.
Hope that helps.
It is really nice to know I am not totally alone in the IT wilderness out here. Many thanks for the response.
I am beginning to pull together migration costs. Amazing how fast it gets pricy.
I am also starting to come up to speed on some of the security issues. Any chance that you could send me a copy of your Filemaker Users Policy?? That would certainly help our argument.
I do think that with some homework on my part, I’ve got a decent chance of success, if for no other reason than so many of our databases are critical for safety and industrial hygiene compliance for the site, and my managers understand the importance of those databases.
Again, many thanks!
John C. Doherty, CIH, CSP
Washington TRU Solutions, Contractor to the
US Dept of Energy - Waste Isolation Pilot Plant
32 miles SE of Carlsbad
Carlsbad, NM 88220
575 361-4030 mobile
575 234-8850 pgr 115
Many thanks. I am starting to implement your recommendations. I will keep you posted.
Many thanks. Now time to implement what you have given me.
This document is a little outdated (it doesn't mention iOS deployment as an option, for instance), but perhaps it will give you some additional ideas to justify FileMaker's continued role within your organization: White Papers for IT and Small Business. HTH.
I was recently shown a filemaker database that had been replaced by a campus wide database. The new database was supposed to replicate and replace FMPro. The only thing it couldn't do was allow them to produce letters. Of course, the users had absolutely no interest in storing names and addresses. The only reason they collected them was to print letters. The result was that they entered the data twice, once for the new system, and then into fmpro.
Many thanks. Looks like this issue will go all the way to the GM, so I need everything I can get.
Gotta love it.
The key IMHO is not to fight it on a technology level. Don't try to prove that FM as a platform is better or equal to whatever is proposed. Fight it on the business value level. Show that you are open to any technology they propose and any course of action they map out. But prepare numbers and ask for business input. If there is a clear business case of keeping the FM solution, the business will fight your fight. Clearly document what your solution is doing and how much it costs on an ongoing basis. Also document the the development process and how much that costs, how agile it is.
Embrace the change and don't give them any chance to attack the platform. It's likely about politics, not technology so fight the fight on the right level.
Show them you can adapt but be the guardian of the business sense of the initiative.
I have forwarded your wisdom to my department management. We will apply it.
The notion that workgroups have to choose their software and hardware based on "standards" rather than needs/outcomes is misguided IMO, but typical of centralized IT. I work for the State of Oregon, and we have hundreds if not thousands of FileMaker users scattered around various departments, but FileMaker still flies largely under the radar, and IT security policies are a never-ending series of speed bumps. Fortunately we have some good IT people on our side who have come to realize that FileMaker is not such a big deal to support, it's not going to bring down their servers or network.
For starters, tell your IT "you broke my app" and here's how to fix it:
Most likey they just need to open up the required firewall ports to get your web publishing going again.
FileMaker Application Developer
Acute & Communicable Disease Prevention
Center for Public Health Practice
Oregon Public Health Division
As soon as IT is directed to again provide us with support (the politics seem to be getting Machiavellian), I will use your information to get Server fully functional.
Many thanks, you have been of great help!!