Geodatabase Replication vs Web Services

[LeoDonahue]

I would like to make an argument (in general) that Geodatabase Replication is still useful for sharing data over a network to a distributed group of users.

As a means to share data, are people finding Geodatabase replication still useful as a means to share data from a central repository to regional locations (locations outside of your office)? 

Or is everyone finding that web services are replacing this data sharing methodology?

I would expect that consuming feature services which contain many thousands of records can have the same effect as sharing that data across a network as a simple file share. If that is plausible argument, then I think Geodatabase Replication still has its place. 

Internal Geodatabase Replication will probably always have value, but I wanted to focus on using that model to share data outside your location, as opposed to web services.

Opinions?

[WilliamCraft]

Good discussion starter.  The use cases and underlying business requirements for geodatabase replication and those for publishing/consuming web services can be entirely different; in fact there may be times where both solutions are used but for entirely different reasons.  In other words, they may serve different purposes altogether.  There are many reasons why one of those two solutions might be best for your needs depending on the end goal.  For example, geodatabase replication might be a good choice if you need the data to exist in a second location for backup or DR purposes.  Additionally, the replica can serve as the source for GIS services while the primary database can be the place where edits occur, thus reducing the load on the editing geodatabase.  Another reason for the use of replicas is to provide mobile users with the data they need in a distributed work environment where they can't connect to the network from the field but can connect at the end of their shift when they return to dock and sync their field units.  On the other hand, Feature services can be great for mobile users who perform basic web editing in a wireless-connected environment.  It all depends on the complexity of your environment as to what solution is best.

[LeoDonahue]

Thanks for the reply William.

I was posing this question mostly to see what direction people are going - Replication or Feature Services as a means of getting data from producer A to consumer B.  We have been using Geodatabase Replication for awhile.

Either requires a connection to a network.  The difference being that Geodatabase Replication occurs on local data whereas a Feature Service might have started out as an empty local FGDB, but then uploading it to the ArcGIS Online area and performing edits on that data from there.  The result I think is the same(?), the updates to the data being consumed are transparent to the end user.

[WilliamCraft]

I might just not be understanding enough about what you're saying.  If you make edits to the data stored in AGO, how are those edits going to be merged appropriately with your enterprise geodatabase?  I can understand the decision to export a subset of data from ArcSDE and upload it to AGO on a periodic basis for sharing, consumption, etc. for viewers.  However, if your GIS system of record IS the enterprise geodatabase and you allow edits to occur to a copy of the data via AGO using feature services, won't the data become disparate between AGO and your instance of ArcSDE?  On the other hand, if you are saying that edits via AGO wouldn't be merged back into your enterprise geodatabase then that is different.  From a consumption standpoint, I agree that the outcome and end-user experience might be the same whether the data is stored in a geodatabase replica or whether the data is stored in a FGDB within AGO.  The user should really not have any idea of the storage source behind what he or she is seeing.  But, to me, comparing the two approaches is somewhat like comparing apples to oranges unless storing/editing data in AGO replaces the enterprise geodatabase entirely.  The mechanism by which updates/edits/refreshes are made to the data viewed by the end user HAS to become part of the discussion since it has bearing on how the solution is architected.  I don't think you can really separate the data updating from the data consumption from the perspective of an overall solution.  But again, if you are saying that AGO would be the repository for all data thus replacing ArcSDE then I may have misunderstood.

[LeoDonahue]

I might just not be understanding enough about what you're saying.  If you make edits to the data stored in AGO, how are those edits going to be merged appropriately with your enterprise geodatabase? 

They won't be. AGO will be "in place of" your enterprise geodatabase distribution methodology.

I can understand the decision to export a subset of data from ArcSDE and upload it to AGO on a periodic basis for sharing, consumption, etc. for viewers.  However, if your GIS system of record IS the enterprise geodatabase and you allow edits to occur to a copy of the data via AGO using feature services, won't the data become disparate between AGO and your instance of ArcSDE? 

I'm saying, with the inception of editable AGOL feature services, and the push to use them, is anyone considering sharing data via AGOL feature web services instead of Geodatabase Replication.

On the other hand, if you are saying that edits via AGO wouldn't be merged back into your enterprise geodatabase then that is different.  From a consumption standpoint, I agree that the outcome and end-user experience might be the same whether the data is stored in a geodatabase replica or whether the data is stored in a FGDB within AGO.  The user should really not have any idea of the storage source behind what he or she is seeing.  But, to me, comparing the two approaches is somewhat like comparing apples to oranges unless storing/editing data in AGO replaces the enterprise geodatabase entirely.  The mechanism by which updates/edits/refreshes are made to the data viewed by the end user HAS to become part of the discussion since it has bearing on how the solution is architected.  I don't think you can really separate the data updating from the data consumption from the perspective of an overall solution.  But again, if you are saying that AGO would be the repository for all data thus replacing ArcSDE then I may have misunderstood.

That is what I'm asking in general.  Do people see an advantage to replacing data sharing via Geodatabase Replication with AGOL feature services.

The point of Geodatabase replication being: physically move data from location A to location B.
The point of AGOL feature services being: just connect to my URL and pull the data into your local ArcMap when you need it.
(this is alot like publishing your own geodata service, except users of AGOL probably don't have ArcGIS Server)

The process of managing AGOL feature services vs managing Geodatabase replication is where I see advantage going to traditional Geodatabase Replication.