Implementing An Enterprise GIS Project: Lana Tylka Jennifer Prather Craig Venker

Implementing an Enterprise GIS Project
Lana Tylka
Jennifer Prather
Craig Venker
July 9, 2017
Introductions
Lana Tylka
Jennifer Prather
Craig Venker
Implementing an Enterprise GIS Project 2017 2
Introductions
Name
Organization you represent
Typical Project Size

The purpose of this workshop is to
provide you with an
understanding of the Enterprise
GIS implementation process and its
components
Agenda
8:30 – 9:00 Opening and Introductions
9:00 – 9:30 Case Study
9:30 – 10:30 Vision, Goals, and Objectives
10:30 – 10:45 Morning Break
10:45 – 11:30 Assess and Plan
11:30 – 1:00 Lunch Break
1:00 – 2:00 Building IOC
2:00 – 2:15 Afternoon Break
3:30 – 3:45 Afternoon Break
4:30 – 5:00 Evaluate, Review, and Plan Ahead
• Sign up sheet
• Class materials
• Questions
• Break and lunch times
• Bathrooms
• Evacuation procedures

Course Scenario
https://www.youtube.com/watch?v=_3MyyiuPAqE

Ordering
Crop Health
Crop Scout Imagery
DASHBOARD
Suggestions
Product 3rd Party
Selection History
Yield Data
Yield
and
Data Weather Data
Analysis
Management
Weather
iPad App
Admin Site AGOL
iPhone App
UI/UX Performance Maintenance Management

Assess the Following Components
Evaluate, Review, and

Vision, Goals, Objectives Assess and Plan Building an IOC
Plan Ahead

How to Start…
Discuss similar
industries Create a plan
Assess
workflows
Prioritize
workflows Choose
Conduct
a life cycle
kickoff meeting
6
5
Launching your Location Platform Guide:

www.esri.com/LaunchGuide

Implementing the Platform
Rapid Deployment of Initial Operating Capability
Desktop Web Device

Foundation Apps
Essential Information Products
Portal
“GIS Ready” Data Server Online Content

and Services
…COTS configuration for quick results
Implementing the Platform
Realization of an Integrated Enterprise System
Desktop Web Device

Extended / Custom Apps
Portal Integration with

business systems
Advanced integrated
workflows
Content Production Systems

Server Online Content Data modernization
and Services
…Reaching across the enterprise with lasting success
Patterns of Implementation
Initial Operating Capability Integrated Enterprise System
Desktop Web Device

Foundation Apps
Essential Information Products Extended / Custom Apps
Portal Integration with

business systems
Advanced integrated
workflows
Content Production Systems

“GIS Ready” Data Server Online Content Data modernization
and Services

Beck’s Platform Vision
Customer Agronomic Sharing and In-field Integrated Customer-driven
Engagement Analysis Collaboration Management/ Imagery Reporting
Decision Making Management
Beck’s Platform
Strategy
ArcGIS Server Image Server 3rd Party Data

Integration

Exercise <Your Agency Name> Platform Vision

Considerations GIS is really about the data
What already exists? What’s next?
Who are the potential end-users of your data?
What are your data retention policies?
How does growth of the project affect your data?

Geodata Management Strategies
• Separate production from publication environments!
• Make Data Owners responsible for (and proud of) their data.
• Structure data to optimize for your information products
• Consider your deployment environment (Web? Desktop? Device?)
ArcGIS for Server
Data Creation Production Publication

Workflows Geodatabase Geodatabase
Online Content
Versions Tuned for Editing Tuned for Services
and Services Replicas

Geodata Management Best Practices
• Design and group data according to maintenance and security policies, not the
application using it
• Feature datasets are for topologies and networks, not to make data look pretty in
ArcCatalog
• Don’t overthink your QA and versioning to avoid paralysis by analysis
• Consider a default-open strategy
• Don’t recreate or re-host data from external providers if possible
• Host heavily-used data and services in a cloud environment to reduce performance
impacts

Base your
Infrastructure Who are your users?
Decisions on
Facts
How much usage will there be?
What are the existing limitations of your systems?
Are you ready for/interested in the cloud?
What happens in the future?

Key
Things to Think About
Infrastructure &
Deployment
Considerations ArcGIS Server ArcGIS Online
• Cloud Hosting vs. On-Premises
• Security: Access, Authentication,
Auditing, Standards
• Network Access
• Reliability Cloud Hosting
• Mobile Device Access Local Hosting
• Contractors, 3rd Party and Public

• Existing users, apps, infrastructure Portal for
ArcGIS
• Databases and storage types
• Physical vs. Virtualization

Using the • Cloud Deployments
Cloud vs. • Reduced capital expenditure
“Your Own” ArcGIS Server ArcGIS Online
Infrastructure • Reduced maintenance
• Rapidly scalable
• Many ready to use resources
• Many deployment options
• Trend is to the Cloud
Cloud Hosting
• Managing your Own Environment
Local Hosting
• More control, but also more management
• Security: Inside firewall (but the cloud is
inside a firewall too) Portal for
• Network: LAN is faster than WAN ArcGIS
• Reliability: Not affected by Internet outages

Web GIS
Cloud Deployment Models
Deployment
Patterns
Source: trust.arcgis.com
• Security
Key
Considerations - Confidence that your customer data
and organizational data is safe
• Authentication
- The GIS needs to ‘know’ who you
are, and trust that you are who you
External
say you are
trust.arcgis.com Inside your Firewall
• Authorization
- Separation of roles and
responsibilities
- Least Privileges Model

