System Design Process 43rd Edition

Fall 2018 System Design Process 43rd Edition

The purpose of this document is to share a system design methodology that promotes successful deployment of geographic information system (GIS) technology. This system design methodology includes guidelines for identifying business requirements, making appropriate software selection, using properly configured data sources, and providing sufficient hardware to meet user productivity needs. This document focuses on system performance and scalability - building a GIS that will perform during peak operational loads.

Much more can be said about business requirements analysis (GIS User Needs) and available software functionality - this is not the focus of this documentation. Dr Roger Tomlinson (Father of GIS) provides an excellent book that shares a proven framework for comprehensive GIS planning called Thinking about GIS. Understanding the information products you want out of the GIS and identifying the software candidates you might use to produce these information products is a prerequisite for completing your system architecture design. The Planning for Building a GIS video series shares an overview of this business process analysis planning methodology. 

What Is System Architecture Design?
System architecture design is a process developed by Esri to promote successful GIS enterprise operations. This process builds on your existing information technology (IT) infrastructure and provides specific recommendations for hardware and network solutions based on existing and projected business (user) needs.

The system architecture design process aligns identified business requirements (user needs) derived from business strategy, goals, and drivers (business processes) with identified business information systems infrastructure technology (network and platform) recommendations. The computer display transaction is the work unit used to translate business requirements to associated server and network loads. Display service times (software processing) generates platform loads and display traffic generates network loads. Peak throughput loads (business needs) are used to generate platform capacity and network bandwidth requirements.

System design starts with identifying business needs. This includes identifying user locations and required information products, identifying required data resources, and developing appropriate software applications to do the work. Business needs are represented by project workflows that identify the traffic and processing associated with each display transaction.

System architecture design translates business needs to identified IT requirements. Hardware requirements are generated based on peak software processing loads. Network connectivity requirements are generated based on peak data flow. Capacity Planning tools are provided to automate the design analysis. Capacity Planning Tools make the process of aligning Business workflows with selected IT resources agile and iterative in nature, rapidly identifying system performance impacts in response to changing business and technology architecture patterns.

"Warning: Trying to build a GIS without completing a proper system architecture design can lead to system deployment failure."



Why Is System Architecture Design Important?
System performance is limited by the weakest link in the system design. System architecture design identifies the weak links during the planning process and promotes investment in a balanced system design.

A distributed computer environment must be designed properly to support user performance (productivity) requirements. The weakest "link" in the system will limit performance. The system architecture design process identifies specifications for a balanced hardware solution. Investment in hardware and network components based on a balanced system load model provides the highest possible system performance at the lowest overall cost as represented by the chain in Figure 1.2.

Building a high-performance GIS requires more than getting the hardware right. User workflows must be designed to optimize client productivity (simple maps) and efficiently manage heavier geoprocessing loads (service request queue). The geodatabase design and data source selection should be optimized to address system performance and scalability requirements. The selected production platform components (servers, workstations, storage) must have the capacity to handle peak user workflow processing loads within an acceptable service response time. The system architecture design must address performance needs and bandwidth constraints over distributed communication networks—technology and solution architecture must be selected to conserve shared infrastructure resources. System architecture design can provide a solid foundation for building a productive operational environment.

Workflow complexity determines processing and data flow loads that must be handled by the computing infrastructure. The computing architecture must be selected with the appropriate capacity to service the required business loads. Workflow complexity is a measure of the amount of processing loads and network traffic required to refresh the user display. Complexity is imposed on the computing architecture by the following design attributes:


 * Database design and data format: DBMS, geodatabase, and ArcSDE
 * User workflow software design: Application development

The computing infrastructure must provide sufficient capacity to handle peak operational loads.


 * Server platform processor core and deployment architecture must handle peak processing loads.
 * Network bandwidth and remote site connectivity must be adequate to avoid traffic contention.
 * Storage access performance and capacity must be adequate to provide required data access.

