City of Rome 39th Edition

From wiki.gis.com
Jump to: navigation, search
System Design Strategies (select here for table of contents)
System Design Strategies 39th Edition (Fall 2016)
1. System Design Process 39th Edition 2. GIS Software Technology 39th Edition 3. Software Performance 39th Edition 4. Server Software Performance 39th Edition
5. GIS Data Administration 39th Edition 6. Network Communications 39th Edition 7. GIS Product Architecture 39th Edition 8. Platform Performance 39th Edition
9. Information Security 39th Edition 10. Performance Management 39th Edition 12. City of Rome 39th Edition 11. System Implementation 39th Edition
A1. Capacity Planning Tool 39th Edition B1. Windows Memory Management 39th Edition Preface (Executive Summary) 39th Edition SDSwiki What's New 39th Edition


Fall 2016 City of Rome 39th Edition

This chapter shares a process you can use to complete your own system architecture design. This process brings together what has been discussed in the earlier chapters and demonstrates the value of the system design analysis in making informed design decisions.

System architecture design provides a methodology for establishing hardware and network requirements that support the performance and communication needs of GIS application users. Hardware requirements should be established based on identified business needs. A fundamental understanding of user workflow requirements and the supporting GIS technology is required before one can identify the appropriate hardware and network requirements for supporting effective enterprise GIS operations.

City of Rome is the name of the case study provided to demonstrate the planning process presented in a book by Roger Tomlinson called Thinking about GIS: Geographic Information System Planning for Managers. Both his book’s chapter 9 and this chapter show standard templates that can be used for most enterprise design studies. In this chapter we will use the Capacity Planning Tool as a framework to model user requirements and the system architecture design for two planned years of expansion and growth for the City of Rome.

Contents

City of Rome case study

Figure 11.1 The City of Rome is a typical municipal community that is used to represent how you might use the system architecture design methodology to make your infrastructure upgrade decisions.

Figure 11.1 shows a collection of photos representing City of Rome. The fictional City of Rome represents a typical organization, just right as a case study to demonstrate how you can use the capacity planning tool in your system design process.

Pre-design efforts

Figure 11.2 Business needs establish the foundation for any enterprise GIS design. The enterprise vision, existing business architecture, and user requirements must be understood to select the best GIS solution.

Figure 11.2 shows the efforts completed in preparation for the system architecture design. Business needs must be understood before you are ready to complete the system architecture design.

Enterprise vision

GIS software deployment patterns are optimized to support your business needs:

  • Location enablement
  • Data management
  • Analysis
  • Field mobility
  • Visualization
  • Constituent engagement

Existing Business Architecture

Business architecture defines the current state of how you are meeting your business requirements.

  • Governance and political landscape
  • People and communication strategies
  • Platform and network environments
  • Operational constraints and priorities
  • Funding constraints

Workflow loads analysis

User workflow loads analysis reviews the business processes to identify where and what is required to support business needs.

  • user location and connectivity
  • user workflow analysis (user needs)

User location and connectivity

Figure 11.3 Where users are located and how they are connected to central applications and data sources can determine acceptable system design candidates.

Figure 11.3 shows the user location and connectivity. All user locations requiring access to GIS applications and data resources must be identified.

  • You want to include everyone who might need access to the system during peak work periods.
  • The term "user locations" encompasses local users, remote users on the Wide Area Network (WAN), and Internet users (internal and public).

The enterprise infrastructure must be able to accommodate peak workflow traffic loads.

  • Know where users are located.
  • Know what information products users will need to do their work.
  • Identify the location of the necessary data resources.
Best practice: A simple diagram can be helpful for identifying user location and network connectivity.

In the system design assessment, you must identify the network communication bandwidth between the different user locations and the data center.

  • Network bandwidth may include communication constraints that will influence the proper software technology solution.
  • The selected technology solution may require upgrades to the network communication infrastructure.
Best practice: It is important to identify additional infrastructure costs during the planning process—you do not want to find this out after system deployment.


User workflow patterns

Figure 11.4 User workflow patterns (use cases) are normally a product of a user needs assessment and provide a reference for establishing workflow loads for the system architecture design.