Who are your
Users?
• Internal Users
- Usually your first tier of support
- Everything ‘works’ in the office External
• 3rd Parties
Inside your Firewall
- Contractors, outside consultants,
neighboring organizations
• External users
- How does the public interface with your
GIS? How do they make use of your data
and services (if at all)?

Data Storage • Where is your data now?
and Usage
- In an enterprise geodatabase?
- On a highly-available file share?
- In an existing business system?
External
- On someone’s laptop?
- External Hard Drives? Inside your Firewall
- DVDs?
• Priorities
- Quality
- Availability
- Redundancy

Assess Your • Whatdata is needed to support the key
Current Data business needs
Flows
• Whatare easy GIS data sets that can be stood
up quickly or are already accessible
• Who is responsible for/owns which GIS layers?
• What are the data exchange protocols?
• What is the format of the GIS data?
• Arethere any GIS data standards in your
organization?
• What security is associated to your data?
Publish • Web Services and Map Services are essential to Web
Data
GIS and modern mapping workflows
• Design services around data, not around application:
reusable, flexible, optimized
• Consider services the primary data access method
• Make data application-agnostic and easily understood
• Be ready to leverage outside data and services in your
information products

https://www.esri.com/~/media/Files/Pdfs/products/arcgis-
System Architecture: platform/architecting-the-arcgis-platform
Leverage best practices: ex. Environment Isolation
Development Staging Production
Portal
Caching Visualization
Server(s)

Exercise <Your Agency Name> Platform Vision
Update with what you have learned…


Plan Ahead

Assess and Plan
Supporting Project
Contracts Risks
Team Lifecycle

Capacity
Capacity of Human Resources, organization and staff
Historic usage and expected future growth
Monitoring and Testing
SLAs and the impact of over-capacity

• Does your organization have enterprise software
Assess your implementation experience?
experience
• Does your organization have GIS implementation
experience?
• Does your organization have the necessary
talent with knowledge to meet the roles and Enterpris
responsibilities?
Server &
database
focused
Desktop
focused
Getting
Started Implementing an Enterprise GIS Project 2017 33
• Hardware is cheap, experience is expensive
Assess your • Servers are easy, network is hard
current IT/GIS
capacity • Beware of key components that you don’t control (NAS,
firewalls, web accelerators…)
• Understand your vendor relationships
• Trust anecdotal information but verify

Assess your
organization’s
willingness to
• Who will be impacted by Enterprise GIS changes?
change
• How will they be impacted and how will they
respond?
• Whatmitigation options are available for negative
impacts?
• Plan your strategies carefully & engage
• An Agile approach can be a massive transition
• An Agile approach can yield earlier successes

Identify roles, • What roles are needed to implement the Enterprise GIS?
resources and • What would be their responsibilities?
their
availability • Identify in-house or contractor resources to potentially support
the project as overseers or implementers
• Document roles, their responsibilities and candidates
Account specialists
GIS analyst Database specialist
Technical lead
Subject matter experts
Program manager Field collection specialist
Business Analyst
System architect Project manager(s)
SOE programmer
Legal expert Contract specialists

• List your assumptions
Formulate
your • List
roles, responsibilities, potential resources and
capabilities
and gaps gaps
• List HW, SW and implementation gaps
• Identify mitigation options
Known Gaps Can Drive Requirements

• Test your GIS for performance (More this afternoon)
- So you know when it’s out of compliance
Test and
• Monitor system metrics and availability
Plan for
- So you know about problems before your customers do
Growth
• Create 1/3/5 year plans
- To ease staff augmentation, hardware and software acquisition
• Stay current on software versions

- Operating System, ArcGIS Platform, Database instances, 3rd party applications
Known Gaps Can Drive Requirements

Assess and Plan
Supporting Project
Contracts Risks
Team Lifecycle

Build for Value
Requirements evolve over time
20% - Often or
Always
Always
7% Often
13%
Never
45% Sometimes
16%
Rarely
19%
64% - Rarely
or Never
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

How Requirements, Technology Affect your Choice of Project Lifecycle
Far from
agreement
Certain
Disaster
Requirements
Agile
Waterfall
Close to
agreement
Close to Far from

certainty
Technology certainty
Project
Lifecycle
Types
Plan Agile/Scrum
• Just in time
Design Staged requirements,
design
Build • Upfront
• Short duration
requirements,
Use design sprints
Waterfall • Prototypes • Continued
Grow • Sequential • Incremental
releasable
product
Steps deliveries
• Single Release

Agile Manifesto
We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,

we value the items on the left more.
Agile Manifesto - www.agilemanifesto.org

Build
Daily Stand-up
Agile Development Build Cycle
Define, Prioritize, Plan Design

Develop
Test
Deploy
Sprint
Product Backlog Sprint Plan Sprint Backlog

Workflows Priorities Use
Maps Tasks
Apps
Review
Potentially Shippable
Product Increment
An Agile Sprint Lifecycle
Product Backlog Sprint Backlog

1
1
2
2
3
3
4
5
Daily
6 Review
7
Sprint Cycle
<30 Days
Working
Tasks Increment

When Do These Models Work Best?
Waterfall Staged Delivery Agile
Scope, • Clear requirements • Flexible scope,

• Several applications deliverables
Technology, • Fixed deliverables
• Prototypes expected • One or several
Contract • Single application applications
Size, • Small size, short duration • Medium or large size, mid • Any size or duration
Duration project to long duration project
• Limited capacity, • Customer EXPECTS

Capacity, • Capacity, resources, and collaboration
resources, and
environment to support
Capabilities, environment
multiple releases • Stable, experienced
Environment • Frequent turnover on project team
project team

