GIS in the Rockies panel on Service Oriented Architecture (SOA)

As mentioned previously, last week I was on the "all star panel" at GIS in the Rockies, with a distinguished cast of characters. Joe Berry published his response, so I thought I would do the same. The following is based on the notes I made in advance, with a few edits to reflect changes that happened on the fly.

The six panelists were asked to spend five minutes each answering the following question: Do you agree that service oriented architecture (SOA) is the key to enterprise data integration and interoperability? If so, how do you see geospatial technology evolving to support the concept of location services and data interoperability? If not, what is the alternative?

My short answer to the question was that SOA is one of various elements which can play a role in implementing integrated enterprise systems, but it is not THE key, just one of various aspects of solving the problem. The preceding panelists had given quite varied responses about different aspects of interoperability and SOA, which was perhaps indicative of the fact that SOA is a bit of a fuzzy notion with no universally agreed upon definition. The one constant in the responses was that 5 minute time limit was not well adhered to :) !!

So in my response, I first tried to clarify what SOA was from my point of view (based on various inputs), and then talked about other aspects of enterprise integration and interoperability.

SOA is really nothing radically new, just an evolution of notions of distributed computing and encapsulating functionality that have been around for a long time. In fact, a reader survey of Network Computing magazine ranked SOA as the most-despised tech buzzword of 2007! SOA is an approach to creating distributed computing systems, combining functionality from multiple different systems into something which appears to be one coherent application to a user.

CORBA and DCOM were both earlier attempts at distributed computing. The so-called "EAI" (Enterprise Application Integration) vendors like Tibco (who existed since since 1985 as part of Teknekron, since 1997 independently) and Vitria (since 1994) pioneered many of the important ideas for a long time before SOA became the buzzword de jour. More recently the big IT vendors have been getting involved in the space, like Oracle with their Fusion middleware and Microsoft with Biztalk

In general, most commentators seem to regard SOA as having two distinguishing characteristics from other distributed computing architectures:

• Services are fairly large chunks of functionality - not very granular
• Typically there is a common “orchestration” layer which lets you specify how services connect to each other (often without requiring programming)
  

SOA is most often implemented using web services to talk to various applications, but this does not have to be the case. One thing that has helped adoption though is the widespread usage of web services, which owes much to the simplicity of XML. Back in early days of OGC there were three separate standards which didn’t talk to each other - COM, CORBA and SQL - and OGC gained a lot of momentum at the end of the 90s when it switched its focused to an XML-based approach.

Anyway, SOA certainly is a logical approach for various aspects of data integration with geospatial as with other kinds of data.

Now let's talk about some other issues apart from SOA which are important in enterprise integration and interoperability ...

Integration of front end user functionality
SOA is really focused on data integration (as the question said), but this is only a part of enterprise integration. Integration or embedding of functionality is important also, especially when you look at geospatial functionality - map display with common operations like panning, zooming, query, etc is a good example. There are various approaches to doing this, especially using browser-based applications, but still you need some consistency in client architecture approach across the organization, including integration with many legacy applications.

Standards
One key for really getting full benefits from SOA is standards. One of the key selling points is that you can replace components of your enterprise system without having to rewrite many custom interfaces - for example, you buy a new work management system and just rewrite one connector to the SOA, rather than 20 point to point interfaces. But this argument is even more compelling if there are standard interfaces which are implemented by multiple vendors in a given application space, so that custom integration work is minimized.

On the geospatial side, we have OGC standards and more recently geoRSS and KML, and there are efforts going on to harmonize these. The more “lightweight” standards have some strong momentum through the growth in non-traditional applications.

But in many ways the bigger question for enterprise integration is not about geospatial standards, it’s about standards for integrating major business systems, for example in a utility you have CIS (Customer Information System), work management, asset management, outage management, etc.

There have been various efforts to standardize these types of workflows in electric utilities - including multispeak for small utilities (co-ops), and the IEC TC57 Working Group 14 for larger utilities. Multispeak is probably further along in terms of adoption.

Database level integration
Database level integration is somewhat over-rated in certain respects, especially for doing updates - with any sort of application involving complex business logic, typically you need to do updates via some sort of API or service. But having data in a common database is useful in certain regards, especially for reporting. This could be reporting against operational data, or in a data warehouse / data mart.

Scalability
SOA approach largely (but not entirely) focused on 3 tier approach with thin client
Still for certain applications, especially heavy duty data creation and editing, a thick client approach is preferable for performance and scalability

Separation of geospatial data into a distinct “GIS” or “GIS database”
Enterprise systems involving geospatial data have typically had additional barriers to overcome because of technological limitations which required the geospatial data to be stored in its own separate "GIS database". Increasingly though these artificial barriers shouldn’t be necessary. All the major database management systems now support geospatial data types, there are increasingly easy and lightweight mechanisms for publishing that data (geoRSS and KML) ... so why shouldn’t location of customers be stored in the CIS, and location of assets be stored in the asset database, rather than implementing complex ways of linking objects in these systems back to locations stored in the “GIS” database? This is not just a technology question, we also need a change in mentality here - to spatial is not special, just another kind of data, a theme I have talked about before (and will talk about again!).

Summary
SOA is a good thing and helps with many aspects of enterprise integration, but it’s not a silver bullet - many other things are important in this area, including the following:

• Standards are key, covering whole business processes, not just geospatial aspects
• As geospatial data increasingly becomes just another data type, this will be a significant help in removing technological integration barriers which existed before - this really changes how we think about integration issues
• Integration of front end user functionality is important for geospatial, as well as data / back end service integration (the latter being where SOA is focused)
  
• There are still certain applications for which a “thick client” makes sense