City of Rome 29th Edition (Spring 2011)

Spring 2011 City of Rome 29th 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 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 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. 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.



Year 2 includes Business Development deployment of a new Business Analyst information systems, and Engineering 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 communication between the City Network and the Police Network. A new Mobile ADF application will support the Police Patrols, using wireless communications over a T-1 connection to synchronize with the ArcGIS Server mobile clients. The police department adds a Police Dispatch and implements 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-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.



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. Figure 11-19 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-6 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-20 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-21, 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.

 What if we do nothing? The CPT Design tab does have an ADJUST function (cell AP2) which will reduce user productivity to fit within the network bandwidth constraints. Figure 11-22 shows what we can expect if we do not upgrade the network bandwidth. Remote site user productivity slows to less than 2 displays a minute (Workflow Performance Summary shows over 30 second display refresh times for Citrix clients accessing over the existing bandwidth). The Internet bandwidth had to be increased to 6 Mbps to handle the public Web mapping traffic loads. Performance is clearly not acceptable, and it is best to find this out now in the planning phase and not later in production.

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 network performance tuning
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 – this would certainly be advisable when performance is important, which it usually is.

City of Rome decided to upgrade the Data Center WAN to 18 Mbps, the Data Center Internet and the Freeberg site to 12 Mbps, and the Willsberg site to 6 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.5 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 router 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 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-24 is supported by Xeon X5570 8 core (2 chip) 2933 MHz hardware platforms (as of mid-2009, our favorite application server platform).



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 X5677 8 core (2 chip) 3467 MHz platforms. The WebMap and DBMS server loads can be supported with 4 core (1 chip) configurations, so these were reduced to save on platform and licensing cost. The Windows Terminal Server platforms were configured with minimum of 68 GB physical memory (RAM), the Database servers with 32 GB RAM, and 12 GB RAM for the Web mapping servers. Projected CPU utilization rates are shown for each tier (less than 28 percent utilization for the Web mapping tier and 13 percent for the Database platforms - these platforms could be hosted on two virtual servers supported by one of the physical machines).

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 normally address a two- or three-year schedule to ensure that the budget is in place for the anticipated deployment needs. Figure 11-25 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-26 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-25) are identified on the CPT workflow requirements analysis display. The new remote site bandwidth connections identified from figure 11-26 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.



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-26) shows 10 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 90 Mbps. Remote site upgrades include Operations, Petersville, and Rogerton to 24 Mbps; Willsberg and Wawash connections to 18 Mbps, and the Jackson connection to 12 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-27 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. 

Year 2 City Hall System Architecture Design Solution
The capacity planning tool is now ready to identify the year 2 platform solution. The CPT display (figure 11-28) shows the minimum recommended platform solution for the year 2 city network workflows when using the selected platforms. Platform configuration requirements are provided by the capacity planning tool after the user requirements and platform selections are complete. Figure 11-28 also provides an overview of the workflow peak loads and the Workflow Performance Summary.



The Phase 2 City network workflow requirements can be supported with three (3) Xeon X5677 8 core (2 chip) 3467 MHz Windows Terminal Servers (each with 78GB RAM), one (1) Xeon X5677 4 core (1 chip) 3467 MHz Web mapping server (12 GB RAM), and one (1) Xeon X5677 4 core (1 chip) 3467 MHz (42GB RAM) 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 service time component represent platform processing wait times (queue-time models are discussed in chapter 5). 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-29 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.



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-30 shows the Police hardware configuration and software install. The Web, ArcGIS Server, and DBMS software are installed on a single Police server, as shown in the platform configuration module.

 The police network platform final design is shown in figure 11-31, 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).

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

A review of the Workflow Performance Summary suggests there are no identified performance bottlenecks. <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 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)