Exercise: Waterfall vs Agile

Waterfall Agile
Scope
Planning
Priorities
Customer
Participation
Testing
Development Team
Project Management
Waterfall Agile
Scope Fixed and well -defined Flexible, continuous refining
Extensive at the beginning allowing Continuous and MUST be part of

Planning
for faster development each iteration
Priorities Set at the beginning Constantly changing
Customer
Can be minimal Must be substantial
Participation
Testing Not until the end (more bugs) Constant (helps reduce bugs)
Replacing resources is easier due to Must have strong skillsets and be

Development Team
robust documentation adaptable
Documentation and planning make Strong PM skills required for scope

Project Management
managing “easier” management
Key Takeaways
All software development projects

complete similar tasks
Select a life cycle that fits your

project (one size does not fit all)
Evaluate – scope, organizational

skills, project size, duration
Assess and Plan
Supporting Project Project

Contracts
Team Lifecycle Planning

Assess and Plan
Contract Types Writing a Proposal Estimating

Contracts • Firm Fixed Price (FFP)
- Contractors will bear the risk
• Time & Materials (T&M)
- You bear all the risk
Contract questions FFP T&M

Do you know what you want? A lot Little
How Much is Managing Risk Worth to A lot Little
You?
How Important is Flexibility to You? Little A lot

• Are you going to engage Contractors?
Contract • If so what would be the Contract type
Support
- FirmFixed Price (FFP); or
- Time and Material (T&M)
You? Contractors?

What should you include in an RFP?
Writing an RFP Not Just Technical Details!
for
Subcontractors
Current State Implementation

and Needs Considerations
Administrative Technical
Details Requirements
Good RFPs Strike a Balance

RFP Process (from the Vendor perspective!)

So What Should Be In Your Enterprise Plan?
Vision statement
Key workflows
Approach – life cycle, budget and staffing
Key things you need from the rest of the organization
Schedule – overview of key milestone target dates
Assumptions, dependencies and risks
Appendices – WBS, roles, key points of contact, etc.
Appendix A Appendix A
Morning Project Plan Morning Project Risk Matrix
Page 3 Page 6
Assess and Plan

Proposing is
Part of Planning How to turn information into an initial plan
Identify Initial operating capability
Identify low hanging fruit – quick wins
Identify high priorities
Identify time frames
Identify resources
Create Work Breakdown Structure (WBS)

Proposal
Considerations
Ask the right Have a Focus on the
Compliance questions process and Executive
early an owner Summary
Put on the
Dedicate a Do your
advertising
team homework
hat
Source: Point of Beginning: “How to Submit a Successful GIS RFP Response”; Valerie King, October 1, 2016;
http://www.pobonline.com/articles/100594-how-to-submit-a-successful-gis-rfp-response Implementing an Enterprise GIS Project 2017 60
Writing a
Focus on the Key Areas…
Proposal
• Executive Summary
• Solution Overview
• Scope of Work
• Schedule

Assess and Plan

Big Picture
Epics
Story point is a arbitrary measure used by Scrum
teams. This is used to measure the effort required to
implement a story. In simple terms its a number that
System tells the team how hard the story is. Hard could be
Database Application
related to complexity, Unknowns and effort. In most
Architecture Design
Widget 1 Widget 2 Hardening
cases a story point range is1,2,3,5,8,13,21,34,45
Story Points
21 34 34 45 21
Story Points
21 34 34 45 21
Hours
168 272 272 360 168

Estimating Sheet
Activity Scrum Product Developer Analyst System Total

Master Owner Admin
System
16 16 0 16 120 168
Architecture
Geodatabase 24 24 0 184 40 272
Design
Widget 1 24 24 176 48 0 272
Widget 2 20 20 240 80 0 360
Application
40 16 84 24 4 168
Hardening

Project
System Database Application

Architecture Design
Widget 1 Widget 2 Hardening
1.1 User Story 2.1 User Story 3.1 User Story 4.1 User Story 5.1 User Story
1.2 User Story 2.2 User Story 3.2 User Story 4.2 User Story 5.2 User Story
2.3 User Story 3.3 User Story 4.3 User Story
3.4 User Story 4.4 User Story
Work Breakdown Structure

Assess and Plan
Supporting Project Project

Contracts
Team Lifecycle Planning

Writing a Why is a Project Plan Critical?
Project Plan
• Defines the Project Execution Roadmap

- What you are building
- Key Timing, sequence of events
- Resources Solution
- Strategy and Communications
• Defines when you are done
- Quality expectations Scope
- Acceptance Criteria

Document
Priorities
• Group and list priorities:
- Key workflows
- Key data
- Key IT needs
- Staffing needs
- Schedule
• Rank importance

List
Requirements • High level functional requirements
(High Level)
- Business processes
- Output
- Communication
• Non-Functional
- Technology
- Capacity
- Maintenance and support
- Policies and procedures
Implementation
Team Project size and Project complexity increases with size
complexity Large projects will require more dedicated
roles
Conflict of interest, If you are the Developer, should you be

testing?
separation of duties
If you are the Project Manager, should you be
the Release Manager?
Skills and expertise Do you have domain knowledge to do
requirements?
required for the task
Do you have the qualifications needed for
testing or release management?
Best use of time Should a senior manager test or focus on
other things?

• Work Breakdown Structure (WBS) is aligned
Setup WBS with the project plan to support project
tracking and monitoring
• WBS is decomposing the project into
phases, deliverables and work packages
– Manageable work elements
• Derived from the Statement of Work (SOW)
• All branches in the WBS should be well
defined otherwise they represents a risk in
Appendix A
scope
Morning Sample WBS Elements
Page 8
Accuracy
Ease of
of
charging
charging
Too few Too many
Ease of
reporting Complexity
A Good WBS...
Develop Build a schedule
built on WBS
Baseline
Schedule
Identify
Add detailed
Milestones &
activities
deliverables
Define
Assign dependencies
resources between
activities
Assign durations

