City of Rome 33rd Edition

From wiki.gis.com
Jump to: navigation, search
System Design Strategies (select here for table of contents)
System Design Strategies 33rd Edition (Fall 2013)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. Server Software Performance
5. GIS Data Administration 6. Network Communications 7. GIS Product Architecture 8. Platform Performance
9. Information Security 10. Performance Management 11. System Implementation 12. City of Rome
A1. Capacity Planning Tool A2. ESD Planning Tools A3. Acronyms and Glossary Preface (Executive Summary)


Fall 2013 City of Rome 33rd 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

GIS business planning

Figure 12.1 System architecture design should be an integral part of GIS business planning.

Figure 12.1 shows the process for GIS planning. GIS planning provides a foundation for building and maintaining successful GIS operations.

Planning begins by thinking about what you want out of the system.

  • What is the overall business strategy?
  • What are the critical business processes?
  • What information products drive business decisions?
  • What are the critical data resources?
  • How does GIS support current business operations?
  • What are the current business needs?
  • What are the GIS software technology needs?
  • What are the available software technology deployment patterns?
  • What is the process for migrating business operations to the new technology state?
  • What are the costs and benefits for making this business change?

These are some of the questions that are addressed during a typical business needs assessment.

System architecture design is a process for identifying the required network and platform infrastructure. Network and platform infrastructure must satisfy peak system capacity and performance needs to enable planned business operations.

Best practice: System architecture design should be included as an integral part of every business planning process.


System architecture design

Figure 12.2 System architecture design provides the foundation for building a successful GIS.

Figure 12.2 shows the system architecture design process. System architecture design is an integral part of the GIS business needs assessment.

GIS enterprise operations are both compute processing and network traffic intensive, which means:

  • GIS operations can place heavy demands on server processing and network traffic loads.
  • Network capacity can be one of the determining factors driving proper software technology selection.
  • In some cases, hardware constraints can drive software technology selection.
Best practice: Infrastructure requirements should always be understood and considered before making a final software technology selection.


Maintain a current plan

Figure 12.3 GIS planning should be updated annually and integrated into your overall enterprise business planning process.

Figure 12.3 emphasizes the importance of maintaining a current GIS plan.

Planning is critical for:

  • Providing a framework for enterprise GIS implementation.
  • Ensuring upper management support for required GIS investments.
  • Managing the evolution of enterprise GIS operations.

Technology is changing more rapidly every year.

  • During the 1990s, GIS planning was a detailed, rigorous process required to identify and justify major changes in business processes necessary to achieve the benefits provided by GIS technology. GIS implementation would take several years to reach the final planned state—and technology would be relatively stable throughout that period.
  • Today, technology is changing much faster, and it is difficult to plan for more than one year at a time. Technology keeps improving, and adjustments must be made each year to keep pace with the change. Planning methodology is becoming more agile, adapting to the rapid change in technology.
Best practice: Enterprise GIS planning is an ongoing process, and should be updated on an annual basis to keep pace with technology.

Most GIS deployments evolve over many years of incremental technology improvements, and:

  • Implementation plans normally address a two- or three-year schedule to ensure that the budget is in place for the anticipated deployment needs.
  • Project planning should be adjusted annually to take advantage of technology improvements and adjust for technology change.


Figure 12.4 CPT can be very useful tool for representing your enterprise GIS operations.

Figure 12.4 shows the CPT Design, a snapshot of a GIS plan identifying user needs, site locations, peak system loads, and platform solution for a specific target architecture (point in time). Changes in user workflow requirements will adjust loads on the selected platform solution. Changes in the platform architecture will identify expected performance improvements and system capacity. The CPT is a simple analysis tool that is easy to change and understand. The CPT provides an adaptive design model representing your GIS enterprise environment.

Best practice: The Capacity Planning Tool provides simple to use framework for GIS system design analysis and planning.


City of Rome case study

Figure 12.5 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 12.5 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.6 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 12.6 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.

Business requirements can be grouped into three areas:

  • Enterprise vision
  • Existing business architecture
  • User workflow requirements
Best practice: Each of these areas should be explored in some detail before you begin your system architecture design.


Enterprise vision

Figure 12.7 GIS technology has evolved to support a broad integrated range of business needs across the organization. Each GIS technology pattern is optimized to address specific organizational needs.

Figure 12.7 shows an overview of the ArcGIS technology patterns. GIS enterprise vision looks at how GIS technology can best support your business needs. ArcGIS includes a range of technology options developed as a complete set of integrated workflows and systems to satisfy a broad range of business requirements.

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

  • Asset management
  • Planning and analysis
  • Field mobility
  • Operational awareness
  • Constituent engagement

Most successful enterprise GIS operations evolve to embrace the full range of available GIS technology patterns to address focused business needs throughout their organization.

Best practice: Establishing a clear enterprise GIS vision early in planning can help identify an optimum roadmap for building effective GIS operations.

Existing Business Architecture