Server performance, network capacity, and efficient storage strategies can improve user productivity and reduce system cost.

The system architecture design process can be used to identify specifications for a balanced hardware solution. Investment in hardware and network components based on a balanced system load model provides the highest possible system performance at the lowest overall cost. 

Why we do planning
The primary reasons for planning include identifying business needs, defining project requirements, and reducing implementation risk. In practical terms, we need a plan if we hope to get something done. The plan provides a foundation for successful implementation. Figure 1.3 identifies some of the primary planning objectives.

Business requirements may include a variety of user workflows and Web services that would improve business operations – these workflows and services must be identified early during the planning process. The workflow and service definitions establish a foundation for the rest of the planning.

The peak user workflow and service processing requirements must be identified and translated to appropriate system design loads – server processing times and network traffic. These processing loads provide a foundation for generating appropriate hardware specifications (performance and capacity requirements) and network infrastructure needs.

A project must be defined to procure and implement the required technology. The project will include a budget and schedule along with a variety of project performance milestones. Project approval is required before any major design and/or implementation efforts begin. Project approval is based on identified or perceived benefits that will accrue to the business resulting from the proposed level of time (schedule) and financial (budget) investment.

A good plan can be used to reduce system implementation risk. Delivering a system that will satisfy identified business requirements is fundamental to project success. Understanding key system performance parameters, identifying incremental system performance targets, and establishing a system performance validation plan can chart a solid framework for managing implementation risk.

Planning is an incremental process driven by rapidly changing technology. The most effective plans are designed to adapt to changing business needs and evolving technology opportunities. The established change control process must be agile and effective to ensure project tasks are managed to deliver within established schedule and budget constraints.

What questions are we trying to answer?
There are many questions about system architecture design that we answer on a daily basis. The System Design Strategies documentation deployed on this wiki site is developed and maintained to answer most of these questions, and provide a reference to help customers better understand their design needs.

Here is a short list of some of the more common questions:


 * How many users can I support with my existing hardware?
 * What hardware do I need to purchase?
 * How many servers (cores) do I need?
 * What are the software licensing requirements?
 * What workflow loads should I use for my existing applications?
 * What are my current workflow service times?
 * What is the capacity of my current system?

This documentation, along with the companion Capacity Planning Tools, was developed so you can answer these questions about your GIS, and many more. We have been supporting GIS customers for over 25 years, and much of what we have learned is shared so you can benefit and build a successful GIS. 

What demands does GIS place on the computing infrastructure?
GIS applications place heavy demands on server processing and network bandwidth resources. For most standard mapping operations, these demands push the limits of platform processor (CPU) and network bandwidth (I/O) capacity.

Several key infrastructure components work together to service business processing loads.


 * Network I/O: Network traffic demands on available bandwidth
 * Processing: Platform processor core processing demands
 * Memory: Platform physical memory utilization
 * Graphics: Video graphics card loads
 * Disk I/O: Storage disk access performance

Different workflows place different loads on the system. Relative processing demands for the four use patterns above show how these loads are distributed differently, based on the workflow.
 * Data query and analysis is network I/O intensive.
 * Analysis and processing is compute (processing) intensive.
 * Fly-through and 3D animation can be graphics intensive.
 * Data loading and conversion can be disk I/O intensive.

GIS operations are typically network and/or processing intensive—these are the subsystems that require the closest attention. GIS applications place heavy demands on server processing and network bandwidth resources. For most standard mapping operations, these demands push the limits of platform processor and network bandwidth capacity.

Additional critical design components include the following:


 * Memory is critical if you do not have enough; memory requirements can normally be satisfied by following standard configuration guidelines. Platform memory guidelines are provided in Windows Memory Management appendix.
 * Some GIS desktop applications are graphics intensive (3D animation); video graphics are less critical for GIS than for the video gaming industry, so there is plenty of graphics technology available at reasonable cost to meet GIS needs.
 * Disk I/O can be a concern if you are moving large volumes of data in or out of storage, such as with imagery or map cache generation (normally a background administrative process).