Figure 11.4 identifies the software technology workflow patterns identified for the City of Rome. GIS business information products and associated data sources were used to classify the identified technology patterns.

  • Desktop Editors would be classified as heavy complexity workflows.
  • Desktop viewers work primarily with much more focused map displays and can be classified as medium complexity workflows.
  • Business Analyst desktop applications will be classified as a heavy complexity workflow.
  • Remote desktop viewers will be supported from a centralized terminal server farm, and will be classified as medium complexity raster based workflows.
  • Web mapping services will be divided into two categories, with a medium complexity workflow used for internal web services and a light complexity workflow used for the more focused public facing services.
  • The Police services will use a Mobile Web dashboard client in the patrol cars with a relatively light synchronization service for updating emergency vehicle locations during emergency response operations.

Performance targets for the identified workflow patterns were reviewed with the department managers to validate workflow complexity estimates.

Best practice: Workflow performance targets will be revisited during system deployment to validate design compliance.


City of Rome CPT user workflow loads analysis

The user workflow loads analysis will identify peak number of concurrent users and workflow transaction rates required to satisfy the City of Rome business requirements for each of the identified workflow patterns for year 1 and year 2.

User workflow loads Year 1
Figure 11.5 Workflow loads analysis for City of Rome Year 1 establishes peak business throughput loads for the Year 1 system architecture design.

Figure 11.5 shows the user requirements for City of Rome year 1 deployment.

The template used to document the year 1 user application requirements for the City of Rome was designed to integrate the requirements analysis provided in Tomlinson's Thinking about GIS with what is needed to complete the system architecture design. The spreadsheet identifies user workflow requirements (peak workflow loads) at the department level for each user location.

Peak workflow loads establish processing and traffic requirements used by the CPT to generate hardware specifications.

  • Each department manager should be called upon during the design process to validate that these peak user loads are accurate estimates.
  • It is important that the design analysis be based on validated peak user requirements, and that the relationship between business needs and these peak throughput estimates have been reviewed and are understood before the final design acceptance processes.
  • Peak user workflow loads are used by the CPT to generate peak processing and traffic requirements applied to the final hardware and network solution.

The first year deployment will include:

  • Internal ArcGIS for Desktop (Desk Edit and Desk View) and internal web services (LocalMap) within central City Hall (Planning and Engineering departments).
  • Three user locations over the WAN (Operations, Freeberg, and Willsberg).
  • The IT department will host public web services over their Internet connection.
Best practice: Each department manager is responsible for validating estimated peak workflow requirements.


User workflow loads Year 2
Figure 11.6 User loads analysis for City of Rome Year 2 establishes peak processing and network traffic requirements for the year 2 system architecture design.

Figure 11.6 shows the user workflow analysis for City of Rome year 2 deployment.

Year 2 includes:

  • Business Development department deployment of a new Business Analyst information system.
  • Engineering department deployment of ArcGIS Workflow Manager applications.
  • City adds 911 services within the Operations department, along with a new dispatch operation and implementation of five additional field offices (Perth, Wawash, Jackson, Petersville, and Rogerton).
  • ArcGIS for Server Geoevent Extention is deployed to facilitate snowplow scheduling.

Year 2 also includes implementation of a separate secure network to support police operations.

  • The police network will be a separate design.
  • Geodatabase replication services will provide updates from the city database to the police database.
  • A new ArcGIS Mobile application will support the police patrols, using wireless communications connecting through a T-1 WAN connection synchronizing with the ArcGIS for Server mobile clients (patrol cars).
  • The police department adds a police dispatch and implements an ArcGIS for Server Geoevent Extension solution with the 20 police patrols.


Workflow loads summary
Figure 11.7 A workflow loads summary provides a more condensed overview of user requirements used to complete the system architecture design.

Figure 11.7 shows a workflow loads summary for years 1 and 2

A workflow loads summary is a more condensed template that you can use as your resource in completing the system architecture design. This template includes the same user locations and workflows provided in the earlier templates.

Best practice: GIS workflow loads summary represents the business requirements used to complete a proper system architecture design.

Performing a proper workflow loads analysis is hard work.

  • Organization staff must work together to identify workflow processes and agree on business needs.
  • Estimating the peak number of users for each user workflow is a fundamental part of doing business and must be completed by the business organization.
    • Peak workflow usage will affect decisions on staffing and software licensing.
    • Peak workflow usage will determine the network and hardware specifications.
  • Understanding and getting the user workflow loads right will make a big contribution toward completing a proper system architecture design and deploying productive GIS operations.

Now that you have completed the user workflow loads analysis, you are ready to continue with the system architecture design.

CPT Business workflows

User workflows identified on the user needs summary are translated to Project Workflow performance targets by the Capacity Planning Tool. Project workflow are collected at the top of the CPT Workflow tab. Critical process information is provided with this link to the Capacity Planning Tool Appendix.

