City of Rome 30th Edition (Fall 2011)

Fall 2011 City of Rome 30th Edition

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. Both his book’s chapter 9 and this chapter show standard templates that can be used for most enterprise design studies. In this book 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.

GIS Business Needs Assessment
Figure 11-1 provides an overview of a typical GIS business needs assessment. A GIS application needs assessment should be completed by the business units that benefit from the GIS information products. The needs assessment should be led by in-house GIS staff with support from an executive sponsor. You may have used professional GIS consultants to facilitate the planning process, but all the decision making will come from your end—from the organization’s managers and decision makers.

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 should be addressed during a typical business needs assessment. 

Figure 11-2 provides an overview of the system architecture design process introduced in Chapter 1. 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. Infrastructure requirements should always be understood and considered before making a final software technology selection. 

Figure 11-3 highlights the importance and strategy for Enterprise GIS strategic planning. Planning is critical for justifying the required GIS investments, in providing a framework for enterprise GIS implementation, and for ensuring upper management support throughout the process. Planning is also important in managing 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. 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. For the City of Rome use case, we will use the Capacity Planning Tool to prepare for year 1 and year 2. The Capacity Planning Tool provides a very adaptive framework for representing your GIS user workflow requirements and the associated system infrastructure needs required to manage technology change.

City of Rome System Architecture Design
People skills and experience in maintaining distributed computer system solutions are important considerations when selecting a system design strategy. Maintenance of the distributed computer environment is a critical factor in selecting appropriate vendor solutions. It is important to understand and consider the experience and training invested by the organization in maintaining existing computer environments. The existing environment may in itself identify a particular design solution as the best fit for an organization. This along with other considerations listed in figure 11-4 must be analyzed and understood before you can develop a proper design solution.



Platform and Network 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. Proposed GIS design solutions should take advantage of corporate experience gained from working with the established platform and network environment.

Hardware Policies and Standards: Organizations develop policies and standards that support their hardware investment decisions. Understanding management preferences and associated vendor relationships will provide insight into a design solution that can be supported best by the organization.

Operational Constraints and Priorities: 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 Administration Experience: The skills and experience of the system support staff provide a foundation for the final design solution. Understanding network administration and hardware support experience, in conjunction with support staff preference for future administration strategies, will help guide the consultant to compatible hardware vendor solutions.

Financial Considerations: 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.

GIS Workflow Analysis
Figure 11-5 provides an overview of the GIS workflow analysis process. There are a few basic user requirements that must be understood before launching into the system design process. In order to design an effective system for GIS, you must come to grips with the basic factors that are the focus of the system architecture needs assessment.



These requirements compose the system architecture workflow needs assessment: identify where GIS users are located in relation to the associated data resources (site locations); what network communications are available to connect user sites with the GIS data sources; and what are the peak user workflow requirements for each user location.

GIS user locations. 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. Knowing where users are located, understanding what applications they will need to do their work, and identifying the location of the necessary data resources provides input values for the system design analysis.

Network Communications. 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. It is important to identify additional infrastructure costs during the planning process - you don't want to find this out after system deployment.

User Workflows. The system workflow loads are generated by the peak users and workflow software component service times and client display traffic discussed in Chapters 2 and 3. These user workflow loads will determine computer processing and network capacity requirements. Traditional capacity planning was done with simple workflow models, using separate models for GIS desktop workflows, Web Services, and batch processing. Platform sizing models were established to help select the right server platform technology. General network design guidelines were used to address communication suitability. These simple platform sizing models and network design guidelines demonstrated the benefits of a proper system architecture design in ensuring successful enterprise GIS implementations.

The capacity planning tool introduced in CY2006 (chapter 10) provides an opportunity for more granular workflow models than what was used for system architecture design in the past. The CPT Calculator and Design tools incorporate all the platform sizing models we developed over the past 16 years; and new technology is included with each software release. The tool’s ability to dynamically model the design alternatives provides an adaptive, integrated, management view of a complete technical solution.

There is a trade off between simplicity and complexity in representing 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 the technical solution that will lead to the right business decisions. 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 capacity planning tool models used during planning are based on what we learn from performance benchmark testing and what other people are able to do with the technology. You can use the CPT models to establish your own system performance targets, based on your specific infrastructure limitations and operational needs.

This chapter will show you how to build your own technical solution—one that can achieve your performance goals--based on validated performance fundamentals described in chapter 5. Afterward, you must monitor and validate that these goals are met throughout the GIS Implementation (see Chapter 12).

City of Rome user requirements analysis
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. In planning a GIS for this city, we’re going to look ahead to year 2 and year 3 even as we plan for the year 1 implementation.



