There's an interesting (and at times heated) discussion going on over at DBMS2 — DataBase Management System Services about FileMaker Pro, and it is worth checking out. Chris Kubica (of Application Architects) has been trying valiantly to explain what FileMaker Pro is and how it compares (and in many cases doesn't compare) to other relational database management systems. It's a discussion that is both interesting and frustrating, as it shows that the misunderstandings about FileMaker -- those same misunderstandings that have been going on for years now -- still remain. And despite Chris' best efforts, I don't think that the message is getting through. (The conversation started here and continues here.)
Explaining what FileMaker is, how it works, and the benefits of it is very hard to do to people who work with traditional SQL-based relational database management systems. I have a very heavy SQL background myself, and I still find it difficult at times to explain FileMaker to other SQL developers. Try explaining how you do a "find" instead of writing a query. Try explaining how you can build feature-rich interfaces within the database itself. Show them how to enforce referential integrity with a few clicks of the mouse... It's little wonder that they just "don't get it."
There are scenarios where building solutions based on traditional SQL RDBMSes makes sense, and scenarios where building them based on FileMaker Pro makes sense. It's my opinion that, because of the way that FileMaker has matured over the past several years, the number of scenarios where FileMaker is a good fit is growing rapidly.
Here's an example of where FileMaker is a good fit -- and where a traditional SQL database isn't: A few weeks ago, I was given the task of developing a proof-of-concept for an electronic purchasing tool. This tool needed to be able to obtain real-time product information from a suppler that provides it's data using Web services, allow the purchasing agent to make some decisions regarding what products they wish to purchase, and to submit the purchase order to the supplier as a cXML document. By the end of the first day I had submitted our first test order to the supplier (much to their surprise!). By the end of the second day, we had a full-featured application built. In other words, we went from specifications to proof-of-concept to production in a matter of days. (Try doing that in something other than FileMaker Pro.)
I don't think we'll ever get the FileMaker message out to the world in a way that feels satisfactory. What Chris was trying to do over at DBMS2 was to get people to at least take a look at FileMaker before passing judgement on it. I'm beginning to think that perhaps the best way to explain what FileMaker is -- and perhaps more importantly, it's value proposition -- is by using it to build Killer Applications like the one that I described above.
What do you think? What success stories can you share?