City of Rome 35th Edition

Spring 2015 City of Rome 36th 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. 

City of Rome case study
Figure 12.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 12.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:
 * Asset management
 * Planning and analysis
 * Field mobility
 * Operational awareness
 * 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

User requirements analysis
User requirements 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 12.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 12.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 medium complexity workflows.
 * Desktop viewers work primarily with much more focused map displays and can be classified as light complexity workflows.
 * Business Analyst desktop applications will be classified as a medium complexity workflow.
 * Remote desktop viewers will be supported from a centralized terminal server farm, and will be classified as light complexity vector 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 ADF client in the patrol cars with a relatively light synchronization service for updating business layers 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 analysis
The user workflow analysis will include a user requirements analysis for year 1 and year 2 to identify the workflows required to satisfy the City of Rome business requirements. 

User Requirements Year 1
Figure 12.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 requirements are used by the CPT to generate system loads (the processing and traffic requirements referred to above) and determine 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 Requirements Year 2
Figure 12.6 shows the user requirements for City of Rome year 1 deployment.

Year 2 includes:
 * Business Development department deployment of a new Business Analyst information system.
 * Engineering department deployment of Joint Tracking (JTX) work order management 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).
 * A Tracking Server implementation is also 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 a Tracking Server solution with the 20 police patrols.

User Requirements Summary
Figure 12.7 shows a requirements analysis summary for years 1 and 2

A user requirements 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 requirements analysis represents the business requirements used to complete a proper system architecture design."

Performing a proper requirements 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 requirements summary 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 requirements analysis, you are ready to continue with the system architecture design. 

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

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

CPT hardware platform candidates
Critical information is provided with this link to the Capacity Planning Tool Appendix.

CPT workflow and hardware platform favorites
Figure 12.11 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. 
 * The Favorites tab can be used as an alternative CPT Design workflow lookup list or CPT hardware selection list.
 * The Favorites tab allows you to organize your specific project workflows and platform selection options on a shorter selection list.
 * The Favorites tab also includes the selected workflow description and the selected platform specifications as a summary view of your project resources.

System design process
Figure 12.12 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.
 * Workflow loads 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.

Technical architecture strategy: Year 1
Figure 12.13 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—100 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.

Workflow loads analysis: Year 1
Figure 12.14 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 workflow 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 workflow requirements analysis includes all of the Year 1 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.

