City of Rome 28th Edition (Fall 2010)

Fall 2010 City of Rome 28th 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, 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.



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-16 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-18 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-19 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-25 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-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.



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  workgroup server.



The Police Workgroup server is a Xeon X5640 4 core (1 chip) 2667 MHz  platform with a Windows operating system. Software is installed in a Physical platform environment.

The police network platform final design is shown in figure 11-32, 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 24 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 X5640 platform could support  the peak workflow loads with a single quad core chip. The selected police network workgroup server is the Xeon X5640 4 core (1 chip) 2667  MHz platform satisfying peak processing loads at less than 30 percent  utilization. Figure 11-32 shows the selected Police design solution.

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

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
[Spring 2010 City of Rome 27th Edition]

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