Let’s begin by taking stock of the city government’s current situation and how exactly the organization and its employees are looking forward to using GIS. This city has more than 580 employees who require GIS information to help in their normal work processes (information products). These employees are located in the Planning, Engineering, Police, and Operations departments throughout the city. The public will also benefit from deployment of standard GIS information products through published Web applications (services). Each department provides a set of these Web services, which it shares with the public on the city’s Web site.

Figure 11-6 provides a simple diagram for identifying user locations throughout the operational environment. This is an overview of the facility locations and network communications to be addressed in the system design study. The point is to show how each user location is connected to the data center (LAN, WAN, Internet) along with the available network capacity (T1 existing environment, a 1.54 Mbps bandwidth).



GIS user types (GIS use cases)
The types of GIS users can be divided into three basic categories. The ArcGIS Desktop user type will require desktop applications for GIS processing. Web users will be supported by ArcGIS Server Web applications. An additional batch process to support replication services and standard administrative batch processing (reconcile and post, online backups, etc.) is the third user type.

ArcGIS Desktop: This category includes ArcGIS Desktop specialists doing general spatial query and analysis studies, simple map production, and general-purpose query and analysis operations, including all ArcEditor and ArcView clients. GIS applications for custom business solutions and any custom ArcGIS Engine clients that support specific business needs could also be included in this category.

For this study, separate workflows are identified for ArcGIS Desktop Editors and Viewers. A separate workflow is also included for ArcGIS Desktop Business Analyst. The initial Desktop workflows use the published Standard ESRI Workflow models. The Editors and Business Analyst workflows will use the medium dynamic performance targets, and the viewers will use the light dynamic performance targets. These workflows can be modified as required during system design and implementation as capacity planning performance targets are validated.

Web services: ESRI ArcGIS Server software provides transaction-based map products to Internet browser clients and supports synchronization with remote mobile clients. The City of Rome will use the ArcGIS Server REST API with dynamic vector operational layer mashup with a pre-processed map cache base layer. Mobile clients will use the ArcGIS Server Mobile ADF (ArcGIS Mobile) workflows. The Standard ESRI Workflow performance targets are used for initial planning purposes (AGS93 REST 1-5 layer Dynamic Service for Web mapping and the AGS93 Mobile ADF Client and AGS93 Mobile ADF Service for ArcGIS Mobile). These workflows can be modified as required during system design and implementation as capacity planning performance targets are validated.

Batch processing: A batch process load profile will be included in the design to account for the administrative batch process workflows planned during peak processing periods. These may include online backups, replication services, reconcile-and-post services, and so forth. A platform utilization profile can be established to represent the batch processing model loads (this profile would depend on potential batch processing needs). It will be a system administration responsibility to make sure the number of concurrent batch processes are managed within these limits during peak processing loads.

The capacity planning framework introduced in the last chapter provides the flexibility to include a variety of desktop and server workflow models in a single system design assessment. Workflow models are defined in terms of software component service times. Component service time target performance loads are provided for ESRI standard COTS (off the shelf) software based on internal performance validation testing and customer feedback. These Standard ESRI Workflow models, which are used as the ESRI baseline for system architecture design consulting, have proven to help customers identify successful design solutions. New technology options introduced with each ArcGIS software release may require different workflow models, and these new models can be represented in the future by appropriate component service times identified for these workflows in the capacity planning tool. Careful selection of appropriate target service times is an important part of the system architecture design.

User workflow requirements
The user-needs template of figure 11-7, used here 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 (identified during the requirements definition—or user needs assessment—stage) establish processing and traffic requirements used by the capacity planning tool 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 Capacity Planning Tool 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 Desktop (Desk Edit and Desk View) and internal Web services (LocalMap) within central City Hall (Planning and Engineering departments) and three user locations over the WAN (Operations, Freeberg, and Willsberg). The IT department will host public Web services over their Internet connection. Again, each department manager is responsible for validating estimated peak workflow requirements. Workflow requirements are identified for each implementation phase. Figure 11-8 identifies the City of Rome year 2 workflow requirements.



Year 2 includes Business Development department deployment of a new Business Analyst information systems, and 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, and 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 Server mobile clients (Patrol cars). The police department adds a Police Dispatch and implements a Tracking Server solution with the 20 Police Patrols.

Figure 11-9 provides a summary report of year 1 and year 2 workflow requirements.



Now that you’ve got it all down on the template, your overall task is to figure out what infrastructure you’ll need to support all these new workflows. In other words, to design the system you must do a GIS workflow requirements analysis. Performing a proper one is hard work. The 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; once identified, this number will affect decisions on staffing and software licensing, as well as the hardware and infrastructure cost to support these workflows. Understanding and getting this right will make a big difference in user productivity and the success of the system.



