Sunday 18 May 2008

What is this Enterprise GIS Thing?

I suppose if I am going to blog on about this topic then I should really lay out what it is I am talking about, so here goes. It is not going to be straight forward though but hopefully, as my ideas develop, I’ll be able to refine this over time.

“Enterprise GIS” is one of those terms that seems to have been around for a long time, at least since the late 1990’s but it has always had more to do with marketing hype than any commonly understood concept. During my time at Convergent Group in the US we certainly toted many solutions as being Enterprise GIS (and some were pretty cool) but today I am taking a different slant on the notion. To begin with I don’t believe that there is such a thing as “an Enterprise GIS” – that is, there is no single application or architectural component that provides all the GIS capabilities that a large organization could need.

In my experience the term is most commonly used for large spatial data repositories; hubs, warehouses and clearinghouses are often labelled as Enterprise GIS. These central stores of geospatial data can vary enormously in their sophistication, ranging from simple file shares that act as dumping grounds for file based formats, to spatially enabled databases fed by automated feeds from business applications. Repositories are often accompanied by metadata catalogues to assist potential users find and evaluate data – but in the end these are still read-only systems and only provide a subset of capabilities.

To me, the definition of “Enterprise GIS” is a set of capabilities (or services) that are baked into the software infrastructure (the ‘stack’) in order to be made available to any application that needs to use them. What are those capabilities? Well basically they provide the ability to work with spatial data i.e. to capture, transform, transfer, store, analyse, visualise, maintain, validate, manage, secure and distribute spatial data. ‘Baking them into the stack’ means that they are made available to any business application without any dependency on proprietary ‘fat’ desktop client software.

Thus it is not possible to purchase an Enterprise GIS; these capabilities need to be architected and assembled using a blend of platform software, supplemented by specific technology components from the specialist GIS houses. This involves careful selection of appropriate standards and policies to support data interoperability between applications and to enable reliable ‘Create Read Update Delete’ access to spatial data via any channel including desktop, web, sensor, mobile, EAI, etc.

Enterprise-wide GIS capabilities need to exhibit specific ‘enterprise class qualities’ i.e. they must be deployed in a server environment and possess the following qualities:

  • Scalable – they can grow to support volume and performance demands for current and future (unforeseen) needs;
  • Reliable – can operate in an unattended fashion to produce consistent and predictable results;
  • Available – can be configured to support High Availability e.g. support clustering and fail over;
  • Flexible – configuration can be changed to support evolving needs of the business with relative ease, i.e. without significant downtime or impact on business operations;
  • Secure – all access to data functions must be securable in line with corporate policies; includes support for directory services, delegation and encryption;
  • Measurable – it must be possible to monitor all aspects of the operation of these capabilities such that administrators can easily determine that they are functioning correctly and to support problem identification and resolution using standard tools (e.g. HP OpenView);
  • Standards-based – In order to support use by many applications, these capabilities need to be accessible via open standard protocols and formats;
  • Discoverable – in future posts I’ll explore this idea more, but the crux is that as we build a set of commonly available geospatial services, they will need to be described, and those descriptions made in an accessible fashion.

This doesn’t sound like GIS today, and in 20 years time may be redundant anyway as the capabilities are increasingly adopted by the major platform vendors. But at the present time I believe that providing spatial capabilities within the common platform is still a highly desirable and achievable vision.

Thursday 8 May 2008

1Spatial and Snowflake Conferences

In the past couple of weeks I managed to squeeze in the Snowflake GeoxChange conference in Edinburgh and the 1Spatial conference at Stansted. Both conferences turned out to be very good so chairman Peter Woodsford must be doing something right.

Interestingly the INSPIRE initiative featured heavily in both of them, the reason being that this European Spatial Data Infrastructure is an ideal driver for both companies. As public bodies across Europe will be mandated to catalogue and share vast amounts of spatial information in the near future, there will likely be the need to quantify data qualities so enable potential users to assess fitness for purpose (and at the very least not sue the provider); 1Spatial are positioning themselves nicely to provide the ability to do just that.

The company is actively involved in an OGC initiative to define data quality assurance measures for spatial metadata to enable data quality attributes to be reported consistently and its Radius Studio tool provides a means to profile spatial data to divine business rules, report conformance with them, and perform actions to improve data consistency. This looks like a nice niche that will enable data custodians to provide clearer descriptions of their data and assist potential users determine the extent to which it might meet their needs. I think that as practitioners get their head around this concept of spatial data quality auditing there is considerable scope for profiling and improving all those datasets that have come into digital existence in the last 15 years.

Snowflake's tools also look well set to support INSPIRE driven initiatives by enabling the encoding and decoding of spatial data packets in GML format. Given this government's preference for XML centric data exchange standards and even the emergence of Dutch legislation that goes as far as to enshrine GML into law (it's true but unfortunately for some strange reason the GeoXchange presentation that describes this is password protected); Snowflake's tools may have a bright future if they can plug into message backbones to enable the transport of spatial data within the new SDIs.