User needs summary (workflow recipe introduced in Chapter 3) 
 * User requirements include five workflows. Additional batch process was included for system administration use.
 * DeskEdit: AGD102 wkstn MXD 50%Dyn Med 19x10 Feature +$$ (local workstation DeskEdit users)
 * DeskView: AGD102 wkstn MXD 50%Dyn Lite 19x10 Feature +$$ (local workstation DeskView users)
 * RemoteGISView: AGD102 Citrix MXD V 50%Dyn Med 19x10 ICA +$$ (remote DeskView clients)
 * WebInternal: AGS102 REST MSD V 50%Dyn Med 13x7 PNG24 +$$ (LocalMap services)
 * WebPublic: AGS102 REST MSD V 50%Dyn Lite 13x7 PNG24 +$$ (PublicMap services)
 * BatchAdmin: AGS102 REST MSD R 100%Dyn Med 13x7 JPEG (reserved for batch administration 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
Critical information is provided with this link to the Capacity Planning Tool Appendix.

Network upgrade recommendations: Year 1
Based on a completed network suitability analysis, Figure 12.17 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 12.18 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 number of 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
City of Rome management requests that we complete a cost analysis for the various platform architecture patterns being proposed for this study. Figure 12.19 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 [2013 best buy platform recommendations] identified in the Platform Performance Chapter 8." 

CPT Platform architecture selection
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.

CPT Design analysis for physical platform solution - Year 1
Critical information is provided with this link to the Capacity Planning Tool Appendix.

Physical platform solution summary: Year 1
Figure 12.23 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-2637v2 4-core platforms, 96 GB RAM.
 * Two (2) Xeon E5-2637v2 4-core platforms, 23 GB RAM.

Minimum physical server platform solution = $43,000.

Year 1 HA physical server platform selections.
 * Four (4) Xeon E5-2637 4-core platforms, 96 GB RAM.
 * Four (4) Xeon E5-2637 4-core platforms, 23 GB RAM.

Year 1 HA physical server platform solution = $86,000.

The 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====

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

High-availability virtual platform solution summary: Year 1
Figure 12.28 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-2637v2 8-core platforms, 192 GB RAM.
 * Four (4) host platform processors (chips).

HA virtual server platform solution = $50,780

Year 1 HA virtual solution (Physical Citrix WTS Tier):
 * Two (2) Xeon E5-2637 4-core WTS platforms, 96 GB RAM.
 * Two (2) Xeon E5-2637 4-core Host platforms, 96 GB RAM.
 * Two (4) host platform processors (chips).

HA WTS physical with virtual server platform solution = $55,590

"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 is 23.3 percent during peak loads, which 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. " <br style="clear: both" />

Technical architecture strategy: Year 2
Figure 12.29 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 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 — 100 Mbps LAN connection
 * Data center - 18 Mbps WAN connection (year 1 upgrade)
 * Site 2 Operations facility—3 Mbps WAN connection (year 1 upgrade)
 * Site 3 Freeberg—12 Mbps WAN connection (year 1 upgrade)
 * Site 4 Willsberg—12 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. <br style="clear: both" />
 * Police Data Center – 100 Mbps LAN connection
 * Police Data Center — 1.5 Mbps WAN connection
 * Police vehicles — 56 Kbps WAN connection to each vehicle

Workflow loads analysis: Year 2
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 12.30 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 workflow requirements analysis includes all of the Year 2 workflows identified during the business needs analysis. <br style="clear: both" />
 * 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
Based on your network suitability analysis, Figure 12.33 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. <br style="clear: both" />

Platform architecture selection: Year 2
Figure 12.34 shows the architecture selection objectives of the City of Rome Year 2 analysis. The high-availability virtual server solution was clearly the best choice for Year 1, so that will be the first candidate solution. The City would also like to evaluate a highbred cloud architecture deploying their public Web services in the Amazon cloud.

Platform solution candidates: <br style="clear: both" />
 * 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
====CPT Design analysis for high availability virtual platform configuration: Year 2====

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

High availability virtual platform solution summary: Year 2
Figure 12.38 shows the high-availability virtual platform solution summary 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 virtual solution (Virtual Citrix Tier):
 * Three (3) Xeon E5-2667v2 16-core Host platforms, 256 GB RAM.
 * Six (6) host platform processors (chips).

HA virtual server platform solution = $83,370

Year 2 HA virtual solution (Physical Citrix Tier):
 * Three (3) Xeon E5-2637 8-core WTS platforms, 128 GB RAM.
 * Two (2) Xeon E5-2637 8-core Host platforms, 192 GB RAM.
 * 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. "

HA WTS physical with virtual server platform solution = $94,280.

"Note: Host platform utilization is 29.9 percent during peak loads, which 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. " <br style="clear: both" />

====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 12.42 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:
 * Three (3) Xeon E5-2637 8-core WTS servers, 128 GB RAM.
 * Two (2) Xeon E5-2637 8-core Host platforms, 128 GB RAM.
 * 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 = $92,480

"Warning: Hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing. " <br style="clear: both" />

Amazon pricing assumptions
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 12.43 shows the Amazon Reserved Instances (3 year term) pricing. Three-year term instances were used for this study.

Additional pricing factors include:
 * Initial data load = $85 (device + load time)
 * S3 storage = $0.030 per GB/month
 * Internet data transfer IN = $0.00 per GB
 * Data transfer OUT = $0.12 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. " <br style="clear: both" />

=
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 12.45 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 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
 * $85 for initial data load (AWS Import/Export service for 100 GB data)
 * $216 for S3 storage (200 GB x 0.030/month x 36 months)

Data out estimates (100,000 peak TPH, average 300,000 transactions per day):
 * 1.2 Mbpd traffic per transaction (45 GB per day, 1,350 GB per month)
 * $162 per month (1,350 GB @ $0.12 after first GB)
 * $5,832 over three years ($162 x 36 months)

Elastic load balancing (ELB) costs:
 * $ 389 total hour cost (2 instances x 24 hrs/day for three years @ $.025/hr)
 * $ 389 traffic cost (1,350 GB/month @ $.008/GB for three years)

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

The Amazon variable rates apply only when you are using the AMIs. Additional savings may be possible using elastic load balancing with on-demand instances. For this study, two machines were capable to satisfy peak throughput needs and both were needed to meet high availability requirements. The three year 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. " <br style="clear: both" />

Rome City Hall business case summary
The pricing summary can be used to make final deployment decisions.

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

Over $30,400 savings with the high-availability virtual server configuration (Citrix physical server tier).
 * Opportunity to consolidate servers and reduce hardware costs.
 * More adaptive and manageable server environment.
 * Better server provisioning and recovery capabilities.

Virtual server deployment strategies save money. <br style="clear: both" />

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

Over $13,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."

<br style="clear: both" />

City of Rome Police Department System Architecture Design
Critical information is provided with this link to the Capacity Planning Tool Appendix.

Workflow loads 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 12.52 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-2637v2 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 = $32,790 <br style="clear: both" />

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.

Previous Editions
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

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