Project Workflow Performance Targets
The first step in the system design process is to generate appropriate project workflow specifications for use in the City of Rome system architecture design. Figure 11-10 provides a list of the City of Rome workflows gathered from the user needs analysis.



Workflow performance targets (selected software component service times) are unique based on the software technology selection and the associated software deployment performance parameters. The system architecture design process is supported by the capacity planning tool. The planning workflow requirements identified earlier in figure 11-9 are used for the workflow analysis.

For some organizations, the capacity planning tool may be used to collect workflow requirements and complete the analysis without using separate workflow requirements templates. Organizations should use the methodology appropriate to their design needs. The templates pictured earlier, with planning workflow requirements listed on a spreadsheet, provide the most complete user needs representation and establish appropriate documentation for the simpler workflow representations displayed in the CPT.



Software Technology Selection
Figure 11-11 provides an overview of the CPT Calculator tool that can be used to identify the software performance specifications and complete a preliminary system architecture design performance assessment for final software technology selection.

The workflow performance parameters used to make the final software technology selection should be carried forward as specifications for software application design and deployment. The technology selection includes decisions on the software deployment pattern, map document optimization, output format, display resolution and density, and display complexity specifications, and data structure (dynamic or cached data source). The CPT Calculator nomenclature provides a simple workflow design recipe used to generate the workflow performance targets used to complete the system architecture design.



City of Rome Project Workflows
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. The CPT Workflow tab includes several of the more common Standard ESRI Workflows for use in most preliminary system architecture design solutions. Workflows performance targets identified on the CPT Workflow tab will be used to complete the final system architecture design.

Figure 11-12 shows the custom workflows established for the City of Rome system design. You can use a large number of separate workflows in CPT Design, yet keeping workflows to a reasonable number will clarify the presentation. The City of Rome example simplifies the analysis display by assuming all ArcGIS Desktop workflows are similar and can be represented by common productivity (divided into three categories - Editors, Viewers, and Business Analysts).



A composite workflow analysis tool is included on the CPT Workflow tab that can be used to combine multiple workflow components into a single composite workflow for use in the CPT Design. This can be useful if you have a user workflow that includes a combination of standard map displays mixed with occasional heavier workflow tasks. The composite workflow can be used in the primary design. If a more detailed review is needed, this can be completed on more detailed tabs with a summary provided for presentation.

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.

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 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. Figure 11-13 provides the final City of Rome workflows along with their nicknames and workflow description.

Hardware Platform Candidates
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 your homework to identify performance and capacity needs. You will also need to understand if the virtual server environments will be used, and review how this will impact your software licensing requirements. Review the [Platform Performance] chapter to identify what platform candidates will best support your procurement needs.

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. Figure 11-14 provides an overview of the CPT Hardware tab.

There is a section on the Hardware tab to identify Favorite Platform Candidates. Grouping your hardware candidates in this area will make platform selection much easier when using the CPT Calculator and Design tools. The most popular platform candidates are already listed on the Hardware tab, and you can move copies of the required platforms to your Favorite Candidate area.

If you do not find your favorite platform already on the CPT Hardware tab, you can go to the SPEC Web site and find the vendor published benchmark results and add the platform to the list. Instructions on how to add platforms to the Hardware tab are provided in the [Platform Performance CPT Video].



City of Rome Favorites (Workflows and Platforms)
Figure 11-15 shows a CPT Favorites tab that 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.



Year 1 Capacity Planning
Figure 11-16 provides an overview of City of Rome year 1 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 Desktop users, ArcGIS Server to support the public Web services, and a central GIS data server to support the enterprise geodatabase. 

Workflow Requirements Analysis
Once the custom workflows are defined, we are ready to complete the Phase 1 workflow requirements analysis. Figure 11.14 shows a CPT representation of the year 1 workflow requirements analysis for City of Rome.

The CPT workflow requirements analysis includes all of the Year 1 workflows identified during the business needs analysis (Figures 11-9 and 11-10). Common workflows can be consolidated at each site location to simplify the display. The CPT workflows must track back to represent the individual Planning Workflow Requirements.

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), the CPT will be completing the network suitability analysis. Before we complete the requirements analysis, we should spend some time establishing our initial platform configuration and completing our software installation. 

Platform Configuration Strategy and Software Installation
The CPT Design tab includes several options for configuring your server platforms. The system can be configured with up to 10 separate platform tier, you can change the tier name and include a nickname, you can identify whether it is a physical or virtual server deployment, and you can identify when you want to add additional platform nodes (utilization rollover percentage). Figure 11-18 shows the platform configuration strategy (WTS tier, two Web tier, and one DBMS tier), platform tier naming assignment (WTS, WebInternal, WebPublic, DBMS), minimum platform rollover setting (80 percent), and operating system environment (Windows physical servers) selected for the City of Rome design.