Waterfall
Approach Validate estimates by considering relative level of effort
Hours
Months

Agile Approach

Reporting
16%
Estimated %
Spent
Estimated %
Remaining
84%
Proposed
Task Proposed Start
Finish
Status
Setup EMCS environment 4/10/17 4/14/17
Configure Portal 4/14/17 4/28/17
Configure Surveys 4/14/17 4/28/17
Survey tie-in 4/24/17 5/19/17
Onsite visit 5/9/17 5/11/17
Finishing touches 5/15/17 5/19/17
Pilot After 5/22

The Importance
of Managing
Risk
• Watch the video
https://www.youtube.com/watch?v=Wac3aGn5twc
• Think about:
- What went wrong?
- What would you do differently?
• There will be a test!

Video Review
• What went wrong?
- Execution
- No business rhythm
- Poor communication
- Over allocated resources
- Control
- Changing scope
- No schedule
- Undefined budget
- No risk management
Let’s look at this more closely…

Risk
Management What happens when there is no risk management?

Purpose of Risk
Management What is the purpose of risk management?
Identify
Reduce

Sources of Risk
Exercise What are sources of risk?
Examples:
• Impossible schedule
• Loss of funding
• Natural disasters- e.g. Hurricane Katrina 2005
Take a piece of paper
Write down one idea of your own
Take five minutes

What are sources of risk?
Sources of Risk
No project management
Too many projects
Not enough resources
Too many changes
Change in government or regulation

Legal issue
Currency rate fluctuations
Technology changes
And many more…


Plan Ahead

Lunch Break
11:30am - 1:00pm


Plan Ahead

Scrum Sprint Cycle
Scrum
Product
Master
Owner
Daily Scrum
The team
2 - 4 Week
Sprint
Product Backlog Sprint Planning Sprint Backlog
Stakeholders Potentially Shippable

Retrospective Product Increment

KanBan Approach (Still Agile, just not Scrum)
• No defined iterations • Limit your work-in-progress

• No defined roles • Visualize your work
• Direct communication with customer • Ever-changing backlog with on-the-fly prioritization

User Stories, Use Cases, Requirements…
How do we relate them?
Narrative texts that

describe an interaction Conceptual
User Stories of the user and the level
system, focusing on the
value
Criteria to which the Functional

Use Cases system or business
requirement
must adhere
Series of interactions by
the user with the Technical
Requirements system and the requirement
response of the system
Appendix A User Story and Requirements

Afternoon Examples and Documentation
Pages 10-19

Types of Requirements
Business, Functional/Technical, COTS
• Streamline processes
• Reduce costs
Business Level • Increase productivity
• Improve communication between user groups
• Enhance capabilities to accomplish work tasks

Functional Level • Store metadata to support historical metrics
• Use location information to harness the power of GIS
• Must be faster than the old system

Performance/Quality • Must be on software that is still supported
Level • Must be built with future growth allowable
Identifying opportunities of improvement

A good user story uses the “INVEST” model:
I ndependent. Reduced dependencies = easier to plan

N egotiable. Details added via collaboration
V aluable. Provides value to the customer
E stimate-able. Too big or too vague = not estimate-able
S mall. Can be done in less than a week
T estable. Good acceptance criteria

As a [role], I can [feature] so that [benefit]

As a field representative,
I want to collect information offline
so that data can be collected
in remote locations.

Use stories to facilitate a conversation with the team and with the users…
Product Scrum
Owner Master
The team
Stakeholders

Progressively decompose your stories…

Consider grouping user stories into themes
Some things are not about a [user]

Use paper cards
Write out concise user stories Define acceptance criteria for

each user story

Keep your stories visible
Watch out for the ‘Gotchas’
Things to avoid
• Avoid long lists of acceptance criteria on a single

user story
• Prepare for conflicting requirements
• Avoid requirements that are ambiguous
• Avoid requirements that describe HOW
• Requirements must have a “reason”
• Avoid moving forward on development until after the
customer has reviewed the design
• Don’t forget to prioritize

Exercise: Creating User
Stories

Managing Software Development
in the Agile World Manage
• Daily Scrum/Stand-up Meeting
• Reporting
Sprint Plan
Product Work
Backlog
Items
Development
Daily Builds
Check In Work, Unit Test Artifacts
& Update Status • Source Code
Scrum Master/ • Configuration Files
Technical • Wireframes
Lead • GIS Data
Development Team
• Developers
• GIS Database Specialists
• Testers Release
…a Formal Process Build Testing
… but unique to each team
Example: Agile Daily Stand Up Meeting for Visibility
15 Minutes, 3 Important Questions Defined In Progress Completed Accepted
What did you

complete yesterday
What have you

planned for today
Are you facing any

obstacles?
https://www.rallydev.com/

Product Backlog

Wish List

Sprint Backlog

Sprint Backlog

Sprint Backlog
4h 8h 3 days 2h
1h 2 days 4h 8h

Using Agile in a Consulting Project
Waterfall
Method
Agile
Time
Waterfall
Method
Agile
Time
Waterfall
Method
Agile
Time
Waterfall
Method
Agile
Time
Waterfall
Method
Agile
Time
Final Release
Waterfall
Method
Agile
Time
Managing Resources
Plan A Plan B Plan Z