Any one of these components, if configured incorrectly, can become a bottleneck and limit system performance.

System architecture design is about building a balanced solution that satisfies peak performance needs at the lowest possible cost. Each of these critical subsystems should be considered in establishing the right system design. 

Cost of a change
Getting it right from the start is best done by taking the time to understand the technology, quantify user requirements, select the right software technology, and deploy the right hardware. Not getting it right from the start will cost money to make it right later. The cost of change increases exponentially as implementation proceeds as shown in Figure 1.6.

Your GIS plan should include performance validation early in the design process. ArcGIS for Desktop authors should have performance targets they verify when publishing a new map service. GIS programmers should have performance targets they build to when developing a new application. Performance should be a consideration for data administrators, network administrators, and selected storage subsystems. Getting the design right from the start can save money and improve overall business operations. 

What is the System Design Process?
The system design process includes a GIS needs assessment and a system architecture design. The system architecture design is based on user workflow requirements identified in the GIS needs assessment.

Traditional system design process
GIS Needs Assessment: The GIS needs assessment includes a review of user workflow requirements and identifies where GIS technology can improve the quality and productivity of the business process flow. This assessment identifies GIS application and data requirements and an implementation strategy for supporting GIS user needs. The user organization must be actively involved throughout the user needs assessment. A GIS solutions architect familiar with current GIS technology patterns and customer business practices can help facilitate this planning effort.

System Architecture Design: The system architecture design is based on user requirements identified by the GIS needs assessment. Customers must have a clear understanding of their GIS application and data requirements before they are ready to complete their system architecture design. An enterprise architect familiar with GIS software patterns and system design analysis is typically used to complete the final system design and analysis. Technology purchase decisions should be delayed until after completing the system architecture design analysis.

The system design begins with a technology exchange. The technology exchange provides a foundation for client support throughout the design process. Client participation is a key ingredient in the design process. The design process includes a review of the existing computer environment, GIS user requirements, and system design alternatives. System design capacity planning tools can be used to translate projected peak user workflow requirements to specific platform specifications. An integrated implementation strategy can then be developed to support GIS deployment milestones.

"Warning: Problems can occur when software technology selection is made based on a GIS needs assessment without considering system architecture design implications."

Enterprise business needs assessment


Traditionally, the user needs assessment and the system architecture design were two separate efforts. There are some key advantages in completing these efforts together. Figure 1.7 shows an overview of the system architecture design development methodology. Enterprise architects now have tools they can use to complete an enterprise wide business needs assessment.

There are four architecture domains that are commonly accepted as subsets of an overall enterprise business needs assessment. These include generally accepted guidelines and best practices provided by The Open Group global consortium.


 * The Business Architecture defines the business strategy, governance, organization, and key business processes.
 * The Information Systems Architecture includes a review of the Data and Application architecture.
 * > The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources.
 * > The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.


 * The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

A primary goal behind developing capacity planning tools is to automate the system architecture design analysis in such a way that GIS solution architects can use these tools to complete a user needs assessment and a system architecture design within an enterprise level business needs assessment. An enterprise level business needs assessment promotes an adaptive discovery effort, enabling optimum alignment between evolving business and technology architecture patterns. 

Building a GIS: Implementation strategy
There are several critical deployment stages that support a successful implementation. Understanding the importance of each stage and the key objectives for success leads to more effective enterprise implementations. Figure 1.8 shows a series of typical system deployment stages for building and maintaining successful enterprise GIS operations.

 Requirements phase
 * User information product needs establish a foundation for completing the design.
 * User location and peak business loads establish a foundation for system architecture design.

Design phase
 * Infrastructure requirements must be identified to quantify deployment costs.
 * Network communication capacity is an important consideration for GIS deployments.
 * Hardware and software procurement requirements must be identified.
 * Software development and data acquisition needs must be identified.