CPT Workflow definitions

Project workflow names and associated performance target assumptions (workflow recipe) are maintained within the CPT Workflow tab. Summary of the workflow definitions is provided with this link to the Capacity Planning Tool Appendix.

CPT hardware platform candidates

Hardware platform candidates are identified on the CPT Hardware tab. City of Rome candidate hardware platform selections are provided with this link to the Capacity Planning Tool Appendix.

CPT workflow and hardware platform favorites
Figure 11.8 The CPT Favorites tab provides a way to organize your workflow and platform project lookup information.

Figure 11.8 shows a summary of the City of Rome Favorites (Workflows and Platforms) provided by the CPT Favorites tab.

The CPT Favorites tab can be used for organizing project workflows and hardware platform technology choices.

  • can be used as an alternative CPT Design workflow lookup list or CPT hardware selection list.
  • allows you to organize your specific project workflows and platform selection options on a shorter selection list.
  • includes the selected workflow description and the selected platform specifications as a summary view of your project resources.
City of Rome workflow favorite summary

Note: City of Rome decided to participate in the Community Maps program, providing their base reference data layers to Esri for caching and sharing on the ArcGIS Online cloud platform. This reduced display complexity for City of Rome workflows by 50 percent.

ArcGIS for Desktop workflows

  • ArcGIS Desktop Editor: ArcGIS workstation ArcMap 2D vector heavy complexity 50 percent dynamic 1920x1080 average desktop client display resolution.
  • ArcGIS Desktop Viewer: ArcGIS workstation ArcMap 2D vector medium complexity 50 percent dynamic 1920x1080 average desktop client display resolution.
  • ArcGIS Business Analysis: ArcGIS workstation ArcMap 2D vector heavy complexity 50 percent dynamic 1920x1080 average desktop client display resolution.

Note: City of Rome decided to register all internal Web mapping services on Portal for ArcGIS for the Year 2 deployment. All year 2 Internal Web Mapping Services will be deployed through Portal File Sharing and Internal Web Portal services (Internal Web Portal Sharing and Services).

ArcGIS Server Mapping Services

  • Internal Web Mapping Services: ArcGIS REST 2D vector heavy complexity 50 percent dynamic 1366x768 average Web client display resolution PNG24 map service with ArcGIS Online basemap cache (Year 1 deployment).
  • Internal Web Portal Sharing and Services: ArcGIS REST 2D vector portal heavy complexity 50 percent dynamic 1366x768 average Web client display resolution PNG24 map service with ArcGIS Online basemap cache plus Portal File Sharing (Year 2 deployment).
  • Public Web Mapping Services: ArcGIS REST 2D vector medium complexity 50 percent dynamic 1366x768 average Web client display resolution PNG24 map service with ArcGIS Online basemap cache.

ArcGIS Server Mobile Services

  • Mobile Synchronization Service: ArcGIS 10.3 SOAP 2D vector light complexity 10 percent dynamic 1024x764 client display resolution feature service.

Batch Administration Services

  • Administration batch process: ArcGIS REST 2D vector medium complexity 100 percent dynamic 1366x768 average Web client display resolution PNG24 batch process.
City of Rome platform favorite summary

Desktop workstation

  • Intel Core i7-6700 4 core (1 chip) 3400 MHz processor (61.8 per core)

Arc15 server platform candidates Xeon E5-2637v4 4 core (1 chip) 3500 MHz: SPEC throughput 240 (60 per core) Xeon E5-2637v4 8 core (2 chip) 3500 MHz: SPEC throughput 479 (59.9 per core) Xeon E5-2643v4 12 core (2 chip) 3400 MHz: SPEC throughput 702 (58.5 per core) Xeon E5-2667v4 16 core (2 chip) 3200 MHz: SPEC throughput 888 (55.5 per core) Xeon E5-2689v4 20 core (2 chip) 3100 MHz: SPEC throughput 1040 (52 per core) Xeon E5-2687Wv4 24 core (2 chip) 3000 MHz: SPEC throughput 1180 (49.2 per core) Xeon E5-2690v4 28 core (2 chip) 2600 MHz: SPEC throughput 1330 (47.5 per core) Xeon E5-2697Av4 32 core (2 chip) 2600 MHz: SPEC throughput 1420 (44.4 per core) Xeon E5-2697v4 36 core (2 chip) 2300 MHz: SPEC throughput 1510 (41.9 per core) Xeon E5-2699v4 44 core (2 chip) 2200 MHz: SPEC throughput 1810 (41.1 per core) AMI m4.large (2vc) 24 core (2400 MHz) 8 GB: SPEC throughput 1015 (42.3 per core)