Business architecture defines the current state of how you are meeting your business requirements. This includes a review of your platform and network architecture, governance and political landscape, types of user communities, operational constraints and priorities, and existing funding constraints. This is information that can be leveraged to identify a GIS design solution that builds on your current business operations.

Platform and network environments

Figure 12.8 The current IT environment can provide insight into administrative staff experience and policies in working with available technology.

Figure 12.8 shows the types of software, network, servers, and data sources maintained within most business environments. Whether on your own or in concert with a design consultant, you should review the vendor platforms and network environments currently maintained by your organization.

Hardware experience, maintenance relationships, and staff training represent a considerable amount of investment for any organization.

Best practice: Proposed GIS design solutions should take advantage of corporate experience gained from working with the established platform and network environment.


Governance and political landscape

Figure 12.9 System architect must consider corporate goals and policy standards in selecting the proper design solution.

Figure 12.9 shows how the organization governs and manages its business operations. Organizations often develop policies and standards that support their software and hardware investment decisions.

A review of management preferences and associated vendor relationships will provide insight into a design solution that can be supported best by the organization.

Meet with the GIS and IT managers to review any policies or preferences they may have for the design. Major system upgrades often provide a chance for reviewing new platform technology directions, and management may want to include specific alternative technology patterns they are considering in the design effort.

Use the right language

Figure 12.10 It is important to recognize and use the proper terminology when discussing design issues.

Figure 12.10 shows the importance of using the right language to get your message across.

Best practice: Take time to listen.

Successful design consulting requires some communication skills.

  • Often the language used by the technical staff is very different than what is used by the user community.
  • Performance and user productivity is often viewed differently by the IT staff and the user community.
  • Technology is changing rapidly, along with the words that are used to describe system loads, architecture patterns, system performance and capacity needs.
  • Words that are used to describe GIS technology patterns change and many design concepts are not well understood.
Best practice: The words you use, how you listen, and how you speak establishes your credibility with both the user community and the technical IT staff. Credibility is very important in leading a mixed group of business users, technical architects, and system administrators toward a proper design decision.


Operational constraints and priorities

Figure 12.11 System availability, security standards, and specific operational performance requirements with guide the proper platform architecture design recommendations.

Figure 12.11 shows some key constraints that impact the system architecture design. Understanding the type of operations supported by the GIS solution will identify requirements for fault tolerance, security, application performance, and the type of client/server architecture that would be appropriate to support these operations.

System availability requirements

Most enterprise operations include several additional platform requirements in addition to their production environment.

  • Development and test platforms
  • Staging platforms
  • Redundant maintenance and publishing database environments
  • Possible remote backup data center
  • Possible cloud collaboration and publishing services
Warning: All business requirements and priorities are not the same, and it is important to listen and understand what is important in making the final design recommendations.
Security requirements

Identify the level of security governing the current business operations

  • Basic - no sensitive data.
  • Standard - moderate consequences for data loss or integrity
  • Advanced - sensitive data

What security standards are currently in place?

  • Published Web services standards
  • Data production and distribution access standards
  • Access protection for Web application servers and data sources.
Performance requirements

Identify any performance concerns being addressed by the new design

  • User productivity
  • Remote access
  • Public web services
  • Geoprocessing timelines
  • Batch process timelines
Best practice: High availability, redundancy, security, and special performance considerations drive requirements for increased hardware and software costs. Recommendations should be backed up with facts to support proper cost and benefit analysis.


Funding constraints

Figure 12.12 Recommended solutions must fit within reasonable organizational funding constraints or they will not be accepted.

Figure 12.12 shows the projected GIS operations budget.

Warning: The final design must be affordable.

An organization will not implement a solution that is beyond its financial resources.

  • With system design, cost is a function of performance and reliability.
  • If cost is an issue, the system design must facilitate a compromise between user application performance, system reliability, cost and schedule.
  • The design consultant must identify a hardware solution that provides optimum performance and reliability within identified budget constraints.

Current technology enables distribution of GIS solutions to clients throughout an enterprise environment, but there are limitations that apply to any distributed computer system design.

  • It is important to clearly understand real GIS user needs and discuss alternative options for meeting those needs with system support staff to identify the most cost-effective solution.
  • It may be necessary to review several alternative software technology patterns along with a variety of system deployment options to identify and establish the best implementation strategy.


User requirements analysis

User location and connectivity

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

Figure 12.13 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.14 User workflow patterns are normally a product of a user needs assessment and provide a reference for establishing workflow loads for the system architecture design.

Software technology workflow patterns are normally identified during a user requirements analysis. The Figure 12.14 workflow patterns were identified for the City of Rome.

The user workflow analysis will review each of these technology patterns and identify appropriate software component processing loads for each of the identified use cases. These user workflow loads will determine computer processing and network capacity requirements.