City of Rome hardware pricing list
Platform pricing will be used later in reviewing our system design configuration options. For City of Rome, we used a hardware pricing list we received from the IT procurement group for our analysis. The hardware pricing list is provided in figure 11-19.

Hardware candidates include high performance server configurations used for physical server deployments, and high capacity server configurations for hosting virtual server deployments. Server pricing would vary based on number of processors (chips) and memory. Virtual server pricing was a per chip charge based on the number of core per chip. 

City of Rome Software Install
Software can be installed on any platform tier, and the selected platform tier must be identified in the software configuration module in design columns J through Q. For City of Rome, the WTS software will be hosted on the WTS platform tier, the Web and SOC software for the internal Web mapping services will be installed on the WebInternal platform tier, The Web and SOC software for the public internet Web services will be installed on the WebPublic tier, SDE will use the default SDE direct connect installation, and the DBMS software will be installed on the DBMS platform. The workflow data source is identified in column R. Figure 11-20 shows the workflow software installation.



Year 1 network bandwidth suitability
We configured the data center and remote site networks and identified the user workflows during the workflow requirements analysis in Figure 11-17. You should already have the peak users and web services identified in the CPT Design User Requirements module.

The next step is to review and select our network bandwidth settings. A review of Figure 11-16 will identify the existing data center and remote site bandwidth connections. You will select the appropriate bandwidth for each network in column H (GREY rows are for the data center, and GREEN rows are for the remote site connections. Figure 11-21 shows an overview of the network bandwidth selections.

 Once the network connections are defined and the summary ranges validated, the capacity planning tool will identify potential traffic bottlenecks. Workflow network traffic is computed from total workflow requirements (DPM x Mbpd / 60 sec.). Network traffic cells show RED when there is insufficient bandwidth to support the identified traffic.

The RED cells identify that we have a performance problem. A closer look at network traffic and the available bandwidth shows we do not have sufficient network capacity to support the identified workflow traffic.

In figure 11-22, the network traffic summary cells turn YELLOW when traffic is more than 50 percent of existing network bandwidth, and turns RED when traffic exceeds existing network bandwidth. The user productivity cells turn RED when calculated workflow think time is less than required minimum user think time. We will need to upgrade the network bandwidth connections or reduce user productivity to fit within the existing design constraints.

This is now a good time to meet with the Network Administrator and discuss plans for upgrading the WAN and Internet bandwidth connections. He may already have network infrastructure upgrade plans - most network administrators these days do. System design planning should include discussions with the Network Administrator to make sure budgets are in place to accommodate required network upgrades.

Networks do not have to be upgraded until traffic problems are confirmed, but you need to make sure the budgets are in place and arrangements made with the network service providers so the network bandwidth can be upgraded when needed. Network bandwidth should be at least twice the projected traffic to avoid workflow performance problems, and should include all other traffic that might be sharing these connections. 

Year 1 recommended network bandwidth upgrades
After identifying the network performance bottlenecks, the Capacity Planning Tool can be adjusted to resolve the performance problems. The standard recommendation is to configure network bandwidth to at least double the projected peak traffic requirements.

Remember, we only show the GIS traffic in this analysis; the WAN and Internet connections are shared by other users throughout the organization and their needs should also be represented in the analysis. It is possible to include an additional workflow representing other projected network traffic – there is a template for inserting a row for background traffic just below the requirements module (row 25 in figure 11-22).

City of Rome decided to upgrade the Data Center WAN and Internet connections to 24 Mbps, the Freeberg and Willsberg sites to 12 Mbps, and the Operations site to 3 Mbps. Figure 11-23 shows the Workflow Performance Summary following the recommended network bandwidth upgrades. The Public WebMap workflow display response time is now less than 0.4 seconds.



Appropriate network bandwidth upgrades can be represented in the CPT, and the network traffic cell colors and Workflow Performance Summary will respond with the proper adjustments. This is a discussion you should have with the network administrator; s/he can identify other traffic requirements which can easily be included in the analysis and confirm what network upgrades are possible.

Once the capacity planning tool is properly configured, you can compare the peak network bandwidth (provided by the workflow analysis tool) with existing bandwidth connections (represented on the earlier network diagram). Then you can identify the required upgrades, if any, and recommend them in your system design.

The City of Rome year 1 implementation encompasses users at four locations. City Hall includes network connections to enable WAN communications with the remote offices and an intranet connection over which the published public Web mapping services can be transported. Each remote office includes a gateway connection to the city WAN. Traffic requirements for each network connection are represented in the workflow analysis network traffic (column F).



Year 1 System Architecture Design Solution
After your have input the year 1 peak user workflow requirements in the CPT User Requirements Module and completed the software platform configuration, the CPT Platform Configuration Module can be used to make the final platform selection and complete the system configuration recommendations. The CPT incorporates the performance models (chapter 9) and the vendor platform performance benchmarks (chapter 7) discussed earlier. The CPT uses the established peak user workflow requirements, along with vendor-relative performance benchmarks, to generate the number of platform nodes required to handle the peak workflow loads. (The system architect can select from a variety of vendor platforms for the final configuration.)

Three design strategies were considered for City of Rome year 1 deployment (minimum physical hardware configuration, high available physical hardware configuration, and virtual server configuration).

Minimum physical server configuration year 1
The minimum physical server system design configuration in figure 11-24 is supported by Xeon X5687 4 core (2 chip) 3600 MHz hardware platforms (as of mid-2010, our favorite application server platform).



Design solution includes the following hardware:
 * WTS tier: 1x Xeon X5687 4 core (1 chip) 3600 MHz platform with 37 GB memory
 * WebInternal tier: 1x Xeon X5687 4 core (1 chip) 3600 MHz platform with 12 GB memory
 * WebPublic tier: 1x Xeon X5687 4 core (1 chip) 3600 MHz platform with 12 GB memory
 * DBMS tier: 1x Xeon X5687 4 core (1 chip) 3600 MHz platform with 12 GB memory

Server pricing was calculated based on price list in Figure 11-19. Total server cost for the minimum production configuration is estimated at $35,264. Development, test, and staging servers are not included in this price (assume older replaced production servers are available for these environments).

This hardware selection provides the lowest cost hardware solution. This solution does not protect against single hardware failure – if one of the platforms stop working, users will not be able to continue their work until the server is back online. This is not acceptable for most operations production environment (business cost for work downtime exceeds cost for high available server configuration).

<br style="clear: both" />

High available physical server configuration year 1
The high available physical hardware system design configuration in figure 11-25 is supported by Xeon X5687 4 core (2 chip) 3600 MHz hardware platforms. The Windows Terminal Server (WTS) farm includes one extra platform node (N+1) to ensure peak performance needs are met with one server failure. Both Web server tier (WebInternal and WebPublic) include a minimum of two platform nodes – when one server fails, Web services are supported at reduced capacity with the remaining platform node. An additional failover database server is included for the DBMS tier, which will take control of database services in the event of primary database server failure.



Design solution includes the following hardware:
 * WTS tier: 2x Xeon X5687 4 core (1 chip) 3600 MHz platform with 37 GB memory
 * WebInternal tier: 2x Xeon X5687 4 core (1 chip) 3600 MHz platform with 12 GB memory
 * WebPublic tier: 2x Xeon X5687 4 core (1 chip) 3600 MHz platform with 12 GB memory
 * DBMS tier: 2x Xeon X5687 4 core (1 chip) 3600 MHz platform with 12 GB memory

Server pricing was calculated based on price list in Figure 11-19. Total server cost for minimum production configuration is estimated at $70,528. Development, test, and staging servers are not included in this price (assume older replaced production servers are available for these environments).

This hardware selection provides the highest performance solution with the available hardware. This also comes at the highest price. System is configured so no single hardware failure will cause a production work shutdown.

The following design will look at an alternative virtual server configuration.

<br style="clear: both" />

High available virtual server configuration year 1
The high available virtual server system design configuration in figure 11-26 is hosted by Xeon X5690 12 core (2 chip) 3466 MHz physical hardware platforms (virtual servers will be deployed on the physical servers). The higher capacity server will be able to host more virtual servers at a lower overall platform cost – at the same time the higher capacity processors reach peak thermal and power limits at a lower performance level (relative platform throughput per core performance values are provided for each physical hardware configuration in Figure 11-19). Dual core virtual servers were used where possible to achieve optimum performance and scalability on the host platform environments.



Virtual server hardware requirements:
 * Hardware: 2x Xeon X5690 12 core (2 chip) 3466 MHz with 64 GB memory
 * WTS tier: 3x 2 core virtual servers with 15 GB memory
 * WebInternal tier: 2x 2 core virtual servers with 6 GB memory
 * WebPublic tier: 2x 2 core virtual servers with 6 GB memory
 * DBMS tier: 2x 2 core virtual servers with 15 GB memory

<br style="clear: both" /> Figure 11-27 shows the proposed virtual server platform configuration layout. Both host hardware platforms will be active during normal production operations. The primary hardware platform will host the primary virtual server environments (peak production loads can be supported by virtual servers located on the primary physical server platform). The backup hardware platform will host failover virtual servers, and will have the capacity to also host the development, test, and staging virtual server environments during normal operations. If the primary hardware server fails, the backup hardware server will drop all active processes and restart the virtual server environment hosted by the primary hardware server (failover operation).

Server pricing was calculated based on price list in Figure 11-19. Total server cost for the virtual server production configuration is estimated at $28,454. The VMWare virtual server software pricing (Figure 11-19) was used this analysis, and pricing analysis does not include additional cost for system management software. This solution shows a $42,000 hardware savings over the high available physical server deployment.

There are several administrative advantages available with virtual server deployments which have the potential of reducing overall operational cost and improving system adaptability. These cost advantages are recognized, but are not be included in this analysis. Virtual server deployments are becoming standard for many organizations due to operational advantages as well as the server consolidation savings we show in this analysis.

<br style="clear: both" />

Year 2 capacity planning
A similar analysis can be completed for the year 2 City of Rome implementation. Most GIS deployments evolve over several years of incremental technology improvements, and implementation plans typically address a two- or three-year schedule to ensure that the budget is in place for the anticipated deployment needs. Figure 11-28 identifies user locations for the year 2 implementation.

Several additional Internet remote sites will be included in year 2, along with deployment of the 911 dispatch and the initial police network. The police network will be supported by a separate server environment (ArcSDE DBMS server for the geodatabase and an ArcGIS Server for the Mobile ADF Police Patrol application. Geodatabase replication will be used for data updates to the Police geodatabase). City network operations will continue to be administered from the IT Data Center.

Provisions should be made to review and update design plans before each deployment phase. Technology is changing rapidly each year, and more efficient and effective opportunities may exist for year 2 that were not available during the initial planning process. The best enterprise design strategy is to update plans on an annual basis, extending plans to include adjustments for changing operational requirements and future business operations. Accommodating technology change can reduce deployment cost and accommodate appropriate system adjustments making best use of available technology. <br style="clear: both" />

Year 2 workflow analysis
See figure 11-29 for results of the year 2 city network workflow requirements analysis, as they appear in the CPT. You will need to transfer the Year 2 workflow requirements identified in the user needs assessment (figure 11-9) to the workflow analysis module in the configuration tool. Two separate CPT tabs must be completed, one for the city network and a separate CPT tab for the police network. The Year 2 worksheet for the city network was updated in the capacity planning tool by copying the year 1 worksheet to a separate tab and inserting the additional locations and user workflows, to complete the user requirements. Year 1 network bandwidth upgrades were included as a starting point for the year 2 analysis.

The year 2 implementation includes five additional remote sites with access over the Data Center Internet network. The new remote site network bandwidth connections represented on the network diagram (figure 11-28) are identified on the CPT workflow requirements analysis display. The new remote site bandwidth connections identified from figure 11-29 are as follows:

New Remote Site Network Connections


 * Perth: 1.5 Mbps (Cell H20)
 * Wawash: 1.5 Mbps (Cell H22)
 * Jackson: 1.5 Mbps (Cell H24)
 * Petersville: 1.5 Mbps (Cell H26)
 * Rogerton: 1.5 Mbps (Cell H28)

Internet Web browser PSAP and emergency vehicles were included with the public Web services.

The site level network traffic totals should be checked to make sure the SUM ranges are updated (remote site ranges should include upper and lower network line bounding the site workflows, and the central data center ranges should include the total range of each gray network (LAN,WAN, Internet). Validating that these ranges are correct will ensure the proper calculations are supported by the Capacity Planning Tool.

<br style="clear: both" />

Year 2 network suitability
With the network connections defined and the summary ranges validated, the capacity planning tool identifies potential traffic bottlenecks. The bottlenecks show up as colored network traffic summary cells. The City Network Workflow Requirements Analysis (figure 11-29) shows nine site connections over 50 percent capacity. Recommended network upgrades are at least twice the peak traffic.



The Data Center network bandwidth upgrades include the following:

Data Center connections Remote site connections
 * LAN (1000 Mbps)
 * WAN (24 Mbps)
 * Internet (90 Mbps)
 * Operations (24 Mbps)
 * Wawash (12 Mbps)
 * Jackson (6 Mbps)
 * Petersville (18 Mbps)
 * Rogerton (18 Mbps)

Cost for these upgrades must be included in the network administrator's infrastructure design budget.

City of Rome decided to upgrade network connections based on the design recommendations. Figure 11-30 provides an overview of the City Network Year 2 Workflow Performance Summary once the recommended network upgrades are included in the CPT design.

Appropriate network bandwidth upgrades can be entered in the Capacity Planning Tool, and the network traffic cell colors and Workflow Performance Summary will respond with the proper adjustments. Other traffic requirements can easily be included in the analysis, so have a discussion with the network administrator to see what he would like to see and confirm that your recommended network upgrades will be supported. <br style="clear: both" />

Year 2 City Hall System Architecture Design Solution
The capacity planning tool is now ready to identify the year 2 platform solution. The initial solution is deployed on the virtual server platform tier identified in year 1. An alternative solution will host the public web services (WebPublic) on an ArcGIS Server Amazon Machine Instance (AMI) in the Amazon EC2 Cloud.

High available virtual server data center configuration year 2
The high available virtual server system design configuration in figure 11-31 is hosted on the same hardware platforms supporting the virtual servers in year 1. Additional server platforms are included to host the peak year 2 workflow loads.



Virtual server hardware requirements: <br style="clear: both" />
 * Hardware: 5x Xeon X5690 12 core (2 chip) 3466 MHz with 128 GB memory
 * WTS tier: 12x 2 core virtual servers with 15 GB memory
 * WebInternal tier: 2x 2 core virtual servers with 6 GB memory
 * WebPublic tier: 4x 2 core virtual servers with 6 GB memory
 * DBMS tier: 2x 6 core virtual servers with 46 GB memory

Figure 11-32 shows the proposed virtual server platform configuration layout. All five host hardware platforms will be active during normal production operations. The primary hardware platforms will host the primary virtual server environments (peak production loads can be supported by virtual servers located on the primary physical server platform). The backup server platform will have capacity to host the development, test, and staging virtual server environments during normal operations. If any of the primary hardware servers fails, the backup hardware server will drop all active processes and restart the virtual server environment hosted by the primary hardware server (failover operation).

Server pricing was calculated based on price list in Figure 11-19. Total server cost for the virtual server production configuration is estimated at $81,000. The VMWare virtual server software pricing (Figure 11-19) was used this analysis, and pricing analysis does not include additional cost for system management software.

Four virtual servers are required to host the Public web services. The data center platform environment can be reduced if these public web services were hosted on ArcGIS AMIs located in the Amazon EC2 Cloud data centers. This alternate solution strategy will be reviewed in the next two sections. <br style="clear: both" />

High available virtual server internal services configuration year 2
The high available virtual server internal services configuration in figure 11-31 removes the public web services (they will be hosted on the Amazon cloud in the next section). This removes the requirement to host the four WebPublic virtual servers and the database load can be supported on a 4 core virtual server. This solution requires one less virtual server host hardware platform.



Reduced data center virtual server hardware requirements: <br style="clear: both" />
 * Hardware: 4x Xeon X5690 12 core (2 chip) 3466 MHz with 128 GB memory
 * WTS tier: 12x 2 core virtual servers with 15 GB memory
 * WebInternal tier: 2x 2 core virtual servers with 6 GB memory
 * DBMS tier: 2x 6 core virtual servers with 46 GB memory

Figure 11-34 shows the reduced virtual server platform configuration layout. All four host hardware platforms will be active during normal production operations. The primary hardware platforms will host the primary virtual server environments (peak production loads can be supported by virtual servers located on the primary physical server platform). The backup server platform will have capacity to host the development, test, and staging virtual server environments during normal operations. If any of the primary hardware servers fails, the backup hardware server will drop all active processes and restart the virtual server environment hosted by the primary hardware server (failover operation).

Server pricing was calculated based on price list in Figure 11-19. Total server cost for the virtual server production configuration is estimated at $65,000. The VMWare virtual server software pricing (Figure 11-19) was used this analysis, and pricing analysis does not include additional cost for system management software.

City of Rome Public web services will be deployed on the ArcGIS Server AMI instances in the Amazon EC2 data center. Data will be maintained within the City of Rome data center geodatabase. Geodatabase one way replication can be used to update a file geodatabase instance in the Amazon EC2 data center, then a snapshot can be moved to each ArcGIS Server AMI. <br style="clear: both" />

Amazon ArcGIS Server EC2 deployment year 2
Amazon provides an Infrastructure as a Service (IaaS) cloud offering for hosting ArcGIS Server web services. City of Rome can leverage this service for deploying their year 2 public web services. Web service loads are projected to reach 100,000 service transactions per hour during peak operational periods. These peak periods would happen periodically, and normal service loads should average less than 50,000 transactions per hour for more than 75 percent of the time.

Amazon Web Service (AWS) Offerings
Figure 11-35 provides an overview of primary AWS service offerings and associated pricing used in this study. Amazon publishes updated pricing for their EC2 cloud services on the Web. Prices and services can change, so it is important to spend some time understanding the Amazon hosting configuration and associated pricing before moving critical services to this environment.

Amazon provides information on EC2 available instance types along with background information on performance represented by their published EC2 compute units. This performance information can be used for sizing purposes. The CPT Hardware Tab includes performance specifications for the Amazon Machine Instances provided in Figure 11-35. <br style="clear: both" />

The CPT Calculator tab was used to generate an Amazon EC2 server configuration for the City of Rome public web services. The CPT Calculator is a very simple system architecture design configuration tool for sizing use when you have a single workflow. Figure 11-36 shows the results of the Calculator design analysis.

The Amazon AMI high memory extra large instance provides the highest performance dual core server option, so this AMI will be used to complete our design. This instance provides a 2-core virtual server with 17.1 GB of memory (we recommend at least 6 GB memory for a 2-core server). Performance is reported at 3.25 EC2 Compute Units per server core.

The CPT Calculator uses the City of Rome WebPublic workflow (pulled from the Workflow tab) and the Amazon platforms (pulled from the Hardware tab) to generate the design solution. Virtual server 2-core per node configuration matches the Amazon AMI selection. Data source will be a local file geodatabase on each ArcGIS Server AMI. Solution shows that four servers will be required to handle peak loads of 100,000 transactions per hour. Amazon three year term dedicated reserve instances were used for this pricing analysis.

Figure 11-37 provides an overview of the Amazon pricing analysis. Pricing was computed over a three year period. Cost for the four ArcGIS Server AMI instances was about $33,229. Data_in costs were about $645 (Pricing included initial data upload using AWS Import/Export services, data_in loads for incremental updates, and Amazon S3 cloud backup storage). Data_out loads were about $7,780 (based on an average of about 300,000 transactions per day. Elastic load balancing costs were slightly above $1000 for the three year period.  Overall cost estimate was around $45,000 over the three years.

It does require some effort to understand and estimate what the AWS hosting costs will be. First you need to fully understand the hosted configuration. Then you need to understand the fixed and incremental costs associated with maintaining and deploying the published services. Finally, you will be responsible for managing the data and services associated with the site configuration.

One big advantage with cloud hosting is that you only pay for what you use. Server pricing includes both fixed and variable costs, and you save money if you shut down servers when not in use. If you need additional server capacity, you can add more servers within a very short amount of time (within 10 minutes). You need to spend some time to develop a strategy that best satisfies your business needs, and then try something small (at a level you can manage) to get experience you can use for future deployments. We believe the cloud is the platform for the future – and an entry level of experience now can prepare you for future opportunities.

Police network year 2 platform solution
Figure 11-38 provides the results of the year 2 Police network workflow requirements analysis. The workflow requirements identified in the user needs assessment (figure 11-9) were transferred to the configuration tool workflow analysis module. You will need to complete the Year 2 Police Network user requirements on a new CPT spreadsheet, configured as inputs to the Police network workflow requirements analysis.

The Police requirements are relatively simple, with three workflows on the LAN and ArcGIS Mobile clients located in remote police patrol cars. The remote patrol cars communicate through a wireless connection to the Police data center. Police data center has a T-1 (1.5 Mbps) WAN connection. Police mobile client applications are updated every 20 seconds (3 displays per minute productivity). <br style="clear: both" />

Figure 11-39 shows the Police hardware configuration and software install. The Police department uses a virtual server configuration. Virtual servers tier are identified for the BatchAdmin process (Batch), ArcGIS Server Mobile synchronization service (WebMap), and the geodatabase (DBMS). Software will be installed on their associated virtual servers.

<br style="clear: both" /> The police network platform final design is shown in figure 11-40. Single processor (chip) server is selected as the host virtual server hardware platform.



In reviewing the final design analysis, it was clear that the Xeon X5690 platform could support the peak workflow loads with a single six core chip. The selected police network server is the Xeon X5690 6 core platform satisfying peak processing loads with minimum platform utilization. Figure 11-40 shows the selected Police design solution.

Police virtual server hardware requirements:
 * Hardware: 2x Xeon X5690 6 core (1 chip) 3466 MHz with 24 GB memory
 * Batch tier: 1x 1 core virtual server with 3 GB memory
 * WebMap tier: 1x 2 core virtual server with 6 GB memory
 * DBMS tier: 1x 1 core virtual servers with 15 GB memory

A review of the Workflow Performance Summary suggests there are no identified performance bottlenecks. <br style="clear: both" />

Rome City Hall Deployment business case summary
Figure 11-41 provides an overview of the various City of Rome City Hall deployment strategies that we discussed in this chapter. There are advantages and tradeoffs with each solution, and selecting the right solution for your business needs is the objective of this case study. Once you have completed your design analysis, you can select the best solution based on overall cost and operational needs.

<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. The next and last chapter is about what to do with a system design once you have it: we will discuss the fundamentals of systems integration and some best practices that lead you to a successful implementation.

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

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