System design process

Figure 11.9 System architecture design process provides a logical step-by-step methodology for using the CPT to complete your system architecture design.

Figure 11.9 shows the process used to complete the system architecture design. A fairly standard system architecture design process will be used to complete the City of Rome analysis.

System architecture design process:

  • Technical architecture strategy. High-level network drawing showing user site locations, network bandwidth connections, and central data center locations. Drawing should match the user location information provided on the user requirements templates.
  • User requirements analysis: The CPT Requirements analysis section is configured to represent the site locations, user workflows, peak loads, and network bandwidth for the enterprise design solution.
  • Network suitability analysis: CPT Design completes the network suitability analysis and identifies any communication bottlenecks. Network bandwidth upgrades are identified to complete the network suitability analysis.
  • Platform architecture selection: The CPT Design Platform tier is configured to represent the design solution. Identify platform tier nicknames, select platforms, and identify platform rollover settings.
  • Software configuration: The CPT Design Software Configuration module is used to assign workflow software to supporting platform tier (software install) and make workflow data source selection.
  • Enterprise design solution: Once configured, the CPT Design tab completes the system architecture design analysis and provides the platform solution.


City of Rome System Architecture Design: Year 1

Technical architecture strategy: Year 1

Figure 11.10 City of Rome Year 1 user location and bandwidth connectivity.

Figure 11.10 shows the user locations and network connectivity for the year 1 GIS implementation strategy.

A server-based architecture will be deployed from the central IT data center for the year 1 implementation.

  • Server platforms will include a Windows Terminal Server farm to support the remote ArcGIS for Desktop users.
  • ArcGIS for Server to support the public web services.
  • A central GIS data server to support the enterprise geodatabase.

City Hall data center remote network connections

  • Data center—1000 Mbps LAN connection
  • Data center—1.5 Mbps WAN connection
    • Site 2 Operations facility—1.5 Mbps WAN connection
    • Site 3 Freeberg—1.5 Mbps WAN connection
    • Site 4 Willsberg—1.5 Mbps WAN connection
  • Data center—1.5 Mbps Internet connection
    • Public web services will connect through the data center Internet connection.


User requirements analysis: Year 1

Figure 11.11 City of Rome Year 1 user needs summary

Figure 11.11 shows the City of Rome year 1 user needs summary. Once the custom workflows are defined (Workflow loads analysis), you are ready to complete the Phase 1 user requirements analysis. The City of Rome Year 1 user needs summary will be used as a reference to configure the CPT Design requirements analysis module.

The CPT user requirements analysis includes all of the Year 1 workflows identified during the business workflow loads analysis.

  • Common workflows can be consolidated at each site location to simplify the display.
  • The CPT workflows must track back to represent the workflow loads analysis (user needs).

User needs summary (workflow recipe introduced in Chapter 3)

  • User requirements include five workflows. Additional batch process was included for system administration use.
    • GISDeskEditor_ArcGIS Desktop Editor: local workstation DeskEdit users.
    • GISDeskView_ArcGIS Desktop Viewer: local workstation DeskView users.
    • RemoteGISView_Citrix ArcGIS Desktop Viewer: remote DeskView clients.
    • WebInternal_Internal Web Mapping Services: LocalMap services.
    • WebPublic_Public Web Mapping Services: PublicMap services.
    • BatchAdmin_Admin Batch Load: reserved for IT administration batch processing.
  • Users are located at different network locations (local users, Operations site 2, Freeberg site 3, Willsberg site 4, and public Web services)
  • Peak workflow usage is identified for each network location
    • Local Area Network (peak users for DeskEdit and DeskView; peak throughput for LocalMap)
    • Operations site 2 (peak users for DeskEdit; peak throughput for LocalMap)
    • Freeberg site 3 (peak users for DeskEdit; peak throughput for LocalMap)
    • Public Internet connection (peak throughput for WebPublic services)


Network suitability analysis: Year 1

Once the CPT Design Requirements Analysis module is configured, the CPT (Excel) completes the network suitability analysis. Peak network loads are calculated and compared to available network bandwidth. Traffic performance bottlenecks are identified by red cells in the CPT requirements model. Sample CPT display information is provided with the network suitability analysis link to the Capacity Planning Tool Appendix.

