Skip navigation
All Places > Implementing ArcGIS > Blog > Author: SScher-esristaff

Implementing ArcGIS

2 Posts authored by: SScher-esristaff Employee

In your organization there are likely different people, working in a variety of roles, with varying skills and responsibilities. It can be overwhelming to deliver the right content in the right format to these different people in a well-performing, reliable, and secure manner.

 

Your geospatial content publication strategy serves as a guide to help accomplish this. While any two organizations can have vastly different publications strategies, an effective content delivery strategy will always address performance, reliability, and security.

 

Performance

Think of performance as how long it takes an application to load- is it lightning fast, or crawling along. One way to address performance strategically is to consider separating internal and external activities. In practice, this could mean external public applications like StoryMaps live in a scalable environment such as ArcGIS Online, and internal dashboards, analytics, and editing work stays on your own infrastructure in ArcGIS Enterprise. This way, if one of those public-facing apps suddenly becomes popular, your internal resources won’t have to compete for resources.

 

Reliability

Reliability is expressed in a service level agreement (SLA), and is an expectation of when the system will be available- like during work hours, or 99% of the time. There are many ways in which organizations address reliability, such as following other best practices like high availability, load balancing, workload separation, and security. You could also address reliability by leveraging cloud capabilities.

 

Security

Within the context of a publication strategy, security is about exposing the right content and capabilities to the right people. You certainly don’t want non-experts editing your asset information, or your sensitive data to be exposed publicly. This content should be properly maintained in a secure system of record. Security isn’t just about keeping your internal content within your organization; it can also pertain to information or capabilities that is sensitive even between departments or teams within your organization. Depending on the level of risk and sensitivity of this content, it may be appropriate to have a separate, internal publication environment.

 

 

While your organization’s individual content publication strategy will likely encompass many other considerations that are relevant to your work, goals, and mission, it should always address the needs and expectations of the people in your organization and protect your internal system.

 

Download the PPT for this presentation from the 2018 Esri User's Conference: Content Publication Strategy.pdf  

As technologists supporting important business functions, it’s important to do what you can to make sure that your organization’s production environment is protected.

 

What kinds of negative business impacts could you expect if your production environment failed? How much money would it cost your organization? How many mission-critical operations would be halted? How many customers or citizens would be affected?

 

Environment isolation will help protect your production system by creating at least three separate and distinct computing environments for operational, testing, and development activities. Let’s talk about how each of these systems help to protect your production environment.

 

Production Environment

Your production environment is the system that you are most familiar with. It’s your “live” system. It’s where most people in your organization go to do their work, whether it’s to access their mobile application to submit damage assessments around the city, or their desktop application to predict the structural integrity of buildings and bridges, or their dashboards to monitor the progress of their initiatives and projects. Because these people’s work is so important, it’s crucial that changes aren’t made here without first being tested and evaluated in a separate environment.

 

Staging Environment

Your staging environment is a replica of the production environment that isn’t supporting your business operations. This makes it a great, safe place to test an amazing new application your team has developed. This way you can be sure the app will deliver the functionality you promise and that nothing else in the system will be negatively impacted. It’s worth mentioning that many risk-averse organizations will have many kinds of testing environments, including a staging, performance testing, load testing, acceptance testing, and even training environments. The needs of your organization may differ depending on the level of risk you’re willing to assume.

 

Development Environment

Let’s get back to that amazing new application. That app was made in a separate environment: development.

This is a workspace where your developers can innovate. It’s where they can manage content, make changes, construct new business workflows, and create new capabilities. This environment’s size and complexity will largely be determined by how many developers you have working in this space and the level of risk associated with the kinds of changes they work on.

 

Needless to say, delivering a reliable, high-performing system is no easy feat. It takes a lot of diligent work done by smart, dedicated people. Isolating inherently risky activities like development and testing from your production environment will contribute to the stability and performance of that system.

 

Download the PPT for this presentation from the 2018 Esri User's Conference: Environment Isolation