"Best Practice: Business decisions for project funding and procurement authorization are often required for project effort to proceed beyond this phase."

Construction phase
 * System procurement authorization, based on the design budget and deployment timeline.
 * Data acquisition and database design efforts begin.
 * Procurement authorization for application design and development.
 * Prototype testing plans completed and scheduled to validate product delivery within design performance targets.

Implementation phase
 * Initial deployment and operational testing.
 * Final system delivery, user training, and workflow migration complete.
 * System maintenance operations.

"Best Practice: Deployment process is repeated incrementally on a periodic schedule to leverage technology change."

The Capacity Planning Tools (CPT) were developed as a framework to promote successful GIS system design and implementation. CPT functions contribute throughout the implementation cycle. The CPT tasks include a review of business needs, establish performance targets, identify user locations, review network suitability, select the product architecture, select the optimum software configuration, and complete the system architecture design analysis. Additional tools are provided to validate system performance during the design, construction, and implementation phases. CPT models can be easily updated and maintained to reflect changes in business requirements and review alternative system deployment strategies, providing an adaptive model for addressing a variety of incremental planning activities.

"Best Practice: Build and maintain a simple system performance model that links user requirements with system design." 

System design strategies overview
Enterprise GIS design includes a broad range of technology that must play together to satisfy identified business needs. The better they work together, the more productive your business can be.

System design topics will be discussed throughout the SDSwiki documentation.


 * Software technology: Chapter 2
 * Software performance: Chapters 3 and 4
 * Data administration: Chapter 5
 * Network communications: Chapter 6
 * Platform performance: Chapter 7
 * Information security: Chapter 8
 * Platform architecture: Chapter 9
 * Performance Management: Chapter 10
 * City of Rome case study: Chapter 11
 * System Implementation: Chapter 12

All of the SDSwiki system architecture design content (Chapters 1-10) are brought together in a system architecture design case study for the fictional City of Rome.

Several key lessons learned are identified in Chapter 12: System Implementation sharing important project management and system delivery practices that reduce implementation risk. The purpose of the system design strategies documentation is to share fundamental practices that promote GIS implementation success. 

Capacity planning terminology
There is a great deal of terminology used within the System Design Strategies wiki that might be new to many readers. System architecture design crosses a variety of disciplines, including business operations, IT operations, and software development. The terminology introduced in this SDSwiki works to build a common vocabulary for communications that bring these groups together—establishing a framework for discussing and addressing system performance problems.

User workflow terminology
User workflow complexity is defined by service time. The user is the person working at the computer display. Service time is the average display refresh processing time.

There are three common types of user productivity: light, casual, and power.

"Best Practice: Select the appropriate productivity for each user workflow." General guidelines:


 * 10 DPM is maximum user productivity for a power desktop user.
 * 6 DPM is maximum user productivity for a web client workflow.
 * 3-5 DPM is appropriate for casual users.
 * 1 DPM is appropriate for light users.

Service time is determined by software functions, data source, and display complexity


 * Light complexity is half the processing time of medium complexity.
 * Medium complexity is the workflow processing baseline.
 * Heavy complexity is 50 percent more than medium complexity.
 * Very complex workflows are possible (up to 10x medium).

'''Warning: Work transaction service time directly affects system loads. '''

"Best Practice: A heavy workflow complexity is a conservative initial planning performance target for most software technology selections." 

Workflow performance
Response time is the sum of service time and queue time. Response time is the total time to complete an average display refresh. Queue time is the average process wait time due to service contention.

System queue time is predictable for large random populations.


 * Large population: System throughput rates normally exceed several thousand transactions per hour, and each transaction can include hundreds of program instructions.
 * Random distribution: System throughput loads are caused by hundreds of transactions generated by each user.
 * Large random distribution of display transactions follows a predictable random arrival distribution.