Network upgrade recommendations: Year 1
Figure 11.12 Network bandwidth upgrades are provided from the City of Rome Year 1 network suitability analysis.

Based on a completed network suitability analysis, Figure 11.12 shows a list of the Year 1 network upgrade recommendations.

Best practice: Network bandwidth upgrade recommendations must be coordinated with the City of Rome network administrator and included in the network infrastructure upgrade budget.
Warning: Serious performance issues will impact user productivity during peak loads if required network bandwidth is not available in production.

Once potential network contention is identified and resolved, we are ready to move on to the platform architecture selection.

Platform architecture selection: Year 1

Figure 11.13 Three platform architecture solutions will be evaluated for the City of Rome Year 1 analysis.

Figure 11.13 shows the candidate architecture patterns that will be evaluated during the City of Rome Year 1 analysis.

Platform solution candidates

  • Minimum physical configuration: Identify the minimum physical platform architecture required to support peak production load requirements.
  • High-availability physical configuration: Identify the minimum high-availability physical platform architecture required to support peak production load requirements.
  • High-availability virtual configuration: Identify the minimum high-availability virtual server configuration architecture required to support peak production load requirements.


Hardware price list

Figure 11.14 City of Rome hardware price list that will be used to complete this business case analysis.

City of Rome management requests that we complete a cost analysis for the various platform architecture patterns being proposed for this study. Figure 11.14 shows the City of Rome hardware price list for platforms under consideration for this design.

Customer price lists can vary based on vendor arrangements and contract agreements. It is important to validate pricing if you wish to include this in your analysis.

Best practice: The Platform Performance lesson includes an assessment of current hardware platform capabilities, and should be reviewed with the IT procurement team for use in generating the best possible list of hardware candidates.

Note: Platform selection list above shows the [2015 best buy platform recommendations] identified in the Platform Performance Chapter 8.

CPT Platform architecture selection

Platform architecture selection should follow best practices identified in the GIS Product Architecture and Information Security chapters. Critical process information for completing the platform architecture CPT Design configuration for City of Rome is provided with this link to the Capacity Planning Tool Appendix.

CPT Design Software configuration

Business workflow software components (software configuration) must be installed on the appropriate CPT platform architecture hardware tier. Critical information for completing the appropriate software configuration is provided with this link to the Capacity Planning Tool Appendix.

Enterprise design solution: Year 1

CPT Design analysis for physical platform solution - Year 1

Selecting the right enterprise design solution is critical for system implementation success. The Esri Capacity Planning Tool translates identified business requirements to selected platform loads, identifying an acceptable platform solution with capacity to satisfy business processing needs. Critical information is provided with this link to the Capacity Planning Tool Appendix.

Physical platform solution summary: Year 1
Figure 11.15 City of Rome Year 1 physical platform solution summary.

Figure 11.15 shows the minimum physical platform solution summaries for year 1. The solution summary was generated by the CPT Design tab. Each of the platform tier is supported by a single server; if any server were to fail, the services would no longer be available for those users.

Year 1 minimum physical server platform selections.

  • Two (2) Xeon E5-2637v4 4-core platforms, 64 GB RAM.
  • Two (2) Xeon E5-2637v4 4-core platforms, 32 GB RAM.

Minimum physical server platform solution = $17,424.

Year 1 HA physical server platform selections.

  • Four (2) Xeon E5-2637v4 4-core platforms, 64 GB RAM.
  • Four (2) Xeon E5-2637v4 4-core platforms, 32 GB RAM.

Year 1 HA physical server platform solution = $34,848.

The City of Rome hardware pricing list was used to identify the cost for these solutions.

Warning: The hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing.


CPT Design analysis for high-availability virtual platform solution: Year 1

Selecting the right enterprise design solution is critical for system implementation success. The Esri Capacity Planning Tool translates identified business requirements to selected platform loads, identifying an acceptable platform solution with capacity to satisfy business processing needs. Critical information is provided with this link to the Capacity Planning Tool Appendix.

High-availability virtual platform solution summary: Year 1
Figure 11.16 City of Rome Year 1 high-availability virtual platform solution summary.

Figure 11.16 shows the high-availability virtual platform solution summaries for year 1. The solution summaries were generated by the CPT Design tab.

Year 1 HA virtual solution (Virtual Citrix Tier):

  • Two (2) Xeon E5-2637v4 8-core platforms, 192 GB RAM.
  • Four (4) host platform processors (chips).

HA virtual server platform solution = $44,428

