City of Rome – 27th Edition (Spring 2010)

From wiki.gis.com
Jump to: navigation, search
System Design Strategies
System Design Strategies 27th Edition (Spring 2010)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. GIS Data Administration
5. Performance Fundamentals 6. Network Communications 7. GIS Product Architecture 8. Information Security
9. Platform Performance 10. Capacity Planning Tool 11. City of Rome 12. System Implementation

City of Rome – 27th Edition (Spring 2010)

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 10 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 three planned years of expansion and growth.

GIS Business Needs Assessment

Figure 11-1 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 System Architecture Design
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 in 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.

Figure 11-3 System Design Strategic Deployment Plan

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 required 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, year 2, and year 3. 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.

Figure 11-4 Build on Existing IT Investments

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.

Figure 11-5 Workflow 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 required 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.

Figure 11-6 User Locations and Network Communications

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.

Figure 11-7 City of Rome User Needs - Year 1

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. Final negotiations on hardware selection should focus on these peak user workflow requirements. 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 Web services are published from the IT Data Center to the public Internet site (in this case study, departments did not access Web services from internal locations).   Again, each department manager is responsible for validating the final workflow requirements. Workflow requirements are identified for each implementation phase. Figure 11-8 identifies the City of Rome year 2 workflow requirements.

Figure 11-8 City of Rome User Needs - Year 2

Year 2 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 communication between the City Network and the Police Network. A new Mobile ADF application will support the Police Patrols, using background communications over dial-up connections to synchronize with the ArcGIS Server mobile application.   Year 2 City Network deployment adds 911 services within the Operations department along with a new dispatch operation and implementation of three additional field offices (Perth, Wawash, and Jackson).

Figure 11-9 identifies the City of Rome year 3 workflow requirements.

Figure 11-9 City of Rome User Needs - Year 3

Year 3 includes deployment of new Business Analyst and Joint Tracking (JTX) work order management applications. A Tracking Server implementation is deployed to facilitate snowplow scheduling. Two new remote field offices are added to the system. The police department adds a Police Dispatch and implements Tracking Server solution with the 20 Police Patrols.

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 user 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. 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-5 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 inserted as 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-10 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.

Figure 11-10 Software Technology Selection - Performance Assessment

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-11 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).

Figure 11-11 City of Rome Workflow Performance Targets

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.

City of Rome Favorites (Workflows and Platforms)

Figure 11-12 City of Rome Workflow and Platform Favorites
Figure 11-12 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-13 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.

Figure 11-13 User Locations and Network Communications - Year 1

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.

Figure 11-14 Workflow Requirements Analysis - Year 1

The CPT workflow requirements analysis includes all of the workflows identified during business needs analysis (Figure 11-7). 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 is completing the performance analysis. 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 required traffic.

System design planning should include discussions with the Network Administrator to make sure budgets are in place to accommodate required network upgrades. Network bandwidth should be at least twice the traffic to avoid workflow performance problems.

Platform Configuration Strategy and Software Installation

Several upgrades were made to the Capacity Planning Tool since August 2008. 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-15 shows the platform configuration strategy (3 tier architecture), platform tier naming assignment (WTS, WebMap, DBMS), minimum platform rollover setting (80 percent), and operating system environment (Windows physical servers) selected for the City of Rome design.

Figure 11-15 Platform Tier Configuration

Software can be installed on any platform tier, and the selected platform tier must be identified in the software configuration module in design columns I through Q. For City of Rome, the WTS software will be hosted on the WTS platform tier, the Web and SOC software will be installed on the WebMap platform tier, SDE will use the default SDE direct connect installation, and the DBMS software will be installed on the DBMS platform. Oracle will be the DBMS software, using the ST_Geometry data type for the geodatabase. Figure 11-16 shows the workflow software installation.

Figure 11-16 Workflow Software Installation

Year 1 network bandwidth suitability

