Quick Take Product Overview: Safe Software's Feature Manipulation Engine (FME) - Features

Directions Magazinewanted to recognize Safe Software's 10 years in business. We also wanted to get an overview of Safe's FME technology and what is in store for the products in light of the coming adoption of .NET. We interviewed Safe CEO Don Murray and Dale Lutz , vice president of product development to get the answers:

1. Why do you think a market developed for Safe Software's Feature Manipulation Engine?Data Interoperability has long been a problem in the GIS community. For many years, sharing data between systems was prohibitively difficult with many organizations having their data locked in proprietary formats. This is the market that the Feature Manipulation Engine (FME) has targeted. The database community has long had a market called Extract, Transform, and Load (ETL) -- FME is simply an ETL tool for spatial data.

The other key factors in FME's success include:FME does a complete and thorough job with formats. In addition, users are in complete control of the comprehensive support FME provides for each format.Safe Software has an unwavering commitment to customer service.FME is based on a solid architecture that has scaled well to include over a hundred formats, and has handled increasingly large data volumes.Support for high-end systems in addition to common lower-end formats provides great value to enterprises of all sizesMany users find the product "fun" to use. As an Austrian customer said, “FME is software that makes you want to use it more.”Because of its flexibility, FME not only solves tough data exchange problems for users, but does so in a way that greatly increases their productivity and saves them a large amount of time and money. Customers get excellent return on investment.2. Do you think that open standards and interoperability was driving factor for adoption of your products?The move to open standards has certainly helped sell our products as we provide a gateway to an open standard such as GML on the source system and from GML to the destination system. Standards such as GML are rich transport formats enabling any kind of data to be moved from one system to another, and to be used properly require the completeness and flexibility of a tool like FME. The FME in fact began as a product to move data in and out of the Spatial Archive and Interchange Format (SAIF), an early 1990's open standard, which some have called the grandfather of GML.

3. Is interoperability being demanded in the marketplace?

Definitely. We have many clients that have multiple GIS systems as a result of mergers or acquisitions or just for business reasons. Interoperability provided by products like ours enables users to pick the best product for different tasks. We are seeing databases from one vendor underneath web mapping systems from another vendor, and it is our technology that is being used in many cases to make this happen. As tools become more specialized and advanced, it is less likely that one-size-fits-all and consequently organizations end up with a diverse environment that requires interoperability.

4. Do you believe that the Open GIS Consortium is doing their job to effect standardization?We feel that the Open GIS Consortium is a positive influence in the GIS market. In creating GML-2 they have performed the remarkable feat of coming up with a GIS data standard that has been adopted throughout the world. Without the OGC, this would not have come to pass. The Web Feature Server (WFS) and Web Mapping Server (WMS) standards definitely fill a void and have focused efforts in these emerging areas in a very positive way.

5. Given FME's adoption among a broad base of GIS application software, how will it evolve as more vendors improve their product with more translation features?We recognized quite early that the vendors would add many of the formats directly. To ensure that our technology is used in as many cases as possible, we have quite an aggressive FME Objects OEM program that enables third parties to embed our technology within their own. FME itself will continue to be focused on the Spatial ETL market and be best-of-breed for sharing data independent of format in ways that other traditional tools are not set up to accomplish.

6. How do you develop different data model translations? Will you, for example, take different vendor data models and translate them to other vendor or database models? How does it work?We have two types of translations. The first is calledgeneric, also called thin-pipe translation where the data is automatically moved from one vendor product to another. This adds little or no value to the data but provides a quick and easy way to get data from one system to the other.

The second is calledsemantic, also called thick pipe, translation in which case users make use of our GUI-based FME Workbench translation and transformation development environment. Within this environment, users are able to restructure data, combine data from different data sources and formats all at once. Workbench is the environment that really makes FME be the ETL tool that it is.

The key to the whole thing is having a very flexible representation that completely characterizes all aspects of data being read, and then providing an environment for manipulating all of that in to the schema of the output system. Enabling users to see their data models before and after the transformation, as well as the steps taken during the transformation, is critical in many situations.

7. What is future path of FME on a .NET framework?FME also comes with a programming API enabling programmers and vendors to embed our technology. The current version of FME (FME 2003) ships with a .Net interface that enables users to leverage our technology using any .Net language such as C#. Other languages that are available are C, C++, Java, and Delphi. In the future, we are looking at ways to take advantage of .Net Web Services to open up our technology to other uses.