Your Project Sprint Sprint
50% 50%
100% 50% 100% 50%
50% 50% 50% 50% 50%
75% 100% 75% 100%
50%
75%
100% 100% 75%
50%

Tools

Tool to assist in Release/Sprint Planning
RealTimeBoard

Use Tools to Manage Requirements
Appendix A
Requirements
Afternoon
Microsoft Team Foundation Server (TFS) Traceability Matrix
Page 18
Rally Agile Implementation Tool
Using Trello
Using GitHub

Using TFS

Making a Decision
Project Considerations Trello GitHub TFS
Requirements are Proprietary

Mobile App
Easy to setup
Estimation tools
Scheduling tools
Automated Burndown chart
Easily integrated with Visual Studio for Code Repository
Capacity Planning
Exports to MPP and Excel

Avoiding Design Nightmares
https://www.youtube.com/watch?v=BKorP55Aqvg

Design
Workflows System Data Documentation

• Storyboards • Architecture • Concepts • Business cases
• Process description • Security • Tools • Data
• GUI • System
• Application

What needs to get designed?
Desktop Web Device

• User Experience
The Front • Information Products
(Maps, Reports, Models)
• Business Logic
The Middle • Integration Points
(Between components, Portal
to enterprise systems)
• Databases, content, services

The Back • Architecture
( Foundational Decisions)
Server Online Content
and Services

Design Components Together
Interoperable
Governance
Hardware Apps
Data
Software Security

Develop • Convertuser stories into storyboards visually
mockups of describing the workflow process
the UI and
work process •A picture is worth more than a 100 words
• Describeuser and system actions for each
storyboard frame

Develop • Available tools
mockups of
- Visio
the UI and
work process - Balsamiq
- Power Point / Keynote
- Photo software – PSP/Corel…

• Process identification
Process
descriptions • Actions by the user
- Inputs
- Format
- Limitations
• System action
- System process description – properties
- Calculation formula’s
- Rules for processing
- Data and domain values
- Test cases with input values and results

• Immediate capabilities
Application • Simple, focused apps
Design
• Traceability to requirements
Themes
• Engage the customer
• Involve developers and end users
• Focus on mitigating risk
• Prototype
Example Templates for Water Leak Management

Web Isolation Trace Operations Dashboard for ArcGIS Mobile Leak Inspector Field Asset Inspections

Application
Design
• Scaffolding tools such as Yeoman
Tools,
Technology • Existing application templates published by Esri and others
• Existing styling frameworks such as Bootstrap may guide
design
• Rebuild from existing templates

System:
Design Information Products
Application
Design
Maps, reports, models
✓ Consider what’s available already

✓ Consider your deployment platform! For Web/mobile apps… Design maps as Web Maps

Design Access to Content
• Applications  Web services  Data

- Web/Mobile – no direct database access
- Requires deliberate & thoughtful authoring
- Different security model
For Web Apps use the Web GIS Information Model

Design the User Experience – How to Evolve an
System: Interface
Application
Design – Wireframes (sketch ideas and workflows, validate
assumptions)
– Review Wireframes and conduct Usability Testing
– Look and Feel of the GUI
Wireframes Prototype Final GUI

System: Design the UX for the common user
Application – Avoid adding superfluous features
Design – Easier to add in the future than remove
Unless the users are experts

Isn’t always better
More Functionality Implementing an Enterprise GIS Project 2017 135
Design
Workflows System Data Documentation

• Storyboards • Architecture • Concepts • Business cases
• Process description • Security • Tools • Data
• GUI • System
• Application

Reality
Non-functional requirements
System
User Load Network Capacity (WAN,
Architecture: Subnets, Virtualization)
Factors
User Location
Servers (CPU, Memory,
Usage Patterns Count)
Availability Redundancy (Backup,

Disaster Recovery)
COTS/Apps
Security Solution
Security (Firewalls, Authentication,
Encryption etc.)
Data
Disk Space
Policies
Software Stack

Architecture:
Tools & • Gathering requirements
Methodology
• Design tools
• Capacity:
CPU, Network, Memory
• Reporting on Performance
ArcGIS System Designer:

https://www.arcgis.com/home/item.html?id=8ff490eef2794f428
bde25b561226bda
ArcGIS System Monitor available through Esri Professional

Services

• Engineering for High Availability adds complexity and cost
Architecture: - Load balancing
High - Duplication / redundancy
Availability - Adequate testing, monitoring
• How many “9’s” do you really need?
- Evaluate costs of downtime against costs of availability
(MySQL Reference Manual)

System
Design: Solutions/Best Practices
Security
Access Control
• Use rules of behavior
• Who is allowed to access the GIS
• Site banner with acceptable use policy
• What is acceptable system usage
Audit, Logging
• Monitoring system health and activities • Configure tools to strike the right balance
• Minimize performance burden on GIS
Encryption • Use HTTPS/TLS

• Protecting the confidentiality of your data • Consider encrypting data at rest
Identity Management • ArcGIS built in-in or your own Provider?

• Uniquely identifying / authenticating users • Single factor or Multi-factor?
• Managing user roles • What is your Password Policy?
Intrusion Detection • Use your Firewall, don’t work around it

• How to prevent threats • Train developers in security practices!
• How to manage vulnerabilities • Implement patch management
http://doc.arcgis.com/en/trust/
System
Design: Examples – Identity Management
Security

• Is your system mission critical?
System: • In case of a catastrophic failure
Disaster - How much time will it take to restore (RTO)
Recovery - How much data loss can you afford (RPO)
• Develop a plan and test it regularly
- Roles and responsibilities
- Succession
- Backup strategy
- System restoration
How many of
you have a
real RTO/RPO
or DR Plan?
Source: Disaster Recovery Preparedness (drbenchmark.org)