Queue time variables include system utilization and transaction service time.
 * Queue time increases with increasing platform utilization.
 * Queue time increases with increasing transaction service times.

Response time is important because it can affect user productivity. "Best Practice: The faster a user can work, the more work the user can do." 
 * As queue time increases, response time will increase and user productivity may decrease.
 * Power users can be very sensitive to minor changes in display response times.
 * User productivity can have a direct effect on business operations and the system's ability to meet user needs.

System performance terminology
System performance terminology can be represented by simple relationships.
 * A workflow transaction (display) is an average unit of work.
 * Throughput is a measure of the transaction rate.
 * Capacity is the maximum rate at which a platform can do work.
 * Utilization is the percentage of capacity represented by a given throughput rate.

Display transaction is the processing load to render a new user display.
 * The software program provides a set of instructions executed by the computer to complete a work transaction.
 * The processor core executes the instructions defined in the computer program to complete the work transaction.

Transactions with more instructions represent more work, while transactions with fewer instructions represent less work.

Throughput is average work transactions completed over time.
 * Expressed in displays per minute or transactions per hour.
 * An average cumulative processing load is applied to the server.

As throughput increases, the processing load on the server increases.

Platform capacity is 100 percent throughput.
 * Expressed in displays per minute or transactions per hour.
 * Maximum server throughput is less than platform capacity.

Platform utilization is the percentage of time that the processor is busy.
 * Processor is busy when servicing a transaction.
 * Processor is not busy when waiting for a transaction.

Utilization of 60 percent means that the processor is busy 60 percent of the time.

Platform utilization is the percentage of activity over a period of time.
 * Short sampling periods (1 second) are difficult to evaluate.
 * Longer sampling periods (30 seconds) show average utilization.
 * Long sampling periods (30 minutes) may underestimate peak values.

"Best Practice: Time period should represent a statistically significant sample of random transaction arrivals (100 or more transactions). " 

Valid workflow
What is a valid workflow?

All user workflow performance terms work together during each display transaction to satisfy business performance requirements.

Workflow specifications:
 * User productivity = 10 DPM/client (user workflow performance needs)
 * Display cycle time = 6 seconds (60 seconds in a minute divided by 10)

For a given display executed on a given platform:
 * Display service time is a constant value.
 * In a shared server environment, queue time increases with increasing user loads (increasing server utilization).
 * As queue time increases, display response time increases.
 * For a fixed user productivity (10 displays per minute), computed user think time will decrease with increasing display response time.

For a valid workflow, the computed user think time is greater than the minimum think time.

'''Warning: At some point, the computed user think time will be less than the minimum think time (invalid user workflow). '''

During peak system loads, the queue time can increase to a point where computed think time is less than minimum think time. 
 * Workflow productivity must be reduced to identify a valid workflow.
 * CPT includes a RESET ADJUST function that will automatically reduce workflow productivity to the proper reduced value.

Batch process
What is a batch process?

A batch process is a workflow that does not require user interaction. Most heavy GIS analysis can be modeled as a batch process.

There are several advantages of configuring geoprocessing functions as a network service:
 * A service work request is sent to a processing queue to await execution.
 * A limited number of server cores can be allocated to execute the service requests.
 * Users can do other work while waiting for service response.

Batch process loads are modeled for workflows with zero (0) think time.
 * Batch productivity is calculated based on computed response time (60 seconds/response time = batch DPM).
 * Batch process queue time is caused by service contention (no random arrival queue time).
 * Transactions are processed sequentially.
 * Batch processes deployed on a single platform with local data source tend to consume a single processor core.
 * The CPT Design tab will distribute loads across available core resources based on batch workflow profile.

"Best Practice: Any heavy geoprocessing function that may be requested by more than one user at a time should be separated from the user application workflows and executed as a separate network batch process. "

'''Warning: The CPT Design productivity ADJUST function must be used to compute system loads and batch process productivity. '''

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

