First off let me say that FileMaker is a great database system that has proven to be extremely flexible and easy to manage.
Countless times we have started a project with a client to determine content strategies, data warehousing strategies, and digital asset management strategies and they all have one thing in common. The client will usually mention an implementation of FileMaker that they are looking to replace. "We need a way to migrate from FileMaker." "We have multiple FileMaker systems that we need to either eliminate or integrate with."
The problem is that because FileMaker can be so easy to setup and configure, that it is often integrated as point solution, or a solution to hold you over, a quick fix. The trouble then starts a few months after you get that FileMaker system up and running. It becomes embedded in your every day work, and the system outgrows it original intent. The reasons for implementing a FileMaker system simple. You need a database to hold information and it is easier to setup a FileMaker system than to create a data model, have a database administrator set it up, and create an interface for managing and editing the records. Because FileMaker can be updated so easily, every time a change is needed there is little thought on what the impact of the change will be on the data model.
When it comes time to migrate from, or integrate with a FileMaker system there can be a multitude of challenges in determining how to organize and normalize the data that is either stored in FileMaker, or will be integrated with FileMaker.
Next time you are considering implementing FileMaker, think about what the problem is that you are really trying to solve, and then ask yourself if you are looking for a quick fix, or a solution that will scale to meet future needs. Regardless of wether you decide to create a FileMaker system or not, careful data modeling and planning is essential to make sure that if you need to integrate or migrate from systems in the future, that rework is reduced to a minimum.
What are your thoughts on using FileMaker for for large data management projects? Are there other point solutions that you see implemented all the time as a quick fix?
FileMaker-Blessing or Curse?
Hi Ivan, As someone who makes their living designing what you refer to as “Multi-Channel Systems,” (For example, I am currently engaged in such a project for the marketing department of a large shoe manufacturer in Oregon.) usually, though not always, employing a FileMaker component, I was very interested in your comments. Furthermore, I would readily confess that I am guilt of the “If your only tool is a hammer, everything is a nail” syndrome.
FileMaker is the only database application that I know well and I do regard that as a limitation. Having admitted that, I would nonetheless take issue with some of your conclusions. I also often encounter legacy FileMaker systems, which, as you suggest, are often expedient and poorly designed, having evolved over a period of time in an unsystematic manner. In some instances the result can only be described as chaotic.
Incidentally, I have found that FileMaker systems for digital asset management often tend to be the most dysfunctional. However, these “point solutions,” as you so aptly describe it, do often serve as useful organizational assets. In many instances they have become mission critical despite all their deficiencies and usually have been in place for years as opposed to months. My usual solution is to do exactly as you say: create a comprehensive data model, a reliable administration, and an effective user interface. And that’s my point.
For a number of reasons, often budget being chief amongst them, we (the client and me) elect to fix not replace. I agree that ongoing development and iteration needs to be managed to avoid negative impacts on the “data model” and runaway feature creep. While I agree that both migration and integration can be challenging I have yet to encounter an insurmountable obstacle with the exception of managing some data types (audio, flash, etc.) FileMaker, even with the Web Viewer and Plugins is not a competent platform for this purpose on any meaningful scale.
There is nothing intrinsic in FileMaker that precludes a well-considered data model, or proficient administration, or efficient interface. I would also question you implication that FileMaker lacks the attribute of scalability (is that word?) I have relied for years on FileMaker’s continuing evolution and have not been disappointed. Having said all that, I strongly endorse your conclusions that the decision to “fix or replace” be subjected to a thoughtful, objective cost/benefit analysis and if the decision is to fix, any of my clients would benefit from following your direction to respect the requirements of a careful data model and planning.
-- Anthony S. Roberts 5237 NE 32nd Avenue Portland, OR 97211 Voice: 503.954.3707 Mobile: 206.218.3677 Fax: 314.431.9312 E-mail: anthrob@earthlink.net --
FileMaker's expandability
I read your blog with interest, but can't say that I agreed with its premise. I agree that FileMaker tries to make itself accessible to the novice user, and because of that, can allow poor design from the start.
A user can write a database that has no normalization and poor relational design (or none at all); I've seen lots of homespun databases that were clearly written by users who didn't know much about FileMaker.
Having said that, I will also add that it doesn't take much planning to create a simple database in FileMaker, and which also adheres to good data normalization. If the file is designed right, it can be added to without having to restructure anything, and eventually grow to become a full-featured, well-designed relational database with lots of bells and whistles.
Virtually any database application can spin out terrible databases in the wrong hands; some are less forgiving than others (another way of saying less user-friendly) and have a steeper learning curve, but there are pluses and minuses to both methodologies.
FileMaker enjoys users at all levels of expertise--it can be used to write full-featured, fully-normalized database solutions, and it can also be used to write flat-file databases that have no relational aspects at all. It can be used as a glorified spreadsheet app--I've seen this countless times--but even with a simple flat file, a skilled FileMaker consultant can take this flat file and develop it into something elegant and easy to use.
What you might have said was, don't be misled into thinking that, because FileMaker is easy to dive right into, doesn't mean that everything you create will be brilliant. In the same vein, just because I have a great camera doesn't mean that I'll take great photos.
RE: FileMaker's expandability
Hi Bob, thanks for your comment. I don't disagree that with the right planning and data modeling that FileMaker can be scaled to handle larger database applications.
Your second sentence: "FileMaker tries to make itself accessible to the novice user, and because of that, can allow poor design from the start.", maybe this is something that FileMaker could take into account and could help the user around data modeling to setup their databases correctly. Like I stated in my first paragraph, I think FileMaker is a great tool, but too often we have come across very LARGE scale database applications that originally used FileMaker as a quick solution, but have since grown into a beast of a system because changes can be made so easily.
FileMaker as point solution
I have found that if we build a point solution in consultation with our DBA's and system architects, FileMaker can actually be a really effective prototyping tool.