Warning: Host platform per-core performance and overall throughput capacity determines the number of required virtual servers. Host platform with faster processor cores provide the best return on investment.
Note: Host platform utilization leaves adequate capacity for additional virtual servers (i.e. test, development, and staging machines) .
Warning: Hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing.


City of Rome System Architecture Design: Year 2

Technical architecture strategy: Year 2

Figure 11.17 City of Rome Year 2 user location and bandwidth connectivity.

Figure 11.17 shows the City of Rome year 2 implementation strategies.

A server-based architecture in the central IT data center will be expanded to support the year 2 implementation.

  • Server platforms will include a Windows Terminal Server farm to support the remote ArcGIS for Desktop users.
  • ArcGIS for Server with Portal for ArcGIS to support the internal web services. Internal Web services will be registered with Portal for ArcGIS to expand collaboration and sharing.
  • ArcGIS for Server to support the public web services.
  • A central GIS data server to support the enterprise geodatabase.

City Hall data center remote network connections:

  • Data center — 1000 Mbps LAN connection
  • Data center - 90 Mbps WAN connection (year 1 upgrade)
    • Site 2 Operations facility—12 Mbps WAN connection (year 1 upgrade)
    • Site 3 Freeberg—45 Mbps WAN connection (year 1 upgrade)
    • Site 4 Willsberg—24 Mbps WAN connection (year 1 upgrade)
  • Data center — 24 Mbps Internet connection (year 1 upgrade)
    • Public web services will connect through the data center Internet connection.
    • Site 5 Perth—1.5 Mbps Internet connection
    • Site 6 Wawash—1.5 Mbps Internet connection
    • Site 7 Jackson—1.5 Mbps Internet connection
    • Site 8 Petersville—1.5 Mbps Internet connection
    • Site 9 Rogerton—1.5 Mbps Internet connection

Additional data center Internet clients:

    • Emergency vehicles—56 Kbps Internet connection to each vehicle
    • Snow plows—56 Kbps Internet connection to each vehicle

A separate police department network will be deployed with their own GIS server.

  • Police Data Center – 100 Mbps LAN connection
  • Police Data Center — 1.5 Mbps WAN connection
  • Police vehicles — 56 Kbps WAN connection to each vehicle


User requirements analysis: Year 2

Figure 11.18 City of Rome Year 2 user needs summary

Once you complete the year 1 design, you are ready to complete the system architecture design for the City of Rome year 2 full deployment plans. Figure 11.18 shows the user needs summary for year 2.

The City of Rome Year 2 user needs summary will be used as a reference to configure the CPT Design requirements analysis module.

The CPT user requirements requirements analysis includes all of the Year 2 workflows identified during the business needs analysis.

  • Common workflows can be consolidated at each site location to simplify the display.
  • The CPT workflows must track back to represent the user requirements analysis.


Network suitability analysis: Year 2

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Network upgrade recommendations: Year 2

Figure 11.19 Network bandwidth upgrades are provided from the City of Rome Year 2 network suitability analysis.

Based on your network suitability analysis, Figure 11.19 shows a list of the Year 2 network upgrade recommendations.

Network bandwidth upgrade recommendations must be coordinated with the City of Rome network administrator and included in the network infrastructure upgrade budget.

Warning: Serious performance issues will impact use productivity during peak loads if required network bandwidth is not available in production.

Once network contention is resolved, you are ready to move on to the platform architecture selection.

Platform architecture selection: Year 2

Figure 11.20 Two platform architecture solutions will be evaluated for the City of Rome Year 2 analysis.

Figure 11.20 shows the architecture selection objectives of the City of Rome Year 2 analysis. High-availability physical and virtual server solutions will be considered in the design review. The City would also like to evaluate a highbred cloud architecture deploying their public Web services in the Amazon cloud.

Platform solution candidates:

  • High-availability physical configuration: Identify the minimum high-availability physical server configuration architecture required to support peak production load requirements.
  • High-availability virtual configuration: Identify the minimum high-availability virtual server configuration architecture required to support peak production load requirements.
  • Amazon Web Public Services: Evaluate the benefits for deploying public web services on ArcGIS for Server Amazon Machine Instances (AMIs).


Enterprise design solution: Year 2

High availability platform solution summary: Year 2
Figure 11.21 City of Rome Year 2 high availability physical and virtual platform solution summary.

Figure 11.21 shows the high-availability physical and virtual platform solution summaries for year 2. Once you complete the CPT Design platform architecture selection and software configuration, Excel completes the system architecture design analysis and provides the platform solution.