Once the network connections are defined and the summary ranges validated, the capacity planning tool will identify potential traffic bottlenecks. The bottlenecks show up as colored network traffic summary cells and as network queue time on the Workflow Performance Summary. Once you identify the platform configuration strategy and identify host platform technology, the CPT can provide a workflow performance summary. Figure 11-17 shows the performance problems identified by the CPT Design if recommended network bandwidth adjustments are made.

Figure 11-17 Network Bandwidth Suitability - Year 1

In figure 11-14, the network traffic summary cells turn YELLOW when traffic is more than 50 percent of existing network bandwidth, and turn RED when traffic exceeds existing network bandwidth. In Figure 11-17, after adjusting user productivity to fit within existing network bandwidth limitations, network queue times (NWQ) are identified on the Workflow Performance Summary above the network service time for each workflow.

For year 1, both the WAN and Internet traffic are well above the current bandwidth capacity. The Workflow Performance Summary shows the expected display response time due to network contention – the Internet application display response time (WebMap) is over 300 seconds (the productivity will not adjust for a known throughput requirement - network queue time defaults to 500 times the network transport time to indicate an invalid solution. The Workflow Performance Summary clearly shows what could happen if the network bandwidth issue were not addressed during the design process.

Year 1 network performance tuning

After identifying the network performance bottlenecks, the Capacity Planning Tool can be adjusted to resolve the particular 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 – this would certainly be advisable when performance is important, which it usually is.

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

Figure 11-18 Network Performance Tuning - Year 1

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 router connection to the city WAN. Traffic requirements for each network connection are represented in the workflow analysis network traffic (column H).

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 5) and the vendor platform performance benchmarks (chapter 9) 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.)

The system design configuration in figure 11-19 is supported by Xeon X5570 8 core (2 chip) 2933 MHz hardware platforms (as of mid-2009, our favorite application server platform).

Figure 11-19 System Architecture Design - Year 1

Peak capacity workflows projected for the year 1 deployment can be supported with one Windows Terminal Server; one Web mapping server (hosting the Web and ArcGIS Server software); and one database server. All hardware platforms are supported with the Xeon X5570 8 core (2 chip) 2933 MHz platforms configured with minimum of 56 GB physical memory (RAM) for the Windows Terminal Server and Database Tier and 16 GB RAM for the Web mapping. Projected CPU utilization rates are shown for each tier of the recommended platform solution server (less than 10 percent utilization for the Web mapping and Database platforms - these platforms could be hosted on two virtual servers supported by one of the physical machines).

Year 2 capacity planning

Figure 11-20 User Locations and Network Communications - Year 2
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 normally address a two- or three-year schedule, to ensure that the budget is in place for the anticipated deployment needs. Figure 11-20 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.


Year 2 workflow analysis

See figure 11-21 for results of the year 2 city network workflow requirements analysis, as they appear in the CPT. You will need to transfer the workflow requirements identified in the user needs assessment (figure 11-8) 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.

Figure 11-21 Workflow Requirements Analysis - Year 2

The year 2 implementation includes three 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-20) are identified on the CPT workflow requirements analysis display. The new remote site bandwidth connections identified from figure 11-20 are as follows:

New Remote Site Network Connections

Perth: 1.5 Mbps (Cell H19) Wawash: 1.5 Mbps (Cell H21) Jackson: 1.5 Mbps (Cell H23)

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.


Year 2 network suitability

With the network connections defined and the summary ranges validated, the capacity planning tool will identify potential traffic bottlenecks. The bottlenecks show up both as colored network traffic summary cells. The City Network Workflow Requirement Analysis (figure 11-21) shows seven site connections over 50 percent capacity. Recommended network upgrades should be at least twice the peak traffic. The Data Center network bandwidth upgrades include the LAN connection to 1000 Mbps and the WAN and Internet connections to 45 Mbps. Remote site upgrades include Ops, Willsberg, and Wawash connections to12 Mbps and the Jackson connection to 6 Mbps. Cost for these upgrades must be included in the network administrator's infrastructure design budget.