The CPT Calculator tab provides the capability for generating custom user workflow models to represent a broad range of software technology patterns.

  • The CPT Calculator and Design tools incorporate all the platform sizing models Esri has used for system design consulting services over the past 20 years. GIS software workflow patterns were identified in Chapter 2. Workflow performance recipes were introduced in Chapter 3.
  • New technology patterns are included with each software release.
  • The tool's ability to dynamically model available system design alternatives provides an adaptive, integrated, management view of a complete system architecture design solution.

There is a tradeoff between simplicity and complexity in representing user workflows in a system architecture design.

  • Simplicity is easier to understand, simpler to quantify, enables broader validation, helps quantify business risk, and provides valuable information on which to base business decisions.
  • Complexity may be more accurate, may provide a closer representation of the final implementation, and may lead to more detailed results; yet complex models can be much more difficult to understand, harder to quantify, more difficult to validate, and may include hidden risk.

During the initial planning phase, it is best to develop the most simple representation of your system architecture design solution that will lead to the right business decisions.

Best practice: A simple model is best: it highlights the relationship between what the organization wants to do with GIS (what you want out of the system) and the technology you need to do it (software, hardware, and network infrastructure procurement decisions).

Planning should establish performance targets that you can identify and validate throughout system deployment.

  • The CPT models used during planning are based on what is learned from performance benchmark testing and what other people are able to do with the technology. Software performance targets were introduced in Chapter 3.
  • You can use the CPT models to establish your own system performance targets, based on your specific infrastructure limitations and operational needs. You can also use the workflow performance models introduced in Chapter 3.

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.15 User requirements for City of Rome Year 1 establish peak business throughput loads for the Year 1 system architecture design.

Figure 12.15 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.16 User requirements for City of Rome Year 2 establishes peak business throughput loads for the year 2 system architecture design.

Figure 12.16 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.17 A requirements analysis summary provides a more condensed overview of user workflow requirements you will use to complete the system architecture design.

Figure 12.17 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
Figure 12.18 Custom project workflows established for the City of Rome system design.

Figure 12.18 shows the results of our City of Rome workflow loads analysis.

The workflow performance targets (component software service times) generated by the CPT Calculator can be included in the City of Rome project workflows located on the CPT Workflow tab.

Each organization's solution will be different.

  • Several decisions must be made during the design process before a final representation is collected in the capacity planning tool.
  • The process and discussion leading up to the final design should be documented as a record of decisions made during the design process.
  • Design documentation should clearly define the basis for the final workflow representation.



CPT Workflow definitions
Figure 12.19 A workflow description includes the workflow recipe generated by the CPT Calculator during the initial workflow analysis. Workflow names are then changed to a more recognizable reference for use during the design.

Figure 12.19 shows the CPT Calculator recipe used to generate the City of Rome project workflows.

Assumptions made during the technology selection process must be carried through project implementation. This is a single point where many GIS implementation fail — assumptions are made during the initial system architecture design that is lost when developing and implementing the final software technology solution.

A change control process should be established to ensure that any modification to the initial design assumptions are properly reviewed and approved before change acceptance.

  • The approval process should include an assessment of potential performance and scalability risks.
  • The CPT Calculator and CPT Design tools will provide a valuable framework to document and manage technology change and make proper assessments during system design and deployment.


CPT hardware platform candidates
Figure 12.20 City of Rome hardware platform candidates are moved to the Project Platform Candidates area on the Hardware tab for easy access during the design process.

Figure 12.20 shows how to identify project hardware candidates on the CPT Hardware tab. Hardware candidates should be reviewed for performance and capacity metrics. Most vendors publish performance benchmarks for their platform configurations on the SPEC Web site.

Hardware procurement standards are normally established by the IT department.

  • Enterprise-level procurement agreements are often made with hardware vendors to streamline the procurement process.
  • It is important to review the available hardware selections and do research to identify performance and capacity needs.
  • You will also need to understand if virtual server environments will be used, and review how this will impact your software licensing requirements.

The CPT Hardware tab is used as a lookup list for capacity planning hardware performance metrics.

  • The CPT Calculator and Design tabs gather platform performance metrics from the Hardware tab.
  • All platform configurations used in your CPT Design must first be identified on the CPT Hardware tab.


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

Figure 12.21 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.22 System architecture design process provides a logical step-by-step methodology for using the CPT to complete your system architecture design.

Figure 12.22 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.


City of Rome System Architecture Design: Year 1

Technical architecture strategy: Year 1

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

Figure 12.23 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.24 City of Rome Year 1 user needs summary

Figure 12.24 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 10x7 Feature +$$ (local workstation DeskEdit users)
    • DeskView: AGD102 wkstn MXD 50%Dyn Lite 10x7 Feature +$$ (local workstation DeskView users)
    • RemoteGISView: AGD102 Citrix MXD V 50%Dyn Med 10x7 ICA +$$ (remote DeskView clients)
    • WebInternal: AGS102 REST MSD V 50%Dyn Med 10x7 PNG24 +$$ (LocalMap services)
    • WebPublic: AGS102 REST MSD V 50%Dyn Lite 10x7 PNG24 +$$ (PublicMap services)
    • BatchAdmin: AGS102 REST MSD R 100%Dyn Med 10x7 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