Year 2 HA physical platform solution:

  • Seven (7) E5-2637v4 4-core physical servers, 64 GB RAM.
  • Four (4) E5-2637v4 4-core physical servers, 32 GB RAM.

HA physical server platform solution = $48,972.

Year 2 HA virtual platform solution:

  • Two (2) E5-2699v4 44 core (2 chip) 2200 MHz, 448 GB RAM host platforms.
  • Four (4) host platform processors (chips).
Warning: Host platform per-core performance and overall throughput capacity determines the number of required virtual servers. Host platform with faster processor cores providing the best return on investment.
Note: Host platform utilization leaves adequate capacity for additional virtual servers (i.e. test, development, and staging machines) .
Warning: The hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing.


CPT Design analysis for data center without hosting public Web services

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Data center solution without web public services: Year 2
Figure 11.22 City of Rome Year 2 high-availability virtual platform solution without hosting web public services.

Figure 11.22 shows the high-availability virtual platform solution summary without web public services for year 2. The solution summary was generated by the CPT Design tab. Each platform tier is supported by at least two servers; if any server were to fail, the remaining server would continue providing required user services.

Year 2 HA platform solution without the web public services:

  • Two (2) E5-2699v4 44-core (2 chip) 2200 MHz, 384 GB RAM host platforms.
  • Four (4) host platform processors (chips).


Warning: Host platform per-core performance and overall throughput capacity determines the number of required virtual servers. Host platform with faster processor cores provide the best return on investment.

HA virtual server platform solution = $104,876

Warning: Hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing.


Public web services deployed on the Amazon cloud

Amazon pricing assumptions
Figure 11.23 Typical Amazon server instance pricing.

Accurate pricing of cloud hosting services can be challenging.

  • Host platform performance information may not be available.
  • A variety of fixed and variable pricing models may be used for computing your monthly bill.
  • Pricing over time is subject to change.
Best practice: Work with the cloud vendor to understand their pricing models and associated hosting platform performance.
Pricing for the City of Rome analysis is based on the following

Amazon virtual machine instances. Figure 11.23 shows the Amazon Reserved Instances (3 year term upfront) pricing. Three-year term instances were used for this study.

Additional pricing factors include:

  • Initial data load = $84 (device + load time)
  • S3 storage = $0.030 per GB/month
  • Internet data transfer IN = $0.00 per GB
  • Data transfer OUT = $0.09 per GB/month (First GB/month free)
  • Elastic load-balancing = $0.025 per instance hour
  • Load Balance traffic charge = 0.008 per GB in/out
Warning: Amazon pricing is subject to change and may not represent the values used in this case study.


CPT Calculator analysis for Amazon Cloud public services configuration

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Amazon hosted pubic web servers pricing summary
Figure 11.24 Summary of total Amazon hosting costs for two servers over three years.

Figure 11.24 shows an overview of the Amazon pricing analysis for hosting the City of Rome public Web mapping services based on Year 2 throughput estimates. The pricing analysis assumed the estimated year 2 throughput would be consistent over the next three years, and pricing was based on a three year fixed term. The three year term was selected for comparison based on life cycle cost for similar purchased hardware (3 year life cycle).

Data in estimates:

  • Assume 100 GB initial data source, with 10 GB updates per month
  • $84 for initial data load (AWS Import/Export service for 100 GB data)
  • $216 for S3 storage (200 GB x 0.03/month x 36 months)

Data out estimates (100,000 peak TPH, average 300,000 transactions per day):

  • 2.1 Mbpd traffic per transaction (79 GB per day, 2,363 GB per month)
  • $212 per month (2,363 GB @ $0.09 after first GB)
  • $7,655 over three years ($212 x 36 months)

Elastic load balancing (ELB) costs:

  • $1,314 total hour cost (2 instances x 24 hrs/day for three years @ $.025/hr)
  • $680 traffic cost (2,363 GB/month @ $.008/GB for three years)

Overall cost estimate is less than $13,000 over three years.

For this study, two machines were capable to satisfy peak throughput needs and both were needed to meet high availability requirements. The three-year fixed term rates provided the best buy for this study.

Best practice: One of the primary advantage of deploying public Web services in the Cloud is server elasticity. In the event the peak throughput loads were to rapidly increase, additional servers could be deployed in time to accommodate the increased throughput loads.
Warning: Amazon pricing is subject to change and may not represent the values used in this case study.