Planning begins by thinking about what you want out of the system.
 * What is the overall business strategy?
 * What are the critical business processes?
 * What information products drive business decisions?
 * What are the critical data resources?
 * How does GIS support current business operations?
 * What are the current business needs?
 * What are the GIS software technology needs?
 * What are the available software technology deployment patterns?
 * What is the process for migrating business operations to the new technology state?
 * What are the costs and benefits for making this business change?

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

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

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

System architecture design process
The enterprise GIS system design process aligns identified business requirements (user needs) derived from business strategy, goals, and drivers (business processes) with recommended business information systems infrastructure technology (network and platform) recommendations.
 * 1)  User needs assessment (results of a GIS user needs assessment provides inputs for the system architecture design analysis)
 * 2)  Workflow loads analysis (translate user needs to project workflows with baseline traffic and processing transaction loads based on estimated workflow complexity)
 * 3)  Technical architecture strategy (identify user locations, network connectivity, and data center server locations)
 * 4)  User requirements analysis (translate peak user workflow loads to peak throughput transaction loads)
 * 5)  Network suitability analysis (translate peak site/network throughput loads to peak site/network traffic and compare with available network bandwidth)
 * 6)  Platform architecture selection (Identify data center platform tier configuration and identify platform selection for each tier)
 * 7)  Software configuration (Identify platform assignment for each workflow software component peak transaction processing load)
 * 8)  Enterprise design solution (combine all peak workflow software component processing loads on the assigned platform tier, translate baseline processing load to selected platform processing load, and generate number of nodes required for each platform tier with estimate of capacity utilization)

The Esri Capacity Planning Tool (CPT) was developed to simplify business requirements data collection and automate system design analysis tasks associated with each phase of the development cycle. This section will introduce the available capacity planning tools and their function in completing a system architecture design. Hyperlinks are provided to associated CPT demos located in the Capacity Planning Tool appendix.

The CPT can be used to identify your system design requirements and model performance and scalability of your enterprise design. The CPT provides a framework for integrating business, data, applications, and technical architecture needs required to design, deploy, and manage successful enterprise GIS operations. 

Pre-design efforts


Figure 1.16 shows how you can prepare for your system architecture design. Business needs must be understood before you are ready to complete the system architecture design. Business requirements analysis includes a review of the enterprise vision, the existing business architecture, and the user workflow requirements. Each of these areas must be explored in some detail before you begin the design.

The GIS needs assessment begins with the organization identifying where GIS technology can improve the quality and productivity of the business process flow. This assessment identifies GIS application and data requirements and an implementation strategy for supporting GIS user needs. The user organization must be actively involved throughout the user needs assessment. A GIS solutions architect familiar with current GIS technology patterns and customer business practices can help facilitate this planning effort; the real work must be done by the organization themselves.

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

GIS software deployment patterns are optimized to support your business needs:
 * Location enablement
 * Data management
 * Analysis
 * Field mobility
 * Visualization (Operational Awareness)
 * Constituent engagement

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

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

Review Business Needs
Figure 1.18 identifies the CPT tabs for documenting findings from your pre-design efforts

Business needs (user requirements) establish a foundation for building a proper system design. Business requirements are represented by user workflows. The first step in completing a system architecture design is to select the appropriate software deployment patterns (project workflows) and identify the peak user workflow profiles loads. GIS Software Technology chapter provides an overview of the primary GIS workflow patterns along with best practices for making a proper technology decision.


 * CPT Workflow loads analysis

The Project Workflows section on the CPT Workflow tab is located at the top of the workflow list. Project Workflows are selected from the Standard Workflows included on the CPT Workflow tab or custom workflows generated from the CPT Calculator or Test tabs - identifying your project workflows is the process referred to as your user workflow loads analysis. Once your software technology (project workflow) selection is complete, your selected workflow performance targets will be available at the top of the CPT workflow selection list for use in your system architecture design.