Figure 12.25 The City of Rome workflows are configured in the CPT Design requirements module to represent the Year 1 business needs.

Figure 12.25 shows the CPT Design year 1 workflow configuration. The CPT requirements analysis includes all of the Year 1 workflows identified during the business needs analysis.

While you configure the user requirements and site locations in the CPT, and update the site traffic summation ranges to include all site workflow traffic going over the network connections (these CPT configuration procedures were discussed in lesson 6), Excel will complete the network suitability analysis.

Several performance problems are identified in the existing design due to network traffic bottlenecks.

  • Red cells in columns F:G identify traffic bottlenecks.
  • Recommend network upgrades to about twice identified network traffic.

Recommended network upgrades should be roughly double the peak traffic flow:

  • WAN from 1.5 Mbps to 24 Mbps
  • Site 2 from 1.5 Mbps to 3 Mbps
  • Site 3 from 1.5 Mbps to 12 Mbps
  • Site 4 from 1.5 Mbps to 12 Mbps
  • Internet from 1.5 Mbps to 24 Mbps


Figure 12.26 User workflow performance looks good once network bandwidth upgrades are completed (no red boxes).

Figure 12.26 shows the CPT Design Year 1 network suitability upgrades. Recommended network upgrades are included in column H.

RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.

CPT Design shows network bottlenecks are resolved.

  • Workflow performance summary shows relative user display performance.


Network upgrade recommendations: Year 1

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

Based on a completed network suitability analysis, Figure 12.27 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.28 Three platform architecture solutions will be evaluated for the City of Rome Year 1 analysis.

Figure 12.28 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

Figure 12.29 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 12.29 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

Figure 12.30 Platform architecture selection for City of Rome physical hardware solutions.

Figure 12.30 shows the physical platform tier configuration for year 1. Data center servers will be configured in four separate platform tier. Citrix terminal server farm will host the remote desktop clients, separate tier will be provided for the internal and public Web mapping services, and a single DBMS will provide the data source for internal GIS data. The minimum server configuration is focused on the production system - existing hardware will be used for development, testing, and staging environments.

Platform tier configuration

  • WTS: Platform Tier 07 will host the Citrix Terminal Server farm.
  • WebIn: Platform Tier 08 will host the web internal ArcGIS for Server web and SOC software components.
  • WebPub: Platform Tier 09 will host the web public ArcGIS for Server web and SOC software components.
  • DBMS: Platform Tier 10 will host the SDE geodatabase server platform.

The minimum physical platform configuration will use the fastest available processor to minimize overall system costs. The same platform will be used for all server tiers.

Platform selection

  • Client workstation: Intel Core E5-1620 (1 chip) 3600 MHz selected to represent the client workstation environments.
  • Data center server tier: Xeon E3-1290v2 4-core (2 chip) 3700 MHz platform selected for the physical server solutions based on highest performing best buy 4-core server configuration.
  • 80 percent rollover selected for all server platform tier.


CPT Design Software configuration

Figure 12.31 Software configuration for City of Rome platform solutions.

Figure 12.31 shows the CPT software configuration module selections for year 1. For each workflow, the software is assigned to the appropriate platform tier and SDE_DBMS is selected as the data source. The internal Web mapping services are assigned to the WebIn platform tier and the public Web mapping services are assigned to the WebPub platform tier. All workflows will use an SDE direct connect architecture when accessing the Geodatabase.

Default Row 5 software assignment:

  • Client software set to client
  • Citrix software set to WTS platform tier
  • Web software set to WebIn platform tier (internal web services)
  • SOC software set to WebIn platform tier (internal web services)
  • SDE software set to Default (direct connect)
  • DBMS software set to DBMS platform tier

WebPublic workflow software assignment (row 22)

  • Web software set to WebPub platform tier (public web services)
  • SOC software set to WebPub platform tier (public web services)
  • DBMS software set to Default (Enterprise DBMS data source)

All remaining workflow software assignments set to default platform.

Enterprise design solution: Year 1

CPT Design analysis for Minimum physical platform solution - Year 1

Figure 12.32 Enterprise design solution for minimum physical platform architecture.

Once the Platforms and Workflow software are configured, Excel completes the system architecture design analysis and provides the platform solution. Figure 12.32 shows the minimum physical platform solution for year 1.

RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate Batch process productivity for the new configuration.

Minimum physical platform solution:

  • WTS tier: One (1) Xeon E3-1290v2 4-core (1 chip) 3700 MHz server with 47 GB RAM
  • WebIn tier: One (1) Xeon E3-1290v2 4-core (1 chip) 3700 MHz server with 12 GB RAM
  • WebPublic tier: One (1) Xeon E3-1290v2 4-core (1 chip) 3700 MHz server with 12 GB RAM
  • DBMS tier: One (1) Xeon E3-1290v2 4-core (1 chip) 3700 MHz server with 47 GB RAM