City of Rome Police Department System Architecture Design

Police Workflow loads analysis: Year 2

Figure 11.25 City of Rome Police department Year 2 user needs summary

Figure 11.25 shows the Police Department user needs summary for year 2.

The City of Rome Police Department Year 2 user needs summary will be used as a reference to configure the CPT Design requirements analysis module.

User requirements analysis

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Network suitability analysis

Critical information is provided with this link to the Capacity Planning Tool Appendix.

CPT Design software configuration

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Enterprise design solution

CPT Design analysis for high availability virtual platform configuration

Critical information is provided with this link to the Capacity Planning Tool Appendix.

High availability virtual platform solution summary
Figure 11.26 Police high-availability virtual platform solution summary.

Figure 11.26 shows the City of Rome Police Department high-availability virtual platform solution summary. The solution summary was generated by the CPT Design tab. Each platform tier is supported by at least two servers; if any server were to fail, the remaining server would continue providing required user services.

Police HA virtual platform solution:

  • Two (2) Xeon E5-2637v4 4-core (2 chip) Host servers, 96 GB RAM for failover configuration
  • Two (2) host platform processors (chips).
Best practice: Batch and synchronization services are both sequential batch processes and will perform well on a single core server.

Police server platform costs = $20,814.

Rome City Hall business case summary

The pricing summary can be used to make final deployment decisions.

Figure 11.27 Estimated pricing summary for Rome City Hall year 1 server configurations.

Figure 11.27 shows the Rome City Hall Year 1 server deployment alternatives.

Additional $9,580 cost for the high-availability virtual server configuration. Additional savings would be realized by IT management.

  • Opportunity to consolidate servers and reduce administration costs.
  • More adaptive and manageable server environment.
  • Better server provisioning and recovery capabilities.
Best practice: Virtual server deployment strategies save money.


Figure 11.28 Estimated pricing summary for Rome City Hall year 2 server configurations.

Figure 11.28 shows the Rome City Hall Year 2 server deployment alternatives.

Over $10,000 additional cost over 3 years by hosting web public services on Amazon Cloud.

  • Extends data center enabling rapid response to changing service requirements.
  • Introduces cloud compute model for future deployment savings.
Best practice: Deployment decision may consider more than cost benefits alone.


Choosing a system configuration

The best solution for a given organization depends on the distribution of the user community and the type of operational data in use. User requirements determine the number of machines necessary (to support the operational environment), the amount of memory required (to support the applications), and the amount of disk space needed (to support the system solution). The system design models provide target performance metrics to aid in capacity planning. The capacity planning tool incorporates standard templates representing the sizing models and provides a manageable interface to help in enterprise-level capacity planning efforts. The CPT can be a big help in applying the results of the user needs assessment.

User needs change as organizations change, so this assessment not only identifies platform and infrastructure specifications and sets performance targets for the initial implementation, it is also part of the process going forward. System upgrades, new technology solutions, tuning and optimizing performance--every implementation or change is like a new launch, insofar as you need to plan for it. Planning provides an opportunity to establish performance milestones that can be used to manage a successful GIS implementation. Performance targets used in capacity planning can provide target milestones to validate performance and scalability throughput deployment of the system.

CPT Capacity Planning videos

Previous Editions

City of Rome 38th Edition
City of Rome 37th Edition
City of Rome 36th Edition
City of Rome 35th Edition
City of Rome 34th Edition
City of Rome 33rd Edition
City of Rome 32nd Edition
City of Rome 31st Edition
City of Rome 30th Edition
City of Rome 29th Edition
City of Rome 28th Edition
City of Rome 27th Edition

System Design Strategies (select here for table of contents)
System Design Strategies 39th Edition (Fall 2016)
1. System Design Process 39th Edition 2. GIS Software Technology 39th Edition 3. Software Performance 39th Edition 4. Server Software Performance 39th Edition
5. GIS Data Administration 39th Edition 6. Network Communications 39th Edition 7. GIS Product Architecture 39th Edition 8. Platform Performance 39th Edition
9. Information Security 39th Edition 10. Performance Management 39th Edition 12. City of Rome 39th Edition 11. System Implementation 39th Edition
A1. Capacity Planning Tool 39th Edition B1. Windows Memory Management 39th Edition Preface (Executive Summary) 39th Edition SDSwiki What's New 39th Edition

Page Footer
Specific license terms for this content
System Design Strategies 26th edition - An Esri ® Technical Reference Document • 2009 (final PDF release)