To implement ArcGIS Online or Enterprise, and organization needs to be a paying customer with ESRI.
Each customer gets access to ArcGIS Online, will have one or more users and some service credits. All of this is dependent on the size and needs of an organization. An organization can always add on more as they go or perhaps they need to obtain and End-user License Agreement (ELA).
Enterprise may or may not be needed, again, dependent on the organizational needs. Some organizations don’t need to stand up and administer an on-premise instance of AGOL (Portal) and the related components. If an organization does, there will be some additional requirements for this. The table below summarizes these.
- User names may be the same or different between ArcGIS Online and Enterprise (mostly likely, some differences), AGOL users are different from Portal users.
- Service credits are provided to the “Organization.” Credits typically are used when ESRI cloud-based (AGOL) storage, services, analytics are consumed from the ESRI cloud. Credits, typically are NOT consumed when viewing, editing, storing, or using services exclusively within the organization (Portal) and are NOT ESRI cloud services.
|ArcGIS Online||ArcGIS Enterprise|
|ESRI Organizational Account||ESRI Organizational Account|
|User Accounts||User Accounts|
|Service Credits||Service Credits|
|On-premise server or cloud instance|
Once AGOL and/or Enterprise are “stood up,” someone (this can be several staff) will need to administer and oversee the platforms are running and functioning as expected.
On the AGOL side, the “technical management” is taken care of by ESRI. An administrator typically manages users, permissions, may tweak the look and feel of the public Open Data Portal page, and troubleshoot issues if map layers, maps, and apps don’t function as expected and may need to consult with ESRI as needed.
On the Enterprise side, administration will be more involved, especially, if the GIS team manages the back-end servers, security, databases, etc. The GIS Admins may partner with internal (or possibly external) IT support, depending on how IT is managed in the organization. Tasks can include installing and updating Portal, database setup and management, troubleshooting, testing updates, organizational security protocols, supporting and troubleshooting GIS and end user issues with map layers, maps, and apps.
Ideal “best practices” for internal IT support (whether within the organization or on a hosted/private cloud) is to have a Development, Test, and Production environments to minimize downtime for systems and end-user experiences. Typically, the following occurs:
- Development – test new procedures (installs, upgrades, patches, new functionality, etc)
- Test – essentially, the system set up is the same as the Production system and can use “beta testers,” “power users,” etc to test out the new system, functionality, etc across the entire platform to ensure the changes don’t break existing systems or protocols
- Production – the actual “user system” for daily/normal functions. When the Production system is updated/upgraded, etc, there is often “some downtime” to the end-user unless the organization has redundant “systems or nodes” to implement change and minimize or eliminate downtime for end users.
Some organizations can’t afford an IT practice like this. If the Development and/or Test environment is not available, then the organization can face an increased risk to longer periods of downtime and higher direct impacts to end-user loss of productivity. Smaller, less complex organizations may not need this 3 tiered system.
|Administer – users, permissions, groups, roles, Open Data||Similar to AGOL (Portal)|
|Publishers/Creators – create content, map layers, web maps, web map apps||Create/Manage web services|
|Users – use maps and apps||Install/Update Portal on premise|
|Custom roles – based on capability, need, security||Manage on premise hardware, software, IT security|
|Manage web server and web adapter|
|Manage hardware, software, security (internal, external, 3rd party apps)|
Data (Layer, raster, storage, etc management) can take many forms. The majority of “data” are the feature layers (created directly in AGOL or Portal or from Pro). Other options can be implemented/used, depending on the need and source of the data. Also, keep in mind that “Web GIS” is not “Desktop GIS” so all of the cool, wiz-bang things we can do with a desktop GIS we won’t necessarily do or can do in the web platform. When using AGOL or Portal, we are providing information over web services, through the internet, not just on our desktop or local network. Keep styling simple. You may or may not need to use labeling, configure pop ups well, use filtering when beneficial.
- Don’t use shapefiles! As noted earlier, no benefits for web
- Do use file geodatabase for on-premise data management and as a surrogate or precursor to migrating a data management practice to Enterprise SDE data management
- Do use Enterprise SDE if it exists and is part of a normal organization data management practice
- Standardize attribute schema (i.e. data field names, types, attribute domains). Remember, attribute domains become drop down lists in AGOL/Portal.
- Use simple styling in web maps (highly likely, labels may not be needed or sparingly and only at certain zoom levels). Pop ups, essentially, take care of the need for labeling in a dynamic web map environment
- Mostly likely create individual feature web layers from individual feature classes
- Can upload CSV (comma separated value) files to directly create feature web layers, provide lat/long fields exist
- CSV with address columns (note – full street address, city, state, possibly zip field are likely needed) can be geocoded to create feature web layers. NOTE: Geocoding takes service credits when using the ESRI world geocoded, especially, on AGOL. On premise, some organizations have their own geocoders that don’t consume credits.
- Can upload GXP gps files to directly create feature web layers.
NOTE: CSV and GXP are typically “one time” efforts. If these file types are recurring in your organization, it is recommended to build a data management practice to possibly automate or eliminate these “flat” type data sources. Getting data into file geodatabase or SDE stand alone tables are much more directly useable when working in a GIS and for publishing/overwriting web layer services.
- Consider overall workflow activities. If these are not known, one or more meetings may be required to determine what the necessary workflow is for data management.
- Can the data/layers stay in the ArcGIS Online Cloud or does this data also need to exist or be managed internally on internal networks, databases, systems?
- Build processes that transfer data to/from the cloud. NOTE: This can be difficult an may require custom coding in Python (Python scripting for ArcGIS and/or using the API for Python).