Minimum physical platform solution summary: Year 1
Figure 12.33 City of Rome Year 1 minimum physical platform solution summary.

Figure 12.33 shows the minimum physical platform solution summary 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 platform solution:

  • WTS: 1 x Xeon E3-1290v2 4-core (1 chip) 3700 MHz 48 GB RAM
  • WEB Internal : 1 x Xeon E3-1290v2 4-core (1 chip) 3700 MHz 12 GB RAM
  • WEB Public: 1 x Xeon E3-1290v2 4-core (1 chip) 3700 MHz 12 GB RAM
  • DBMS: 1 x Xeon E3-1290v2 4-core (1 chip) 3700 MHz 48 GB RAM

The hardware pricing list can be used to identify the cost for this solution. Minimum physical platform solution server platform cost = $40,970.

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-available physical platform configuration: Year 1

Figure 12.34 Enterprise design solution for high-availability physical platform architecture.

A copy of the CPT Design for the minimum physical platform configuration can be updated to provide results for the high-availability physical platform configuration. Once you update the CPT Design platform architecture selection and software configuration, Excel completes the system architecture design analysis and provides the platform solution. Figure 12.34 shows the high-availability physical platform solution for year 1.

The high-availability (High Avail) selection above each platform tier in column H will automatically generate the proper number of platform nodes for each tier.

  • WTS tier high-availability requirements include N+1 server nodes.
  • WebIn and WebPublic high-availability requirements include at least two server nodes.
  • DBMS high-availability requirements must include an additional failover data server node.
Best practice: The DBMS tier High Avail selection must be set as minimum to show a single server. SDE Geodatabase multi-platform active-active server configurations required more expensive software and added administration complexity - it is much easier and effective to increase the number of platform core and maintain a single server primary environment than to implement an active-active clustered geodatabase server solution. A standby server would be configured in a failover cluster configuration for high availability.

RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.

High-availability physical platform solution:

  • WTS tier: Two (2) Xeon E3-1290v2 4-core (1 chip) 3700 MHz servers with 47 GB RAM
  • WebIn tier: Two (2) Xeon E3-1290v2 4-core (1 chip) 3700 MHz servers with 12 GB RAM
  • WebPublic tier: Two (2) Xeon E3-1290v2 4-core (1 chip) 3700 MHz servers with 12 GB RAM
  • DBMS tier: One (1) Xeon E3-1290v2 4-core (1 chip) 3700 MHz servers with 47 GB RAM with additional failover server of the same configuration.


High-availability physical platform solution summary: Year 1
Figure 12.35 City of Rome Year 1 high-availability physical platform solution summary.

Figure 12.35 shows the high-availability physical platform solution summary for year 1. The solution summary was generated by the CPT Design tab. Each of the platform tier is supported by two servers; if any server were to fail, the remaining server would continue providing required user services.

Year 1 high-availability physical platform solution:

  • WTS: 2 x Xeon E3-1290v2 4-core (1 chip) 3700 MHz 48 GB RAM
  • WEB Internal : 2 x Xeon E3-1290v2 4-core (1 chip) 3700 MHz 12 GB RAM
  • WEB Public: 2 x Xeon E3-1290v2 4-core (1 chip) 3700 MHz 12 GB RAM
  • DBMS: 1 x Xeon E3-1290v2 4-core (1 chip) 3700 MHz 48 GB RAM with failover server

High-availability physical platform solution server platform cost = $111,480 based on provided hardware price list. This is twice the cost of the minimum physical server platform solution.

Warning: Hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing.
Note: Server utilization for each platform tier is less than 25 percent, suggesting there could be significant savings through server consolidation by implementing a virtual server solution.


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

Figure 12.36 Enterprise design solution for high available virtual platform architecture.

Copy of the CPT Design for the high-availability physical platform configuration can be updated to provide results for the high-availability virtual platform configuration. Once you update the CPT Design platform architecture selection and software configuration, Excel completes the system architecture design analysis and provides the platform solution. Figure 12.36 shows the high-availability virtual platform solution for year 1.

The Xeon E5-2667 12-core (2 chip) 2900 MHz server was selected as the virtual server host platform. This platform provides roughtly the same per core performance as the Xeon E5-2637 4-core 3000 MHz server with much more capacity (total of 12 core). The Xeon E5-2690 16 core (2 chip) 2900 MHz platform was also considered, and was rejected due to the higher virtual server cost ($4,500 per VM for 8 core chips).

Select a new host platform configuration for each virtual server and host platform tier.

  • Xeon E5-2667 12-core (2 chip) 2900 MHz platform
Best practice: E5-2667 12-core platforms were selected because they provide optimum virtual server consolidation capacity with minimum loss in per-core performance.

Select the virtual server configuration.

  • Select virtual server (VMware) selection for each tier in column I.
  • Select 2 core/node to set virtual core for each node.
  • Select Host01 for the host platform tier
