 
|
FileMaker - Development Guidelines
ITAG Standard #12: I/T teams need to follow the I/T development guidelines for internally developed and purchased vendor products.
Fitting in the MIT network
You should design and implement your application with an eye toward seamless integration with the MIT network. Build for supported platforms and secure your application on MIT's open network. You should also be mindful of what it will take to support your application once it's been deployed and how it might need to integrate with other MIT systems.
Avoid plug-ins
There are many plug-ins written for FileMaker that can extend its capabilities. However, every new piece of software that you add to your application increases the amount of cost and maintenance required to keep your system going each time any component is upgraded by its manufacturer. With the frequency of new versions for FileMaker itself, that means waiting for and testing and purchasing and deploying a new version of each plug-in you incorporate in your solution. For that reason, you should limit the use of plug-ins to those which truly add required functionality, and which functionality can't somehow be built into your application through its own capabilities and features.
Integration
Very rarely does data live in isolation in FileMaker. Usually data comes in from somewhere and often gets exported to yet another system. In fact, throughout the Institute, FileMaker is an integration point for data from several other sources, from enterprise systems like MITSIS to paper application forms to email messages. The more you standardize and automate the movement of your data, the greater its accuracy --not to mention the savings in data entry labor.
If you are entering Institute data into FileMaker from an enterprise system like SAP, you should probably access it via odbc from the Data Warehouse, rather than duplicating it locally. Almost any staff, financial, or student data you might need is stored in the Warehouse and can be viewed via your FileMaker database, without the added steps and security risk of querying with Brio and generating text or Excel files for import. A Warehouse account, a properly configured odbc driver, and a little knowledge of the backend system is all you need. Of course, both the connection and access to the application must be secure, since most staff and student data is typically sensitive and protected by federal law.
With the introduction of the External SQL Sources (ESS) feature in FileMaker v9, you no longer have to import the data to access it. As a developer, you need to consider carefully which data elements you should import and store, and which should just be viewable via ESS. The less data you store the better, for two reasons:
- Stored data quickly loses its "freshness" and will need to be purged and re-imported to preserve reliability
- Storing sensitive data comes with the responsibility and liability of protecting it adequately.
Most reporting needs can be met by viewing rather than importing data. However, there will be times when you need to store data. Typically you will only need to store data that you need to manipulate, that doesn't change often but you need to reference often, or is so voluminous that it impacts performance when you access it real-time.
Storing sensitive local data should be avoided. Any non-enterprise system that must house sensitive data for departmental business reasons should be hosted in a professionally managed environment. Hosting your system through a contract with any of the several hosting services offered through IS&T insures that appropriate action can be taken in the event of system or server failure or compromise.