Design
System Workflows Data Documentation

• Architecture • Storyboards • Concepts • Business cases
• Security • Process description • Tools • Data
• Application • GUI • System

Design the GIS • Identify data requirements for information
Database products Appendix A
Data Requirements
Afternoon
Template
• Collect data inventory Page 19
• Identify gaps and how to resolve them

• Create the data model Appendix A
Afternoon Source Data Matrix
Page 20
Conceptual Logical Physical

Workspace
Featured Dataset
Topology
Feature Relationship
Classes s
Dataset
Focus on data you will use and maintain!

Design to the normal not the exception!
Geoprocessing Models; DDL Scripts
Data Design - • Repeatable maintenance process
Tools • Initial investment to create the model
ArcGIS Diagrammer, XRay

• Schema Creation and Documentation Functions
• GDB centric
Visio, UML
• Simple; tool is well known
• Limited support for GDB features,
• No schema creation or reverse engineering (any more)
Enterprise Architect, UML

• Full UML Support
• ArcGIS Extension: Import XML Workspace Exports
• Currently better for documentation than design

Exercise: List Data
Requirements

Exercise– List Data Requirements for Information Products
Example: Water Leak Management
Water Department
Information Products
Asset Map
Leak Trace
Data
Map with Service
Requests location by
status
Map showing field crews
Map showing customers

Design
System Workflows Data Documentation

• Architecture • Storyboards • Concepts • Business cases
• Security • Process description • Tools • Data
• Application • GUI • System

How much is enough?

How Much is Enough? (for the customer)
Documentation
• Enough to articulate how the business processes will be realized
- Solution architecture
- Concept of Operations (CONOPS)
- User Experience
- User Stories, Scenarios
- Data Layers and Attributes
- Maps, Reports
Appendix A Appendix A Appendix A Use Case Model

Afternoon ArcGIS Diagrammer Afternoon X-Ray Tool Afternoon Activity Diagram
Page 20 Page 21 Page 22

How Much is Enough? (for technical team)
Documentation
• Enough to determine and articulate (where necessary)

how the solution will be developed
- System architecture
- Detailed component breakdown
- Design Specifications for apps and data
Appendix A Sequence
Afternoon Diagram - Services
Page 25
- Prototyping and/or design models for…
- High risk areas
- Integration points
Appendix A
Afternoon Class Diagram - Key points that are fail points or are non-traditional
Page 27
- Prototype Prove implement  review cycle

Configure and Develop your System
Application Data Development

Development • Content
Development • Tracking, development
Principles Managing options
• Tools • Process
https://www.youtube.com/watch?v=X5SkW7K0e3Y

Development • Build to your design!
Principles
- If change is necessary, inform and explain it to the
team, use change management
• COTS and configuration first, customization
later or when 100% necessary
• Track development progress continuously
- Use tools and metrics
- Keep everything visible and review frequently
• Use existing and trusted tools for:
- Source control - change control - issue tracking - build
automation
Apps and Information Products | How to Implement Them
• Use COTS and GIS-ready data to deploy Initial Operating Capability (IOC)
3
Presenting IOCs instead of finished
products is a big switch!
2
Customize
1 for specific
needs(only if
Configure necessary)
Apps and
Deploy
Workflows
Foundation
Apps

Development
Principles
Tools are your Friends Use Coding Standards Enforce Unit Testing
Work Item
Logging By developers
Management
Source Code
Exception handling Use automation
Repository
Build System Naming conventions Test design
Test robustness of
IDEs Code Reviews
code
http://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments
Configure and Develop your System


Application
Development -
Tools
Build
Source Control • TFS,
• TFS • JIRA
Work Item Management,
• git/GitHub • Travis
Issue / Change Tracking
• Subversion • Ant
• TFS,
• Mercurial • Maven
• GitHub
• Grunt
• JIRA
• Less
• Rally, Trello
• Bugzilla
• OnTime
• Remedy
Development • Lighthouse
Environment
IDEs
• Sublime Text
• Visual Studio
• Eclipse
• Technology
Stack dependent Implementing an Enterprise GIS Project 2017 157
Application • Options:
Development -
Server-Side - Microsoft .NET
Technology
Stacks - Java
- Node.js
- Also:
- Ruby on Rails, Django, …

Application • JavaScript is the best bet for native-looking apps
Development -
Recommendations • Python is not only for geoprocessing but for web
services, hosting web apps with Flask and other
cases
• Mix and match languages to suit the need and
suit your team’s experience
• With web services, you can use any language /
any technology stack to access the services
once they exist.
• Leverage existing APIs or wrapper libraries
- ArcREST
- arcgis-node
- node-geoservices
Configure and Develop Your System


What are the Options for Developing Data
Data
Development
Content?
Conversion – Automate new

Migration – Move data
geospatial data
between GIS Platforms
• Hardcopy Maps to GDB
• AutoCAD, Microstation
• Imagery to vectors
• to ArcGIS
• Shapefile to GDB
Collection – New data from

remote platforms
• Imagery
Appendix A
Data Migration • GPS
Afternoon
Page 29
Procedures Document • Surveys

Tools
• ArcCatalog
Data • ArcGIS Data Interoperability Extension
Development • Production Mapping Data Loader
• ArcGIS Data Reviewer
Tools and
Procedures
• Open Source data production
• Relational Database Geometry storage
Pilot
• Test Design
• Real data for
developers Coordinated
Approach
• Incremental
deliveries
• Synchronized with
development
For best results:

Let your data evolve with your
Apps and information products!
• Formal process is key
Development -
Review • Strive for transparency in the process
• Engage the leadership team and sponsors
• Coordinate database and application
development
• Keep developers developing and testers
testing
• Stay engaged with customer or project owner
• Test early, release as often as is possible and
prudent.
• Code Reviews

Test your system
Testing
Process Test Plan Test Cases How to Test

Testing Themes
• Test the right things at the right time

Common Testing Challenges
• Focus on your deliverables
• Develop good test cases
- Prove requirements are met
- Fit the importance of the requirement
- Reflect workflows
• Use an (approved) test plan
• Tests need to be realistic and fair http://atagg.agiletestingalliance.org/
https://www.youtube.com/watch?v=mafRRWKSwu0

Testing Process
Testing Works Best as an
Integrated Process!
Testers, Designers, Developers Testers

Developers Develop and unit test Stakeholders, End Users
Collaborate during test case single components Test in a separate test
development (design stage) environment
Test Plan and Test

Cases
Test team
Testing Process Release training
for testing
Perform testing
Fix bugs
Review results
Testing and log bugs
criteria met
Ready to client
verification and
validation
Sample Design Artifacts for a Leak Management Isolation Trace Tool
User Stories Acceptance Criteria User Interface Prototype & GIS Data Layers
Information Products Design
Feature
Classes
Pipes
Summary Report
Develop Design Configure Trace Tool Valve Report
Valves
Artifacts Specific to Execute Trace Hydrants
Hydrant Report
Save Trace Service Locations
the Sprint Customer Report
Work Order Locations
Trace Map
Basemap Layers

Test your system
Testing
Test Plan Test Cases How to Test
Process

Typical Test Plan Outline:
Test Plan • Your testing strategy including:
- Overview of the solution
- Objective with the testing
- Scope of the testing
- Sequence of testing
• Acceptance procedure and criteria

Appendix A • Test environment to be used
Afternoon - Test Plan Templates
Pages 32 - • Test data and test area to be used
33
Appendix A The test plan is your ‘battle plan’ for acceptance

Afternoon Acceptance Criteria
Page 35

Test your system
Testing
Process

• Test cases are procedures for verifying requirements
Develop Test • Address all requirements
Cases
– Functional
– Non-Functional
• Good Test Cases:
– State the purpose of the test with reference to requirement
– State pre-conditions
– Clearly and objectively outline the steps to verify/validate a specific
outcome
– Unambiguously list the expected result or outcome of the test
determining a pass/fail of the test
Appendix A
Afternoon Test Case Template
Pages 37 Test Script
to 39
User Stories and Testing
…Think back to the invest model…Think Traceability
User Story Template Testing Template
I Independent Given [Some Context]

As a [User Role}
[When] some action is carried out
N Negotiable I want to [Desired Feature]
[Then] a particular set of observable
So that [Value/benefit]
results should be obtained
V Valid
E Estimable
S Small Focus on •
Focus on
Pre-conditions, Post-conditions
• Value to the user • Step-wise descriptions
T Testable • Testable outcomes

Example: Test Scenario for a Water Leak Isolation Trace User Story
User Stories Test Scenario Acceptance Conditions
Isolation Trace Locate Leak Locate Leak on Map Acceptance
As a Field Crew Member Given - User is logged in • After user login, map displays
I want to run a leak As a field crew member I Mobile app is open with map based on default of users profile
isolation trace starting need to locate the leak display and list of active workorders • Active workorders display in
from the leak location on the map so I can Then - side panel
So I can identify affected determine the starting 1. User selects an active work • User can select a single
service areas, point of the trace order from list workorder from the list
customers, and assets 2. Selected work order highlights • Clicking “locate” zooms map
3. User picks “locate” display to the location of
4. Map display zooms to selected workorder and closest
workorder location service point is highlighted on
5. Location is highlighted with the map
marker • Clicking “cancel” clears the
6. Service point nearest to the selection
Appendix A location is highlighted
Afternoon Test Cases Template
Pages 37- Test Scripts/Scenarios
39
Test your System
Testing
Process

Acceptance Testing Process
How to Test
Deploy Pre-UAT
Solution Training
• Your site or client site?

• How much time?
• When to train? Test
• What happens after the test? Fix
• Is on-site support necessary?

• How to track and manage defects?
Review /
Retrospective
Appendix A Appendix A
Afternoon Defect Tracking Afternoon Test Results Report Move to Production
Page 44 Page 45 Acceptance
Releasable
Issued Product
How Do You Evaluate Software Quality?
Testing process
Measure and analyze

against acceptance criteria
• Defect metrics
• Status meetings
Anecdotal
evidence from
developers and
end users
Sample Test Manager Reports
• Are you on or off track?
Testing process
Scenario 1 Scenario 2
140 140
120 120
100 100
Total 80
80
Closed 60
60 Resolved
40
Active
40
20
20 0
Test Cycle Test Cycle IAT UAT Post UAT
0 1 2
Test Cycle 1 Test Cycle 2 IAT UAT Post UAT
• Defect rate does not decline • Defect rate declining steadily over time
• Large number of active defects at UAT • Few active defects when entering UAT
• Acceptance unlikely • Acceptance likely
Deploy

Deploy Typical Sequence of Events
Production Staff
Training
Deploy Pre-UAT Stand-up

Solution Training Production
Production Assess
Test Checklist
Fix Rollout
Move to
Production
Acceptance
Review /
Retrospective
Issued
Support
Releasable
Product