Figure 11-22 Network Bandwidth Suitability Upgrades - Year 2
City of Rome decided to upgrade network connections based on the design recommendations. Figure 11-22 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 they are and confirm that your recommended network upgrades can be supported.  


Year 2 System Architecture Design Solution

The capacity planning tool is now ready to identify the year 2 platform solution. The CPT display (figure 11-23) shows the minimum recommended platform solution for the year 2 city network workflows when using the Xeon X5570 8 core (2 chip) 2933 MHz platforms. Platform configuration requirements are provided by the capacity planning tool after the user requirements and platform selections are complete. Figure 11-23 also provides an overview of the workflow peak loads and the Workflow Performance Summary.

Figure 11-23 System Architecture Design Solution - Year 2

The Phase 2 City network workflow requirements can be supported with two (2) Windows Terminal Servers, one (1) Web mapping server, and one (1) Database Server with the selected platform configurations.

The Workflow Performance Summary can be used to review user response times for the selected configuration. Process queue times located above each hardware component represent platform processing wait times (queue-time models are discussed in chapter 7). User performance will decrease as platform capacity increases due to process instructions waiting for access to processor core for execution.

Police network year 2 platform solution

Figure 11-24 provides the results of the year 2 Police network workflow requirements analysis. The workflow requirements identified in the user needs assessment (figure 11-8) 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.

Figure 11-24 Police Workflow Requirements Analysis - Year 2

The year 2 Police implementation includes local network clients and remote mobile police patrol cars. Each police patrol communications unit is supported over wireless service routing mobile communications through the data center WAN service connection.

Figure 11-25 shows the Police hardware configuration and software install. The Web, ArcGIS Server, and DBMS software are installed on a single workgroup server.

Figure 11-25 Police Workflow Software Configuration - Year 2

The Police Workgroup server is a Xeon X5570 with a Windows operating system. Software is installed in a Physical platform environment.

Figure 11-26 Police Hardware Platform Requirements - Year 2

The police network platform final design is shown in figure 11-25, which includes the Police user workflows and design solution at the top and the Workflow Performance Summary at the bottom (you can drag the graphs located in the CPT to locations that are convenient for display purposes).

The peak numbers of ArcGIS Desktop users were identified as 11 in City of Rome year 2. The ESRI workgroup server license can support up to 10 concurrent ArcGIS Desktop connections and could be used to support the police network needs, if the peak workflow requirements could be reduced by one desktop user. This should be discussed during the design evaluation as a potential cost reduction—it is important that these peak loads were not overestimated.

In reviewing the final design analysis, it was clear that the Xeon X5570 platform could support the peak workflow loads with a single quad core chip. The selected police network workgroup server is the Xeon X5260 4 core (1 chip) 2933 MHz platform satisfying peak processing loads at less than 10 percent utilization. Figure 11-26 shows the selected Police design solution.

A review of the Workflow Performance Summary suggests there are no identified performance bottlenecks.

Year 3 capacity planning

Year 3 includes deployment of two new regional office sites, increase in the number of City Hall departments and workflows using GIS technology, and introduction of tracking analysis to monitor mobile vehicle operations, including up to 100 snowplows during winter storm operations. Here are the user locations for year 3 (figure 11-27).

Figure 11-27 User Locations and Network Communications - Year 3

Year 3 workflow analysis

Figure 11-28provides the results of the year 3 workflow analysis. The workflow requirements identified in the user needs assessment (figure 11-9) were transferred to the configuration tool workflow requirements module. The workflow templates for the city network and the police network were generated from the capacity planning workbook in Excel, to complete the site configurations: by copying the year 2 worksheets to separate tabs and inserting the additional remote site locations and workflow upgrades.

Figure 11-28Workflow Requirements Analysis - Year 3