Best practice: Two-core server configurations provide the best performance and throughput for virtual server platforms. CPT model increases workload service times to account for virtual server processing overhead.

Once virtual server selection is made, Excel completes the system architecture design analysis.

The RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate Batch process productivity for the new configuration.

High-availability virtual platform solution:

  • WTS tier: WTS: 3x VM (2-core 20 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
  • WebIn tier: WebIn: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
  • WebPub: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2667 2900 MHz servers
  • DBMS: 1x VM (2-core 20 GB RAM) deployed on Xeon E5-2667 2900 MHz servers with a failover VM with the same configuration
  • Host01: 2x Xeon E5-2667 2900 MHz host servers with 104 GB RAM
Note: Host memory requirements based on supporting all virtual server machines with single platform failure.
Best practice: Host platform HA configuration must support peak operations with single platform failure.


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

Figure 12.37 shows the high-availability physical platform solution summary for year 1. The solution summary was generated by the CPT Design tab. Each platform tier is supported by two servers; if any server were to fail, the remaining server would continue providing required user services.

Year 1 high-availability virtual platform solution:

  • Host01: 2x Xeon E5-2690 12-core 2900 MHz host platforms with 128 GB RAM
    • WTS: 3x 2-core virtual servers each with 20 GB RAM
    • WEB Internal: 2x 2-core virtual servers each with 6 GB RAM
    • WEB Public: 2x 2-core virtual servers each with 6 GB RAM
    • DBMS: 1x 2-core virtual server with failover server each with 20 GB RAM
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.


High-availability physical platform solution server platform cost = $45,428 based on provided hardware price list. This represents $36,512 hardware savings over the high-availability physical server platform solution.

Note: Host platform utilization is 16.7 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.


City of Rome System Architecture Design: Year 2

Technical architecture strategy: Year 2

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

Figure 12.38 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 - 24 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.

Police remote network connections:

  • Police — 1.5 Mbps WAN connection to data center
  • Police vehicles — 56 Kbps WAN connection to each vehicle


Workflow loads analysis: Year 2

Figure 12.39 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 12.39 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.

  • 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

Figure 12.40 The City of Rome workflows are configured in the CPT Design requirements module to represent the Year 2 business needs.

Figure 12.40 shows the Year 2 CPT Design workflow configuration. To simplify configuration effort, start with a copy of the Year 1 CPT Design tab (virtual server platform configuration) and add the Year 2 workflows to complete the business needs analysis.

While you configure the user requirements and site locations in the CPT, and update the site traffic summation ranges to include all site workflow traffic going over the network connections (these CPT configuration procedures were discussed in Chapter 6), Excel will complete the network suitability analysis.

Several performance problems are identified in the existing design due to network traffic bottlenecks.

  • Red cells in columns F:G identify traffic bottlenecks.
  • Recommend network upgrades to about twice identified network traffic.

Recommended network upgrades:

  • Data center LAN from 100 Mbps to 1 Gbps
  • Data center WAN from 24 Mbps to 45 Mbps
  • Site 2 from 3 Mbps to 24 Mbps
  • Data center Internet from 24 Mbps to 90 Mbps
  • Site 6 from 1.5 Mbps to 12 Mbps
  • Site 7 from 1.5 Mbps to 6 Mbps
  • Site 8 from 1.5 Mbps to 18 Mbps
  • Site 9 from 1.5 Mbps to 18 Mbps


Figure 12.41 User workflow performance looks good once network bandwidth upgrades are completed (no red boxes).

Figure 12.41 shows the Year 2 network suitability upgrades. Results of the network suitability analysis should be shared with the Network Administrator, and together identify upgrades for the year 2 network infrastructure to support the year 2 design. Recommended network upgrades are included in column H.

The RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.

CPT Design shows network bottlenecks are resolved.

  • Workflow performance summary shows relative user display performance for each workflow at each site location.


Network upgrade recommendations: Year 2

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

Based on your network suitability analysis, Figure 12.42 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 12.43 Two platform architecture solutions will be evaluated for the City of Rome Year 2 analysis.

Figure 12.43 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 highbrid cloud architecture deploying their public Web services in the Amazon cloud.

Platform solution candidates:

  • 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 availablility virtual platform configuration: Year 2

Figure 12.44 Enterprise design solution for high-availability physical platform architecture, year 2.

Confirm the virtual platform configuration: The Workflow Configuration sheet was copied from the Year 1 virtual server configuration and should have the proper hardware platform configuration set. Once you confirm the proper hardware configuration, Excel completes the system architecture design analysis. Figure 12.44 shows the year 2 high availability virtual platform solution.

The RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.

High-availability virtual platform solution: Host01 tier: 3x Xeon E5-2667 2900 MHz host servers each with 122 GB RAM

  • WTS tier: WTS: 10x VM (2-core 20 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
  • WebIn tier: WebIn: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
  • WebPub: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2667 2900 MHz servers
  • DBMS: 1x VM (4-core 40 GB RAM) deployed on Xeon E5-2667 2900 MHz servers plus an additional failover VM with the same configuration


High availability virtual platform solution summary: Year 2
Figure 12.45 City of Rome Year 2 high available virtual platform solution.

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

Year 2 high-availability virtual platform solution:

  • Host01: Xeon E5-2690 12-core 2900 MHz host platforms each with 128 GB RAM
    • WTS: 10x 2-core virtual servers each with 20 GB RAM
    • WEB Internal: 2x 2-core virtual servers each with 6 GB RAM
    • WEB Public: 2x 2-core virtual servers each with 6 GB RAM
    • DBMS: 1 x 4-core virtual server with failover server each with 40 GB RAM
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.

High-availability physical platform solution server platform cost = $68,142 based on provided hardware price list.

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

Figure 12.46 Enterprise design solution for high-availability physical platform architecture year 2 without WebPublic services.

Copy previous high availability virtual platform configuration — Year 2 solution on separate tab and delete WebPublic peak throughput from column D. Once you remove the WebPublic peak throughput, Excel completes the system architecture design analysis.

City decided to host the City Hall data center virtual servers on lower capacity E5-2643 8-core platforms to reduce overall system cost.

Figure 12.46 shows the City of Rome Year 2 data center solution without hosting the public web services.

The RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.

High-availability virtual platform design:

  • Host01 tier: 3x Xeon E5-2643 8-core (2 chip) 3300 MHz host servers each with 112 GB RAM
  • WTS tier: WTS: 10x VM (2-core 21 GB RAM) deployed on Xeon E5-2643 3300 MHz host servers
  • WebIn tier: WebIn: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2643 3300 MHz host servers
  • DBMS: 1x VM (4-core 43 GB RAM) deployed on Xeon E5-2643 3300 MHz servers plus an additional failover VM with the same configuration
Best practice: Publishing public services on the Amazon Cloud removes requirements to host these services in your data center environment.


High-availability virtual platform design solution without web public services: Year 2
Figure 12.47 City of Rome Year 2 high-availability virtual platform solution without hosting web public services.

Figure 12.47 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 high-availability virtual platform solution without the web public services:

  • Host01: 3x Xeon E5-2643 8-core 3300 MHz host platforms each with 112 GB RAM
  • WTS: 10x 2-core virtual servers each with 20 GB RAM
  • WEB Internal: 2x 2-core virtual servers each with 6 GB RAM
  • WEB Public: 2x 2-core virtual servers each with 6 GB RAM
  • DBMS: 1 x 4-core virtual server with failover server, each with 40 GB RAM
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.

High-availability physical platform solution server platform cost = $65,658 based on provided hardware price list. This represents $2,484 local data center hardware savings by not hosting the WebPublic services.

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 12.48 Typical Amazon server instance pricing.

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

Additional pricing considerations include:

  • Internet data transfer IN = $0.00 per GB
  • Data transfer OUT = $0.12 per GB/month (First GB/month free)
  • Regional data transfer = $0.02 per GB
  • Elastic load balancing = $0.025 per hour
  • Elastic load balancing 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
Figure 12.49 Single workflow design solution for Amazon Cloud Web Public services architecture year 2.

Figure 12.49 shows the CPT Calculator used to compute web public server platform solution. CPT Calculator can be used for completing a single workflow system architecture design sizing analysis.

Enter the Web public peak throughput and data source selections.

  • Peak throughput = 100,000 TPH
  • Select Small FGDB data source (you will use geodatabase replication services to publish data updates to the Amazon machine).

Amazon AMI Platform Selection:

  • Select AMI HM Extra Large Instance 2-core (6.5 CU) 17.1 GB as the platform selection.
Warning: The Amazon server instances performance specifications are included in the CPT Hardware tab based on [EC2 instance type compute resources information] provided on the Amazon Web site.
Best practice: The AMI HM Extra Large Instance 2-core (6.5 CU) 17.1 GB virtual server machine is Amazon's highest performing 2-core server configuration based on the information Amazon shares for the AMI instance performance.
  • Identify a two-tier high-availability configuration.
Best practice: Use ArcGIS for Server Cloud Builder to deploy services on the Amazon EC2 site.

Amazon Cloud platform solution:

  • GIS server: 2x HM Extra Large Instance 2-core (6.5 CU) 17.1 GB Amazon Machine Instance
  • Data source: File geodatabase

Amazon AMI pricing (based on pricing model):

  • Fixed cost for three-year term = $1,550
  • Variable cost of $0.14 per hour for 26,280 hours = $3679
  • Total cost per server = $5229
  • Cost for two servers = $10,458


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

Figure 12.50 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)
  • $342 for S3 storage (100 GB x 0.095/month x 36 months)

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

  • 1.2 Mbpd traffic per transaction (36 GB per day, 1,080 GB per month)
  • $130 per month (1,080 GB @ $0.12 after first GB)
  • $4,666 over three years ($130 x 36 months)

Elastic load balancing (ELB) costs:

  • $ 648 total hour cost (24 hrs/day for three years @ $.025/hr)
  • $ 388 traffic cost (1,350 GB/month @ $.008/GB for three years)

Overall cost estimate is less than $17,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.


Rome City Hall business case summary.

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

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

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

Over $36,512 savings with the high-availability virtual server configuration.

  • Able 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.

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

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

Over $14,103 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.


City of Rome Police Department System Architecture Design

Workflow loads analysis

Figure 12.53 The police workflows are configured in the CPT Design requirements module to represent business needs.

Figure 12.53 shows the City of Rome Police Department user needs and CPT Design workflow configuration. The CPT Design analysis is completed on a separate CPT Design tab. The CPT requirements analysis includes all of the police workflows identified during the business needs analysis. An additional batch process was included in the design to reserve core to accommodate one system administration batch process during peak system loads.

The RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.

The CPT Design shows no network bottleneck issues.

Network suitability analysis

Figure 12.54 Platform architecture selection for police hardware solution.

Figure 12.54 shows the Police hardware configuration. Separate single core VMs were established for the system administration batch process (Batch) and the mobile synchronization service (WebMap). The SDE geodatabase would be deployed on a single database server (DBMS).

Platform tier configuration:

  • Batch: Platform Tier 08 will host the batch process.
  • WebMap: Platform Tier 09 will host the web Mobile Synchronization service.
  • DBMS: Platform Tier 10 will host the SDE geodatabase server platform.

Xeon E3-1290v2 4 core (1 chip) 3700 MHz servers were selected as the host platform. The E3-1290v2 processor had a SPECrate_int2006 benchmark of 49.3 per core, one of the faster machines available in the 2013 procurement period.

Platform selection:

  • Client workstation: Intel Core E5-1620 4-core (1 chip) 3600 MHz selected to represent the client workstation environments.
  • Data center server tier: Xeon E3-1290v2 4-core (2 chip) 3700 MHz platform selected for the virtual host server platforms based on highest performing best buy 4-core server configuration.
  • 80 percent rollover selected for all server platform tier.


CPT Design software configuration

Figure 12.55 Police software was configured for a high-availability virtual server solution.

Figure 12.55 shows the software and virtual machine configurations. For each workflow, assign software to the appropriate platform tier and select appropriate data source.

Default Row 5 software assignment:

  • Client software set to client
  • Web software set to WebMap
  • SOC software set to WebMap (Mobile synchronization services)
  • SDE software set to Default (Direct connect)
  • DBMS software set to DBMS

Batch workflow software assignment (row 6):

  • Web software set to Batch (batch virtual machine)
  • SOC software set to Batch (batch virtual machine)
  • DBMS software set to Default (Police DBMS geodatabase)

All remaining workflow software assignments set to default platform.

Data source assignment SDE_DBMS for all workflows.

Enterprise design solution

CPT Design analysis for high availability virtual platform configuration

Figure 12.56 Police high-availability virtual platform solution.

Once the platforms and workflow software are configured, Excel completes the system architecture design analysis and provides the platform solution. Figure 12.56 shows the CPT Design Police virtual platform solution.

The RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.

High-availability virtual platform solution:

  • Host01 tier: 2x E3-1290v2 4-core (2 chip) 3700 MHz servers each with 18 GB RAM
    • Batch tier: 2x VM (1-core 3 GB RAM)
    • WebMap tier: 2x VM (1-core 3 GB RAM)
    • DBMS: 1x VM (2-core 24 GB RAM) plus an additional failover VM with the same configuration


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

Figure 12.57 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 high-availability virtual platform solution:

  • Host01: 2x E3-1290v2 4-core (2 chip) 3700 MHz servers each with 72 GB RAM
    • Batch: 2x 1-core virtual servers each with 3 GB RAM
    • WebMap: 2x 1-core virtual servers each with 3 GB RAM
    • DBMS: 1 x 2-core virtual server with failover server each with 22 GB RAM
Best practice: Batch and synchronization services are both sequential batch processes and will perform well on a single core server.


Police server platform costs were $29,574.

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 Video: City of Rome use case

CPT Video: City of Portland system design exercise demo

Previous Editions

City of Rome 32nd Edition (Spring 2013)
City of Rome 31st Edition (Fall 2012)

City of Rome 30th Edition (Fall 2011)
City of Rome 29th Edition (Spring 2011)
City of Rome 28th Edition (Fall 2010)
City of Rome 27th Edition (Spring 2010)

System Design Strategies (select here for table of contents)
System Design Strategies 33rd Edition (Fall 2013)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. Server Software Performance
5. GIS Data Administration 6. Network Communications 7. GIS Product Architecture 8. Platform Performance
9. Information Security 10. Performance Management 11. System Implementation 12. City of Rome
A1. Capacity Planning Tool A2. ESD Planning Tools A3. Acronyms and Glossary Preface (Executive Summary)

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