Deploy
Plan Before you Go….
• Confirm the customer is ready
• Communicate all Hardware/Software pre-
requisites
• Define resources, tasks, assignments
• Develop a detailed checklist
• Develop a detailed schedule
Appendix A
Afternoon Deployment Checklist
Page 46

Multiple • Use an installation package
Deploy: departments, • Plan sequencing with customer
Typical locations
Challenges
Many system • Itemized list of components

components (HW, • Detailed checklist
RDBMS, GIS)
Working around • Separate environments

existing operational • Move to operations in OFF hours
environment
Varying skills in • Targeted training program

user community
Deploy
Tips and Techniques
• Swap staging and production
• Swap passive and active leg (for high
availability)
• When upgrading, you must be able to fall
back to previous configuration
• Down-time because of installation and
upgrade still counts as down-time!

• Build training curriculum supporting GIS business processes
- Targeted to the audience – not generic
Training - Differentiate casual from advanced users
- Help user visualize success in the production environment
• Sequencing and timing is essential

- COTS before custom
- Just-in-time is best
• Continue to grow GIS knowledge and capacity


Plan Ahead

Performance Monitoring, Tuning
• Monitor, evaluate
- How is the system REALLY used?
Evaluate
- Are there unanticipated bottlenecks?
- Can performance be improved?
• Tuning can improve performance

- RDBMS database, ArcGIS Server
- Versioning workflows
System Test System Monitor

Production Rollout / Transitioning / Operations
Evaluate
• Users assume ownership
• A critical stage
Use
- Encourage use of the system
- Avoid operational failures
- Avoid abandonment of the system Monitor
• Plan to provide adequate support

- Performance monitoring, tuning Resolve
- Resolving issues (e.g. Help Desk)

- Review and follow-up Follow-
Up

Version Updates
Evaluate
• Evaluate options
• Upgrade in test environment first
• Includes Software Patches and OS Updates
• Communicate with IT
• Investigate new tools and functionality
• Get ready for rollback
• Is it worth it?

Adopting Emerging Technologies
Evaluate
• Risk/Reward
• Prototype new technology
• Demonstrate functionality to yourselves
• Demonstrate functionality to customer
• Consider Integration impacts

Measuring Benefits, Path Forward
Review
• Operational review Review
- Are existing expectations met?
- What are future expectations?
- Are there new requirements?
- What benefits were realized? Recommend
- Are there short comings?
• Assess the happiness of your stakeholders
• Make recommendations Grow
- Priorities for new data, services, apps
- Organizational considerations
- System tuning, upgrades
• Plan for Growth

Increase organizational enablement
• New apps, data, services
Plan Ahead
• Further integration of organizational units
Desktop Web Device
Portal

and Services
Moving to an Integrated Enterprise System
Initial Operating Capability Integrated Enterprise System
Desktop Web Device

Foundation apps
Essential Information Products Extended / custom apps
Portal Integration with business systems
Advanced workflows
Content production systems

“GIS Ready” data Data modernization
and Services

Questions?


Implementing An Enterprise GIS Project: Lana Tylka Jennifer Prather Craig Venker

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementing An Enterprise GIS Project: Lana Tylka Jennifer Prather Craig Venker

Uploaded by

Copyright:

Available Formats

Implementing an Enterprise GIS Project

Organization you represent

Typical Project Size

Implementing an Enterprise GIS Project 2017 3

Implementing an Enterprise GIS Project 2017 6

Implementing an Enterprise GIS Project 2017 7

UI/UX Performance Maintenance Management

Evaluate, Review, and

Implementing an Enterprise GIS Project 2017 9

Launching your Location Platform Guide:

Implementing an Enterprise GIS Project 2017 10

Desktop Web Device

“GIS Ready” Data Server Online Content

Desktop Web Device

Portal Integration with

Content Production Systems

Desktop Web Device

Portal Integration with

Content Production Systems

Implementing an Enterprise GIS Project 2017 13

ArcGIS Server Image Server 3rd Party Data

Implementing an Enterprise GIS Project 2017 14

Implementing an Enterprise GIS Project 2017 15

What already exists? What’s next?

Who are the potential end-users of your data?

What are your data retention policies?

How does growth of the project affect your data?

Implementing an Enterprise GIS Project 2017 16

Data Creation Production Publication

Implementing an Enterprise GIS Project 2017 17

Implementing an Enterprise GIS Project 2017 18

What are the existing limitations of your systems?

Are you ready for/interested in the cloud?

What happens in the future?

Implementing an Enterprise GIS Project 2017 19

• Mobile Device Access Local Hosting

• Contractors, 3rd Party and Public

Implementing an Enterprise GIS Project 2017 20

Implementing an Enterprise GIS Project 2017 21

Implementing an Enterprise GIS Project 2017 23

Implementing an Enterprise GIS Project 2017 24

Implementing an Enterprise GIS Project 2017 25

Implementing an Enterprise GIS Project 2017 27

Development Staging Production

Implementing an Enterprise GIS Project 2017 28

Update with what you have learned…

Evaluate, Review, and

Implementing an Enterprise GIS Project 2017 30

Implementing an Enterprise GIS Project 2017 31

Historic usage and expected future growth

Monitoring and Testing

SLAs and the impact of over-capacity

Implementing an Enterprise GIS Project 2017 32

Implementing an Enterprise GIS Project 2017 34

Implementing an Enterprise GIS Project 2017 35

Implementing an Enterprise GIS Project 2017 36

Known Gaps Can Drive Requirements

• Stay current on software versions

Known Gaps Can Drive Requirements

Implementing an Enterprise GIS Project 2017 39

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Close to Far from

Implementing an Enterprise GIS Project 2017 42