FileMaker developers are a unique phenomenon. In a wide world of software development we find ourselves wearing many hats: project manager, database admin, tester, graphic artist, user interface designer. We often find ourselves involved at all levels of the project, from beginning to end, from being on the front line meeting with the customer to back in our offices deep diving into the script debugger. Having such varying roles within a project is one of the truly awesome things about being a FileMaker developer. Unfortunately, having all these roles bundled into one is something of a paradox in the wide world of software development.
This isn’t intrinsically bad. In fact it is one of the things that makes FileMaker more marketable. Most companies not using FileMaker for their solutions have entire teams of people just for designing their website page; then another for administering the database; and yet another team called data analysts that help query the data into sensible reports. The overall overhead associated with having teams of people far outweighs the cost of using FileMaker; making FileMaker a more cost effective option. This is exactly the argument that many of us use when first discussing FileMaker with potential clients. And it works.
Yet, FileMaker still has not caught on like wildfire. While its certainly popular, it’s not a household name like Oracle or MySQL. One of the reasons for this is that, while the cost effectiveness often convinces business people, other software developers within a company might remain skeptical simply because the idea of FileMaker runs contrary to the mainstream thinking of database and web design. The standard thought process for most solutions is that there are three developmental parts to every solution, and therefore three roles.
The first is that of a database administrator. The database administrator is responsible for maintaining the integrity of the database. They will create the schema, set permissions, and might even be responsible for maintaining the physical server that hosts the database. Their realm consists of the server and the database engine, usually SQL powered. Most people who have heard of FileMaker typically view it in this context, as a database engine. In terms of FileMaker, this roughly corresponds to the initial file and schema creation.
The second role is that of user interface designer. This person would be responsible for building a website’s pages or the interface for an application. They create the objects that the user will interact with in order to get to the data they need. They are concerned with the actual database only as it relates to presenting the user the information they need. For a website these individuals live in HTML, and for applications might use a different programming language. This relates directly to building layouts and objects in FileMaker.
The third role is a little more ambiguous and serves as an intermediary between the database and the user interface. A person in this role would be responsible for ensuring that the data in the database is consistent with the user interface. They might write logic in PHP or some other scripting language that enables the proper assemblage of data for websites. They might be data analysts who query reports. A FileMaker developer might use FileMaker scripts and calculations to handle these problems.
These of course are simplified generalizations. Most software projects are more complicated, and involve many moving parts. Yet, understanding the three stereotypical parts of a projects development can help you explain what FileMaker can do for an existing team of developers within a company; especially since FileMaker can handle all three aspects! So whether you are speaking to a database admin or a .NET developer you can speak their language and convince them how FileMaker has all the same capabilities and more.
