Straws in the Wind Blog Articles
This article has been a long time in gestation. Sure, I could have written it anytime in the past 12 months, but it is just has not been in my top 10 jobs: paid work always takes preference to “labours of love”
The ESRI value-add conundrum
For anyone selling software in the GIS industry one question always seems to be foremost:
“How does the software integrate with what ESRI offers?”
with an important corollary question then arising:
“How does this add value to ESRI’s software and customers?”
(And in a way that doesn’t cause ESRI to enter your market.)
The FDO Value-Add
In Part One, “Radius Studio and FDO” I explained how quality open source software, FDO, could be used to add value to 1Spatial’s Radius Studio. That value can be summarised as follows:
In summary, this is the pre-eminent “value add”. To be able to concentrate on what you do best, correctly relegating generic data access componentry to where it should be: foundational.
This article is all about the question of how Radius Studio might value-add ESRI’s software and customers now that it can use FDO to access ESRI’s myriad data formats.
Recently 1Spatial discovered that having embedded FDO within Radius Studio they could now access ArcSDE based data with little or no engineering effort. (The first integration they conducted with FDO was with shapefiles.) As Chris Tagg observed in an email to me: “It just works”. I suspect they also will discover that, via the FDO OGR provider (and any others that may get created), they can access personal geodatabases as well. The latter is important because it is likely that the greatest amount of spatial data being managed by ESRI software is in personal geodatabases.
But does being able to read someone else’s proprietary format data holdings add any value to ESRI?
From ESRI’s perspective the answer is “not really”. Why? Well, will having such capability sell any more ESRI licenses to customers? No. Being able to read data is also not a basis for being a business partner (even Manifold GIS can read shapefiles, personal and enterprise geodatabases – without the use of FDO – and they are very much in the anti-ESRI camp). And has such a capability helped current ESRI customer improve their return on their ESRI software investment? Unlikely.
Is being able to write the data back to ESRI database formats a value add?
If writing back the data occurs via back-door methods (eg reverse-engineering of the format), then the answer is definitely “no” as it places the customer and vendor in a difficult situation with respect to ESRI support. For example, writing an invalid shape into an Enterprise Geodatabase can cause queries against that database by ArcSDE to fail (as all geometries extracted in a query are validated by ArcSDE). If the customer then lodged a support call and ESRI Inc discovered that a third-party application caused the issue they would rightly insist that the offending software be removed.
Fortunately, FDO’s ArcSDE provider uses ESRI’s published method for accessing ArcSDE data: the ArcSDE API.
But writing data can be seen as a value-add where the product vendor provides a product that ESRI itself does not. So, being able to write clean GPS data from, say, Trimble Pathfinder Office directly to an ArcSDE database would be seen as a value add if it used the ArcSDE API and is obviously from a market segment ESRI does not directly compete in.
1Spatial and ESRI: more than just data
But what about 1Spatial? It can read, and write, ESRI ArcSDE and other proprietary format data. And, fortunately, for ArcSDE, that writing occurs via ESRI’s own API (so is “support friendly”). So they have capability in data interoperability but they are not an ESRI business partner; they own no ESRI software; they have not created any “extension” products for ArcGIS or ArcGIS Server; in fact they directly compete against ESRI in a host of areas: database cartography, object oriented GIS, topology.
So, how can they value-add ESRI in a way that is non-threatening?
Technology Stack: The Geodatabase
Integration of Radius Studio and ESRI data technologies is more than just the reading and writing of a particular proprietary storage formats though particular APIs i.e. ArcSDE. Rather integration needs to consider the whole of the ESRI “technology stack” and their positioning of that technology in the marketplace.
The ESRI “technology stack” is predominantly a style of Model Driven Architecture (MDA) based on their “intelligent feature” Geodatabase technologies.
The Geodatabase is more than just a bucket of geographic data, it also implements sophisticated business logic that, for example, builds relationships between data types, such as topologies and geometric networks; validates data; and controls access.
Within the ESRI system, the proprietary spatial data formats (shapefiles, SDEBINARY, etc) and data access technologies (ArcSDE, Jet, APIs) are glued together through a common generic geospatially aware semantic model that is stored and managed within the metadata repository components of a Geodatabase. A fully defined Geodatabase should include all the rules that are necessary for defining, controlling and validating data quality and integrity. ESRI client technology such as ArcGIS, ArcEngine, ArcServer dynamically use those rules (though generated code) to control data editing.
ESRI’s preferred method for the construction of Geodatabase models is to use a UML CASE tool such as Microsoft Visio and Rational Rose which it has extended with a set of modeling templates that enable customers to model some of the spatial aspects of a Geodatabase. Once modelled, a design can be “forward engineered” to the Geodatabase persistent data store (via the ArcCatalog Schema wizard) with “behaviours” being generated for use within the ArcGIS technology via the Code Generation Wizard.
However, it would appear that while many ESRI customers have purchased all the software components necessary to build an intelligent Geodatabase, they do not have the in-house skills to use UML to define a Geodatabase structure, or the skills to conformance check and migrate their data. Because of this, ESRI and other “domain experts” have developed, and made available for download, “starter data models” which customers can use as templates to “kick start” their Geodatabase creation (see http://support.esri.com/datamodels). These models are already “spatially aware”. However, when a customer uses one of these models, converting existing spatial data such that it conforms to the model is a manual process.
Until an ESRI customer has a fully specified, semantically rich, Geodatabase populated with quality data, they cannot leverage the “intelligent features” promise in the ESRI stack of technology. Until they do, their Return On Investment is sub-optimal.
The Radius Studio Value-Add.
Given this understanding of the Geodatabase technology, leads to a number of possible areas in which Radius Studio could deliver significant return on investment (ROI) for ESRI customers.
Firstly, Radius Studio is designed to be “domain expert” friendly. One does not need to know anything about UML to be able to discover and define rules.
Secondly, by reading in the semantics of a “starter model”, Radius Studio could conform a customer’s existing spatial data to a chosen ESRI data model.
Thirdly, since no generic “starter data model” reflects the idiosyncrasies of any one business’s rules or operating envionment, Radius Studio, through its ability to automatically discover new rules, could enhance a “starter model” through examination of a customer’s specific data.
Finally, having conformed the data and discovered new rules, if Radius Studio had the ability to write the rules and conformed data to the ESRI Geodatabase metadata catalog (via the XML Schema of the Geodatabase) this could give ESRI customers an enormous “leg up” in their migration activities, but more importantly will enable the customer owning the ESRI technology, to use all the “smart feature” capabilty of the whole technology stack, delivering much faster ROI than they could otherwise expect.