Year 3 includes adding a new Business Analyst workflow to the City LAN, and adding two new remote sites (Petersville and Rogerton) to the Data Center Internet connections. The remote site network bandwidth connections are shown on the far right of the CPT display (column H):

New Remote Site Network Connections Site 8 – Petersville: 1.5 Mbps (Cell H26) Site 9 – Rogerton: 1.5 Mbps (Cell H28)

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

Year 3 network suitability

Once the network connections are defined and the summary ranges are validated, the CPT will identify potential traffic bottlenecks. The bottlenecks show up both as colored network traffic summary cells and as network queue time on the Workflow Performance Summary. The CPT (figure 11-28) shows network traffic over 50 percent bandwidth capacity for Ops, Willsberg, Wawash, Jackson and for the City WAN and Internet connections. Petersville and Rogerton show traffic over 100 percent capacity.

The City of Rome decides to plan for upgrading the City Internet connection to 90 Mbps, and connections for Ops, Petersville, and Rogerton to 24 Mbps. The remaining sites were only slightly over 50 percent utilization and display performance should remain acceptable during these peak loads. Figure 11-29 provides an overview of the upgraded City Network Year 3 design including the Workflow Performance Summary.

Figure 11-29 Network Bandwidth Upgrade - Year 3

Appropriate network bandwidth upgrades can be represented in the Capacity Planning Tool, and the Workflow Performance Summary will respond with the proper adjustments. Most display response times are less than 1 second, with the remote ArcGIS Desktop viewers at Perth slowing to almost 1.4 sec per display (Perth has the lowest bandwidth at 1.5 Mbps). This analysis considers only the GIS traffic, so there will come a time to conduct the discussion with the network administrator about including the other traffic requirements. They can be estimated using a custom workflow representing existing traffic loads, and thereby easily included in the analysis.

Year 3 System Architecture Design Solution

The capacity planning tool is now ready to validate the final year 3 platform configuration. The CPT interface below (figure 11-30) shows the minimum recommended platform solution for the year 3 city network workflows when using the Xeon X5570 8 core (2 chip) 2933 MHz platforms. Platform configuration requirements are provided by Excel once the user requirements and platform selections are complete.

Figure 11-30 System Architecture Design Solution - Year 3

The Workflow Performance Summary shows the user workflow display response times for the selected configuration. Process queue times are represented above each hardware component to identify platform processing wait times (queue time models are discussed in chapter 7). For this solution, Windows Terminal Server platforms are at 63 percent capacity (Cell A35) and, slightly above 50 percent utilization.


Final platform selection includes three (3) Xeon X5570 8 core (2 chip) 2933 MHz platforms for the WTS tier, one (1) Xeon X5570 8 core (2 chip) 2933 MHz platform for the Web mapping tier, and one (1) Xeon X5570 8 core (2 chip) 2933 MHz platform for the DBMS tier. Additional platforms can be provided to support high availability requirements. Memory recommendations include 56 MB RAM for the WTS and DBMS servers and 16 GB RAM for the Web mapping server. Display performance for all workflows is well under 2 seconds.

Police network year 3 platform solution

The police network year 3 design is provided in Figure 11-31. Capacity requirements continue to be satisfied with a single-socket server configuration. Peak desktop user connections have increased to a total of 24 ArcGIS Desktop users, which would require an enterprise ArcGIS Server license, although peak loads could continue to be supported by the SQL Express database.

Figure 11-31 Police Hardware Platform Requirements - Year 3

The Workflow Performance Summary shows excellent performance with the proposed system design solution.

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.


System Design Strategies
System Design Strategies 27th Edition (Spring 2010)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. GIS Data Administration
5. Performance Fundamentals 6. Network Communications 7. GIS Product Architecture 8. Information Security
9. Platform Performance 10. Capacity Planning Tool 11. City of Rome 12. System Implementation


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