This article is about FileMaker and why it is poised to emerge as a cornerstone in Apple’s mobile enterprise story, whatever that may become.
1. Established Technology
Few technologies have arrived in the app store with a foundation based on decades of business domain expertise, tens of thousands of invested developer hours, and thousands of third-party developers, experienced consultants, and solution providers. FileMaker is uniquely positioned to capture a significant share of the custom business apps market.
2. Agility
FileMaker Pro and its bigger siblings, FileMaker Advanced and FileMaker Server, have been around long enough to evolve into rock-solid application development products with remarkably agile frameworks. FileMaker has been used to successfully deployed hundreds of thousands of business applications which can run on iOS without modification.
But even with its magical and effortless cross-platform support from Windows, to Mac OS and now iOS, the underlying technology provides a level of agility that few app development approaches can match. The puzzle pieces are already in place to transform this agility to mobile business solutions.
3. Frictionless Deployment
Everyone wants native apps but small and medium-sized businesses (SMB) must live within resource constraints that make it difficult to tackle native app projects. Even projects based on HTML5 or simple web interfaces are non-trivial undertakings for many businesses. FileMaker provides an abstraction layer that allows rapid cross-platform development without significant iOS, XCode or HTML5 skills.
Wait… there’s more.
And now to the bonus round. Here are two additional reasons FileMaker will become a deeply entrenched mobile business applications leader by 2012 and why this database product may emerge as a cornerstone in Apple’s enterprise strategy.
4. Unfair Competitive Advantage
Imagine if Apple acquired QuickOffice. With a swipe of Steve Jobs’ pen, all other Microsoft Office iOS solution providers would view QuickOffice through very different competitive optics.
All businesses strive to achieve an unfair competitive advantage; it’s the nature of free markets and the foundation of competitive differentiation. This term is typically and mistakingly associated with illegal activities that capture the attention of the US Justice Department. However, in this context I’m simply pointing out that Filemaker enjoys a slight advantage over other app developers because it is a wholly-owned subsidiary of Apple, Inc.
It’s likely that FileMaker developers have friction-free access to iOS engineers and other resources at Apple. Even if there’s no sanctioned cross-pollination of knowledge, their kids play on the same Soccer teams, there are long-established friendships, and there’s core institutional knowledge that probably flows between product managers, marketing executives, and engineers.
This is an ideal competitive advantage that few other mobile solution providers can ever achieve. Even if Apple wanted to establish similar relationships with other app developers, there’s the issue of intellectual property disclosure and all the legal ramifications that aren’t present when disclosing information to employees.
5. Android and Blackberry
While the likelihood of FileMaker appearing on Android and Blackberry devices is pure speculation, the interpretive architecture of FileMaker database applications ideally positions it for additional mobile OS targets. FileMaker is uniquely positioned to emerge on popular OS platforms with relative ease. FMTouch, an alternative to FileMaker Go, has already demonstrated that third-party companies can generate native apps from a FileMaker Pro database application. Demand for cross-platform support on Android and Blackberry will predictably encourage additional offerings on these mobile OSes if not from FileMaker itself.
I think, too, that Filemaker will be recognized as a genuine database application as opposed to Access, which is actually a spreadsheet disguised as a database.
Don,
Your point about a “genuine database application” is fully absorbed by me. While this article is really intended to raise awareness of key elements that suggest likely success by FileMaker for mobile solutions, the topic deserves far more depth concerning the importance of database applications especially in the rapidly changing topology of mobile PCs. The data is clear – laptops are being displaced by iPad and soon many tablet form-factors will join in the displacement trend. What cross-platform, mobile database technology is better positioned to take a third of that market share?
My experience with FileMaker is that it is a limited end-user database tool for small to mid-sized departmental applications. It is sorely lacking in features required to built enterprise class applications. It doesn’t use a standardized language for scripting, instead using a ‘child-like’ scripting language that is non-standard (not taught in a single university environment), it’s performance querying against complex schemas is horrible. It is not a tool a professional developer would ever consider for building enterprise applications. It isn’t marketed that way, if you read their literature and website. It might be better than MS Access, but that isn’t saying much. MS Access is another want-to-be database tool for unskilled people who won’t take the time to learn real languages and robust tools. If Apple really cared at all about the enterprise world they would buy a company like Servoy and their product which started out as a ‘professional’ developer’s 4GL tool based roughly on the FileMaker model and move away from the the propietary junk they currently support to a standards based tool. Of course Mr. Jobs is a bigot when it comes to established standards like Java so that would never work at all. The iPad needs a front-end tool to Oracle, MS SQL Server, DB2, etc that isn’t dragged down by all the baggage the FileMaker still clings too. That is its Achille Heel to any acceptance in the corporate world of enterprise applications. Yes, you can throw together an iPad solution quickly that looks like something that would take months to build in XCode, but the performance would cause a revolt among mobile workers who had to use it day to day. Also there is no synchronization processes available for those situations when Wi-Fi is not available. Forgot 3G connections, unless you have a 1/2 hour to create and save individual transactions!
Hi Gary, you do make some valid points:
* You’re right that FileMaker has limitations, and that it is targeted more for end-users than for enterprise-class applications.
* “there is no synchronization processes available” for FileMaker Go. This is half true. It is possible to ‘roll your own’ synchronization process, but handling bidirectional sync is probably beyond the skill level of most FileMaker users. You can send and receive database files via e-mail, which is sufficient for many cases.
However, many of your other points are either irrelevant or wrong:
* For FileMaker’s target market, which is not professional developers, the non-standard scripting language is a feature. End users are much more productive with FileMaker scripting than with, for example, Java code. Whether either one is taught in schools is irrelevant to the target market.
* FileMaker’s query performance is quite good. You can query a billion record database in less than a second.
* “It is not a tool a professional developer would ever consider for building enterprise applications.” This is incorrect. I am a professional developer, and I have built enterprise applications with FileMaker. There are thousands of other developers as well (http://filemaker.com/developers) doing similar projects. When rapid development is a high priority, FileMaker is a very attractive option.
* “1/2 hour to create and save individual transactions” – based on this statement, I don’t believe that you have ever used FileMaker Go. I use it to access my company invoicing and ledgers remotely via 3G, and while it’s not as fast as sitting in the office, I can open FM Go, log in, search for invoices, view the related financial entries, and then log out, all in less than a minute.
In summary, if you have the skills and the free time to build a native app in XCode, then go for it. If you need rapid development and don’t want to spend months or years learning, then FileMaker Go is a great choice. I did the same application both ways for a large enterprise client, and I will tell you that the FileMaker Go version was done in 1/10 the time, looked better, and made the client happy.
Good points Jesse and I’ve recently caught you on a number of FileMaker podcasts – lots of great tips and insightful knowledge.
I agree with your assertion concerning app time-to-market, or time-to-production. Internet years are basically dog years. Mobile app years are like butterfly years so the pressure is really intense to provide killer solutions and extremely fast.
I just finished a social media BI app in about 21 days; XCode would have taken about 16 weeks. As an old dBase developer, I can appreciate the benefits of a well tested database implementation that supports cross-mobile-platform out of the gate. Looking forward to the FileMaker Go for Android. ;-)
Gary,
You make some interesting points; however, you are making some rather sweeping statements which are somewhat disingenuous. Your primary concern is that FileMaker is not an Enterprise tool. Your reasoning for this is twofold: it does not use a standardized language “taught in…universit[ies]” (e.g. SQL), and it does not cater to “big iron” database deployments. As correctly stated, FileMaker, Inc. does not position itself as a tool for hardcore IT programmers who spend their hours optimizing code for databases running hundred of millions of records. FileMaker is clearly not intended to be that type of system.
So does that make it of no value in the Enterprise world? Of course not. Most database solutions that are developed for the enterprise are based within department, operational units, geographical regions etc. A minority of database applications are deployed enterprise-wide to thousands of users. Of course, enterprise IT units mostly focuses on these massive application deployments. To this end, enterprise IT focuses on Oracle/SQL/etc. deployments. However, most departmental users have a tremendous need to create effective applications that solve problems that are still mission critical, even though they are not big enough to be noticed by the main IT or funded at the enterprise level by management. And they need it done yesterday.
Frankly, this is where FileMaker is unbeatable. FileMaker empowers the knowledge workers (a.k.a. power users) to build their own successful solutions without the assistance of IT or other programmers.
This is abhorrent to some IT departments. I could name some fortune 100 companies that actively fight their users if their users try to build applications to solve their department database needs, many of which are being overlooked by IT because “we’ve got bigger fish to fry” or are being underfunded by management for the same reason: it’s not their pain.
This is a real shame. There are better ways for IT staff work with departments, for example by providing some guidance (e.g. “watch out for x”, “make sure you have backups”, etc.) while allowing the department to build out their own internal applications.
FileMaker on the iPad and iPhone provides a compelling solution, which allows department level power users within the enterprise to actively deploy their own shared applications on a major mobile platform. Just because it’s not “standardized” doesn’t mean it’s not useful, especially when the standardized IT department either won’t or can’t give the departments the time of day.
Power users and knowledge workers … who exist inside of every enterprise department … don’t care about SQL, Java, Flash, and all the other buzz words of the IT industry. They don’t care about your NoSQL, MapReduce, or MongoDB. They certainly don’t care about your übermensch Perl scripting or your LISP, Haskell, or Erlang. Some of them might think it’s cool, but all of them just want to be able to get to their contacts’ information and take notes on what they’re doing while they’re out in the field.
They just want their solutions to work. FileMaker Go works. It can be scripted to sync data back and forth between a server and mobile user, and with a little bit of care it can deliver effective database performance on a 3G network (I know because we’ve done it). It can handle thousands of records or tens of millions of records.
FileMaker can event communicate with Oracle or SQL. It’s just not the “darling” of enterprise IT programmers. Does that make it unusable for the enterprise? No.
Thanks for the responses to my earlier post on FileMaker!
I do appreciate hearing others opinions on this topic. Yes, I have used FileMaker and FileMaker Go, no, I’m not as experienced with it as some of you who have posted. But I do know dozens of professional FileMaker developers with years of FileMaker experience, who have left the product for other tools such as Servoy, Omnis, .NET that do a better job at communicating with SQL databases.
These same people have provided hours of interesting discussion about the strengths and weaknesses of the FileMaker. I read what Bob Cusick blogged about recently: ‘Using the Right Tool, Without Becoming One’. If all you have is a hammer, everything starts to look like a nail.
I have 25 years experience using Omnis which is a development front-end for SQL databases that is cross-platform and another 4 years experience with using Servoy which is a Java 4GL tool for building enterprise front-ends to SQL databases that runs in both the web and as a Java SmartClient. I do admit I have less than a year total working with FileMaker Pro. I have picked up various copies over the last 20 years, but have always put it down for better tools. (at least for the applications I had to design and build!). After having worked with proprietary databases in Omnis in my early days in the 80′s, I have no interest in going back to that world again.
Yes, FileMaker can talk in a very limited way with SQL databases, but my personal experience with that functionality found it so limiting compared to the enterprise tools I currently use, I have a hard time finding a reason to go through that pain just to build something quickly for the iPad.
The clients I deal with, which are many universities, hospitals, and government entities would never allow a departmental power user to touch the corporate or business data with a tool being such as FileMaker. Y
You may have clients yourselves that do allow that kind of access to their misson critical data using FileMaker. Our company has been extremely successful in eliminating dozens of these departmental applications that act like islands of data that are not integrated into the larger pictures.
Managers tell me that they no longer want these islands of data hiding out within departments. I would estimate our application has replaced at minimum several dozen departmental apps that lived in their own little isolated environments.
FileMaker Go is cool, no doubt about it, what isn’t cool, is FileMaker Pro and its limitations. FileMaker Go is like crack, it makes you want more. The bummer is when you find out that FileMaker Pro is what is holding the Go…Back.
There will always be opportunities for companies and developers to build apps with it and to make a decent living. I don’t fault anyone with that. But, as many of my clients will state, if a ‘departmental user’ is spending his time building departmental apps’ then he is not doing the job I hired him for and he need to find a new career.’
I wonder if topics such as synchronization are discussed because FileMaker is not capable of interacting with ‘live’ data? Is the FileMaker database nothing but an uninvited middle piece stuck between the user and the ‘real’ data?
FileMaker is not intended to be a front-end to SQL database. You have said it and so does FileMaker, Inc. My clients don’t need to fool around wasting their time passing databases back and forth and synchronizing data when there are powerful tools to do it without those ‘hacks’ due to FileMakers inherent limitations. Taking the easy way to build solutions is not always the best shortcut. The FileMaker database itself is old baggage, its a hangover from by-gone days. Does it still ‘hunt’ data? Sure, within the limitations of the FileMaker ‘world view’. By, the way finding a single record out of a billion is no big deal for any database worth its name. I’ve never used one that can’t do that!
I can communicate with to my neighbors house with a tin can and string, I just think my cell phone works more efficiently. It’s not about being a darling to anyone…its about the right tool for the job in front of you.
Gary,
You make some good points about unified data management and enterprise requirements. However, isn’t it possible that the excessively high rate of IT project failures in enterprises, is an indicator that overarching control over information leads to a high incidence of rogue database solutions? Is it possible that departments are simply reacting to a lack of effective solutions?
I think it’s wise to create unified information architectures, but if there’s a high incidence of rogue solutions being created, it suggests the problem is not with the rogue database apps, but more likely with IT, its chosen technologies, and perhaps its approach to meeting business requirements.
Suggesting that FileMaker iPad apps are standing between employees and data is exactly the opposite of what I would conclude. If you stand in the departmental users’ shoes, there is no incentive to create rogue applications unless there is a lack of acceptable solutions to get their work done.
We also should consider the issue of agility. FileMaker (departmental-level) apps, both desktop and mobile, bring a degree of agility to the playground that cannot be achieved through most, if not all, enterprise IT groups. Information agility is now, more than ever before, the most important competitive advantage. Yet, IT organizations are unprepared to accelerate access to information in a mobile framework. Most projects are years away, and if they follow the current IT industry failure rate, only 3 in 10 will be used by enterprise workers.
“FileMaker Go … like crack… users want more.”
And we should punish this behavior? We should fear having IT solutions where users don’t want any information. Any model or approach that encourages workers to *want* more information should be observed closely and transformed into an enterprise mandate. IT should seize that addiction and find ways to integrate it, not eliminate it.
Hi Gary, thanks for the feedback.
Let me start with the “data island” position. I agree with you that inaccessible pockets of corporate data is bad. However, there are a variety of ways to grab data from FileMaker. There is JDBC, ODBC, or my favorite, SOAP Web Services, so there is no reason that FileMaker has to be an island.
When it comes to picking a developer tool, I’m going to restate your position, and see if you agree with me.
Instead of saying “The clients I deal with…would never allow a departmental power user to touch the corporate or business data with a tool being such as FileMaker”, how about this:
“The clients I deal with…would never allow a departmental power user to have write access to the raw schema of corporate or business data.”
Isn’t this true regardless of what tool they are using? If they can’t be trusted to have ODBC write access with FileMaker, do you think they’re likely to be more successful with Java, Servoy, Omnis, or (yikes!) C++? That’s an even worse recipe for disaster than FileMaker.
So if your real conclusion is that only people who really know what they’re doing should have read/write access to enterprise databases, then we are in agreement.
Let’s assume that we have now decided to only give professional software developers access to the corporate data, and we are moving on to the topic of what tool they should use. All of the tools you mention are good, and they will all get the job done. I have not used Servoy or Omnis, but I have used Java for a decade, and FileMaker for two decades. If the objective is to build a high volume web-based front end, I am going to pick Java. If the objective is a complex desktop application that is going to require a 20-person development team, I’d pick Java again so that I can assign each developer a module and API that they can implement.
On the other hand, if the job is to build a desktop application, and I am the only developer, and time to delivery is a priority (as it often is), FileMaker beats Java hands-down. If the job is to deliver the data on an iPad, then FileMaker wins again by a long shot.
As you say, it’s about picking the right tool for the job. FileMaker is the best tool for certain jobs, and not the best for others.
I think we are all in agreement on many levels. I just don’t (and this is my personalopinion) find, FileMaker Pro fun to work with. I’ve been ‘spoiled’ by the level of control I have as a developer in providing what my clients want. I don’t have the patience or time to struggle with a tool that doesn’t seem very logical at times or has many ‘given’ features missing that are present in other environments.
Time and time again, when trying to do something that is very easy in a slightly lower level language like ‘JavaScript’ or the Omnis scripting language, I have to perform gymnastics to do the same thing in FileMaker. All of the non-logical things I’ve encountered in trying to build something have frustrated me to no end. Not sure if the FileMaker developers really listen to their developer core, as there sure is a lot of complaining about the product if you Google on FileMaker issues.
So, I don’t think I’m alone in wanting more in a development tool I work with day to day. Yes, FileMaker has a place no doubt about it, and it may be the correct tool for some developers and the answer to some departmental solutions. I support an application that for many organizations is second in importance to their accounting system. It feeds that systems with millions of dollars of expenditures and revenues. We can’t allow that ‘departmental’ user to tap into that data from our viewpoint. We have moved from Omnis to Servoy because its uses recognized standards, unlike Omnis or FileMaker, or MS Access. It scales to any level and talks directly to big iron databases w/o some middleware databases between the GUI and the data. It brings Java power down to a 4GL level without any degradation in performance, and a huge increase in development time.
But, alas, the poor deprived iPad doesn’t support the JRE, like the new Motorola Zoom and Google 3.0, so we the more open hardware that can support a enterprise level front-end tool to corporate data. Maybe someone will write a nice tool for the iPad someday to do this, but today it doesn’t exists w/o the pain of Object C and XCode. I would much rather develop projects for the iPad. I guess there is always LiveCode iOS 5.0 with support for connectining directly to SQL databases and fast development?
I agree with Bill that many IT projects do fail because of the tools choosen. Our firm just doesn’t have that track record in the 25 years we have been around. But, we aren’t writing custom solutions for each client. We support a vertical that is mature and continues to improve with each iteration. Yes, FileMaker beats anything else out there for the iPad…at the moment. When the demand becomes great enough for developer tools that are fast and efficient at exposing ISV’s databases and corporate databases w/o fooling around with this unwanted ‘guest’ fo the FileMaker database in-between the developer and the task at hand, then it’s star won’t shine quit as bright as it does today. If this tool doesn’t emerge, then most of the corporate world will look hard at ‘open’ systems like Google based tablets and move on. Java isn’t going away because Mr. Jobs is having a hissy fit about it on ‘his’ devices.
In a matter of weeks everything we have developed for the desktop world in Java/Servoy will be up and running on a tablet from Motorola with just some minor adjustments to the layouts!
Hola, you know I was just surfing randomly and came across your rant. I 100% agree! But in general I think there will always haters and lovers. After all…That’s what makes the world go round… or is it around? Have a cold one for me!
Some interesting conversation however, I’m new to filemaker myself but have been developing using .NET for many years and even in my research and testing I have found Filemaker to be a highly scalable and enterprise capable system. But it depends on how you deploy it. Everybody is talking about the Go in Filemaker however what about the fact that you can connect to a filemaker server which would solve any sync issues also you could easily use an SQL server (mysql, mssql) as the primary datasource and have a data level (clustering able) and load balanced filemaker server cluster (middle tier and a little programming) and pc, mac and mobile based clients.
Because the primary data source lives in an SQL server it can be accessed directly by .NET, Java (etc) to deliver other applications. I am working on such a solution myself and it is 100% RAD based and uses a custom nTier RAD windows forms and WPF framework i developed a Silverlight nTier Framework (lightswitch) and DotNetNuke Web Application with webstudio installed to give it 2 Tier access to multiple databases and RAD in browser capabilities and then FileMaker and ALL it’s RAD capabilities.
Now one thing i would love to say to Gary is while your customers (the big governments, universities, big enterprises and what not) may be just as you say however, don’t fool yourself because their are MANY universities, government agencies and big enterprises that have deployed filemaker in their IT strategy and sometimes it is the primary tool in place.
Plus now that MS has release LightSwitch I would say Access Vs Filemaker comparisons are mute as LightSwitch and Filemaker are more alike then access ever was in capabilities. Just my Opinion.
Hey guys, looks like it’s been a while since someone posted on this article but there has been a new development on the Android / Filemaker front!
Saw this on a forum :
“Hello Everyone!
I saw this thread and wanted to let you know that I’ve just posted my own android app for accessing FileMaker dateabases. It’s not as pretty as FMGo, but it works for basic database access. You can find, edit, sort, download containers, and run scripts. You can also configure your database with some naming conventions so that you can control which layouts and scripts your users can run and see.
Check it out and let me know if you have any feedback or questions!”
Links to :
https://market.android.com/details?id=com.smefworks.android.fmdroid
Smefworks.com