System Design Process
Once you have identified your project workflows, you are ready to complete your system design. The CPT is developed for use based on a standard system architecture design process as shown in Figure 1.19. Each cycle of the system architecture design process includes the following steps:


 * Technical architecture strategy—High-level overview showing user site locations, network bandwidth connections, and central data center locations. User location information is collected during the user needs analysis.
 * User requirements analysis—CPT Requirements analysis section is configured to represent the site locations, user workflows, peak loads, and network bandwidth for the enterprise design solution.
 * Network suitability analysis—CPT Design completes the network suitability analysis and identifies any communication bottlenecks. Network bandwidth upgrades are identified to complete the network suitability analysis.
 * Platform architecture selection—CPT Design Platform tier is configured to represent the design solution. Identify platform tier nicknames, select platforms, and identify platform rollover settings.
 * Software configuration—CPT Design Software Configuration module is used to assign workflow software to supporting platform tier (software install) and make workflow data source selection.
 * Enterprise design solution—Once configured, the CPT Design tab completes the system architecture design analysis and provides the platform solution.

Technical architecture strategy
During your user needs assessment, you must identify all user locations requiring access to GIS server applications and data sources. This should 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 network infrastructure must be able to accommodate peak workflow traffic loads.
 * Know where users are located.
 * Know network bandwidth communication constraints.
 * Identify the location of necessary data resources.

"Best practice: A simple diagram can help identify user locations and network connectivity constraints." 

User requirements analysis


Figure 1.21 shows the steps to complete the system design. System design process includes the user requirements analysis, network suitability analysis, platform architecture selection, software configuration (installation), and the enterprise design solution.

The CPT was designed to complete the analysis. Once the CPT is properly configured and business requirements are defined, the CPT will complete the system architecture design analysis and display the hardware solution.


 * CPT Design tab: User requirements analysis

Once you identify your business workflows, you are ready to complete a user system loads analysis. The CPT Design tab includes a Requirements Analysis module where you can identify user locations and peak throughput loads.

Network suitability analysis

 * CPT Design tab: Network suitability analysis

Once you configure the CPT Design tab to reflect your user requirements and identify the network connections, the CPT completes a network suitability analysis. Network suitability analysis is completed by the CPT Design tab. The CPT analysis evaluates network bandwidth and latency to ensure adequate capacity to accommodate peak traffic flow loads. You can then increase network bandwidth as required to accommodate peak traffic loads.

Platform architecture selection

 * CPT Design tab: Platform architecture selection

Platform selection is a critical decision in any design process. The selected platform directly contributes to user display performance, platform capacity, and software licensing cost. A faster processor core improves user performance and reduces license cost. Higher capacity servers reduce the total number of server machines required to satisfy business requirements.

"Warning: Platform selection directly impacts overall system cost."

Software configuration

 * CPT Design tab: Software configuration

"Note: CPT Design software configuration will be discussed in more detail in Lesson 7: GIS product architecture."

Enterprise system design

 * CPT Design tab: Enterprise system design

Once you make your platform selections and install workflow software components (software configuration), the CPT will complete the platform sizing and show the required server configuration (number of platforms and peak utilization levels for each platform tier).

The Design tab provides a snapshot view of your user requirements and associated platform solution as a single integrated information product.

"Note: Chapter 11 provides a case study for the City of Rome, demonstrating how to use the CPT to complete an enterprise system architecture design."


 * CPT Hardware tab: Platform performance

The CPT Hardware tab is used to list SPEC performance benchmark values for use in completing the system architecture design.

Monitor performance compliance
The capacity planning tool (CPT) can be used by project managers to establish specific project performance milestones and measure compliance. Figure 1.22 shows some key opportunities for measuring performance compliance.


 * Measuring display rendering time when authoring a service is the first opportunity to validate performance.
 * Measuring deployed service rendering time is another opportunity to validate performance.

