One of the most powerful features in AIMS is the ability to point it at pretty much any spatial data source and then diplay that data in a map. For one of our large enterprise customers this was fantastic as they had data being managed by a variety of in-house and external systems that they wanted to bring together into their AIMS solution.
The problem we found with giving AIMS direct access from to another system's spatial database or SHP file store was the potential performance impacts on the source system. Given that these systems ranged in business criticality we found that the Application Owners were reluctant to let AIMS have open slather access to their data, even if it was only for querying. When it's all said and done, using AIMS it is possible to theme your spatial data in such a way that it will cause a significant database hit, just like you can with a bad SQL query.
So we ended up advising on an architecture something like this...
Notice that the external data sources supply data to the AIMS database or fileserver, essentially making the total AIMS solution a data wharehouse.
This gave us the added ability to 'process' data on the way in.
We could also do things like joining data from various sources together selectively in our database - this doesn't work so well when set up through AIMS Studio.
We could also optimise the data for viewing - especially in the database where you can create both spatial and standard indexes to accelerate things like Layer Filters and Themes.
An architecture like this gives you great control over the data that AIMS is consuming. The tricky bit is how do you keep data current? But that's for another blog post!
Comments
You can follow this conversation by subscribing to the comment feed for this post.