"Best Practice: Monitoring progress in meeting performance milestones can reduce deployment risk and ensure project delivery success."

When performance issues are identified early in deployment, proper adjustments can be made before impacting production workflow productivity. Simpler map displays, simpler data models, and cached data layers are proven ways to reduce workflow complexity. Warnings identified by the map publishing analysis tool identify how to reduce display complexity.

"Best Practice: Identifying and resolving performance issues before they become production level performance problems will promote deployment success."

Figure 1.23 shows some tools that were developed to translate system performance measurements to workflow service times for use in performance validation. The CPT Test tab was designed to help with the validation process, and includes several tools that can be used to translate performance measurements to equivalent workflow service times.


 * Performance validation (CPT Test tab)

Measuring performance during the system build and deployment reduces implementation risk. System design is only the beginning of the process; then you need to build a system that performs within the system architecture design performance targets. If measured performance loads exceed planned budgets, adjustments can be made to workflow complexity during the build process to deliver services within initial performance targets.

Platform capacity calculations
Platform capacity for a standard map display can be calculated for any selected platform. Platform capacity varies based on selected platform throughput performance and published map display complexity. Vendor published throughput benchmarks (SPECint_rate2006 Baseline) available on the SPEC Web site shows relative platform throughput for available server platform configurations.
 * 2018 Baseline System Specifications
 * Arc18 4-core platform performance SPEC baseline = 296 (SPECint_rate2006 Baseline)
 * ArcGIS for Server REST 2D V 100%Dyn 1366x768 resolution PNG24 output
 * Baseline 4-core medium complexity throughput capacity = 84,600 TPH


 * Variations in platform performance and workflow display complexity drives selected platform throughput
 * Platform SPECint_rate2006 baseline = 400, medium complexity, throughput = 116,250 TPH
 * Platform SPECint_rate2006 baseline = 100, medium complexity, throughput = 29,063 TPH
 * Platform SPECint_rate2006 baseline = 200, light complexity (0.5x medium), throughput = 116,250 TPH
 * Platform SPECint_rate2006 baseline = 200, heavy complexity (1.5x medium), throughput = 38,750 TPH

This section ends by introducing a simple tool used for proper hardware platform selection. The Platform Capacity Calculator identifies the single server throughput capacity of the selection platform configuration.


 * Platform Capacity Calculator

The Platform Capacity Calculator provides a peak throughput range for selected workflows, showing medium complexity output in blue and light complexity output in red. This provides a simple tool to help customers select the appropriate platform configuration.

CPT Calculator tab provides a much more accurate platform capacity planning assessment for a single workflow configuration, taking into account software performance variables and hardware configuration strategies.

CPT Design tab provides a much more adaptive enterprise capacity planning assessment integrating system loads for multiple workflows supporting multiple network local and remote sites and a variety of platform configuration strategies.

Concluding remarks
Proper GIS planning is the most important investment any organization can make in building a GIS. Understanding your GIS needs, selecting the right technology at the right time, and establishing documented implementation milestones to measure your progress can ensure your success. This document is focused on sharing how to build and maintain successful GIS operations. The Capacity Planning Tools provide a framework for collecting what you know about your business needs and your system environment. The Capacity Planning Tool models connect what you understand about GIS user requirements with the network and platform loads your IT support teams can measure in the data center.

=CPT Capacity Planning videos=

The next Chapter will review the most common GIS technology patterns and share best practices in making the right technology selection.

Previous Editions
System Design Process 42nd Edition System Design Process 41st Edition System Design Process 40th Edition System Design Process 39th Edition System Design Process 38th Edition System Design Process 37th Edition System Design Process 36th Edition System Design Process 35th Edition System Design Process 34th Edition System Design Process 33rd Edition System Design Process 32nd Edition System Design Process 31st Edition System Design Process 30th Edition System Design Process 29th Edition System Design Process 28th Edition System Design Process 27th Edition

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