System Design Process 28th Edition (Fall 2010)

Fall 2010 System Design Process 28th 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 is focused 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.

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. Application requirements, data resources, and people within an organization are all important in determining the optimum hardware  solution as shown in figure 1-1.

Early GIS customer implementation experiences highlighted the importance of understanding  the relationship between user business workflow requirements and the  supporting hardware and network infrastructure loads. A process was established to understand GIS business needs, identify common user  workflows (application and data architecture patterns), and apply a  system architecture design methodology to identify technology solutions  that contribute to successful GIS operations.



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.



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  process.

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.

Why Is System Architecture Design Important?
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 derives 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 shown in figure 1-3.



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.

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 the project implementation proceeds as shown in Figure 1-4.



What is the System Design Process?
The traditional 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. Figure 1-5 provides an overview of the 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 user workflow. 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 professional consultant familiar with current GIS solutions 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 the system architecture  design. System implementation planning should schedule hardware purchases "just in time" to support user deployment needs.

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. The system design capacity planning tools translate projected peak user  workflow requirements to specific platform specifications. An integrated implementation strategy is developed to support GIS deployment  milestones.

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-6 shows the project time line relationship between the traditional user needs assessment and the system architecture design  process.

The GIS software technology selection process should include a discussion of architecture options and available system  deployment alternatives. The existing hardware environment, peak user workflow operations, and user location information required for a system  design should be identified during the user needs workflow interviews. Software technology selection should consider hardware configuration options, required platform selection, peak system loads for each  configuration option, and overall system costs. User productivity may be a primary consideration in making the right software technology choice. And finally the system implementation schedule must consider hardware and application delivery milestones. A primary goal for developing capacity planning tools is to automate the system architecture design  analysis in such a way that GIS professional consultants can complete a  user needs assessment and a system architecture design within an  integrated business needs assessment.



What Does It Take to Support Successful GIS Operations?
There are several critical deployment stages that support a successful  implementation. Understanding the importance of each stage and the key objectives that support success leads to more effective enterprise  implementations. Figure 1-7 shows a series of typical system deployment stages for building and maintaining successful enterprise GIS  operations.



The system architecture design Capacity Planning Tool (CPT) was developed  as a framework to promote successful GIS system design and  implementation. CPT functions contribute throughout the implementation cycle.



Requirements Stage:
Understanding GIS technology alternatives, quantifying GIS user requirements, and  establishing an appropriate system architecture design deployment  strategy are critical during the requirements stage. Capacity planning during this phase can help establish appropriate software performance  specifications. Figure 1-8 provides an overview of the CPT Calculator highlighting its role during the software technology selection process.



A review of available software technology patterns and software  performance parameters can provide key information for technology  selection. This is a planning stage where "getting it right" can save considerable effort and money throughout the implementation. User workflow analysis should generate reasonable workflow performance  targets for use in the system architecture design. Figure 1-9 highlights the role of the CPT Workflow tab in selecting appropriate user workflow  performance targets in preparing for the enterprise system design.



Peak concurrent users and workflow productivity establish system throughput  loads that drive the system architecture design. Understanding user locations and infrastructure limitations can impact software technology  selection. Figure 1-10 highlights the role of the CPT Design in completing the user requirements analysis.





Design Stage:
System development and prototype functional testing build the components and  confidence to support the follow-on deployment. This is where time and money are invested to build and test the selected environment. Initial prototype testing demonstrates functionality and reduces implementation  risk. Preliminary software performance testing can validate initial capacity planning assumptions.

The system design includes vendor hardware selection. Figure 1-11 highlights the role of the CPT in sharing vendor hardware performance and capacity benchmarks,  and integrating platform performance with the design to identify system  capacity needs.



The selected platform architecture and software installation will determine  availability and scalability of the final hardware design. Figure 1-12 provides an overview of the CPT Design software configuration module.



The CPT software configuration module provides flexibility to define  software component platform installation and data source selection for  user workflows located throughout the enterprise environment. Figure 1-13 identifies the CPT platform selection model.



Platform performance can have significant impact on user productivity and peak  system capacity. Capacity planning tool includes enterprise GIS design options for configuring up to 10 separate platform tier, each tier can  expand to meet peak capacity design requirements.

The CPT system architecture design analysis will apply identified peak user  workflow requirements to the selected platform architecture, identifying  required platform nodes and expected peak utilization. Figure 1-14 shows an overview of the CPT Design graphic platform solution display.



User workflow productivity is directly related to display performance. Workflow performance depends on user location, network connectivity, software install, platform selection, and peak system loads. Figure 1-15 shows an overview of the CPT Design Workflow Performance Summary.



User workflow display performance at locations throughout the enterprise  environment is an important consideration in making a final software  technology selection. The selected design solution should be configured to satisfy user performance needs.



Construction Stage:
A successful initial system deployment can set the stage for success. This is where the solution comes together and final operational support needs are validated. This is an important time to demonstrate performance and the capacity of the deployed system and validate that  the selected hardware and infrastructure will support full production  deployment. Several tools are provided on the CPT test tab to translate measured performance to software technology workflow performance  targets used for capacity planning.

Figure 1-16 highlights test measurement tools that can be used by an ArcGIS Desktop  user when authoring a map document for publishing as a Web service. ArcGIS Desktop Map document rendering time can be used to estimate published Web service processing loads during the authoring process. Once the Web service is published, a perfheatmap tool can be used to measure Web service render times throughout the service area. The CPT can use render times collected by the perfheatmap test tool to generate  appropriate service time processing profiles for use by the capacity  planning tools or for performance validation.



Figure 1-17 highlights the CPT Test tab used for translating system throughput  and utilization measurements to validate CPT workflow service times. Web service throughput measurements can be used as an input to calculate workflow service times. Peak concurrent power users can also be used as an input if measured transaction throughput measurements are not  available.





Implementation Stage:
Final system procurement and deployment demonstrate operational success. Capacity planning metrics can be used to monitor and maintain system performance objectives. Good planning, development, and testing will support a smooth deployment, productive operations, and satisfied users.

Establishing workflow performance target milestones and managing software  performance to achieve performance goals throughout deployment is a  positive recipe for success. Building systems without regard to performance and scalability can lead to disappointing results and costly  recovery.

Why use Capacity Planning tools?
Capacity planning tools were developed to simplify the system design process and  reduce implementation risk. GIS workflows generate network and server processing demands across the enterprise. GIS user productivity depends on the available capacity of these shared resources. There are many software technology patterns and performance parameters that impact  workflow performance - it is not easy to put all these pieces together  without modeling your system. System performance is influenced by the combination of many different interrelated factors. Capacity planning tools allow users to focus on technology selection and information  product design - workflow performance and the system architecture design  solution is generated as a function of the technology selection.

CPT Calculator tab:
The Capacity Planning Calculator was developed to address user workflow analysis and software technology selection. Understanding user needs is the first step in building a GIS. Identifying the information product specifications and selecting the right software technology is an important part of the user needs  analysis. The Calculator includes dropdown inputs for software technology selection (software, map document, output) and key software  performance parameters (display resolution, density, complexity, and  percent data cache). The GIS Software Technology and Software Performance sections will describe the technology patterns and software  performance in more detail. Figure 1-18 provides an overview of the Capacity Planning Calculator tab.

The software technology and selected performance parameters generate GIS workflow  performance targets than can be used for the system architecture design. The CPT Calculator generates workflow performance targets from technology baselines and performance adjustment factors derived from  Esri performance validation test results. Workflow performance targets are updated with each software release to incorporate the latest  performance metrics.

The CPT Calculator also provides system architecture design and workflow performance information. User requirements (peak users and productivity or peak service transaction  rates) generate system processing loads, and platform architecture  (tiers, high availability, SDE connection, data source) and platform  technology selection complete the system design inputs. Client network bandwidth connectivity inputs incorporate a preliminary communications  assessment and provide local and remote user workflow display  performance. System design solution is displayed in the platform sizing section. The CPT Calculator provides a complete system design assessment for an informed software technology selection based on identified user  requirements.

CPT Workflow tab:
The CPT Workflow tab provides a lookup table for workflow performance targets (component software service times) used in  the CPT Design tab. A list of Standard Esri Workflows are maintained in the Workflow tab for use in selecting the most common workflow  performance targets. The Standard Esri Workflows were generated from the CPT Calculator and the workflow name identifies the software technology  and performance parameter selections. Workflows not included in the Standard Esri Workflow list can be generated from the CPT Calculator  tab, which is included as a reference workflow on the CPT Workflow tab. A composite workflow analysis section generates representative workflow  service times for a combination of two or more workflow services. Figure 1-19 provides an overview of the CPT Workflow tab, identifying the  primary sources for selecting design workflow performance targets  (Standard Esri Workflows, Calculator, Test, or Composite workflows).

Once the user workflow analysis and software technology selection is  complete, the selected workflow performance targets will be available to  complete the user requirements analysis.



CPT Design tab:
The CPT Design tab was developed as a framework to document and execute an enterprise level system architecture design  analysis. User workflow requirements identify user locations and peak workflow loads (concurrent users or service transaction rates) for each  system implementation milestone. Network traffic loads are generated to complete an enterprise network suitability analysis. Software configuration (not shown below) and platform selection complete inputs  for the system architecture design. The CPT Design tab provides the platform solution (number of nodes and platform Utilization) based on an  integrated analysis of the user workflow requirements and platform  selection. A Workflow Performance Summary provides average display response time for each user workflow. CPT Design includes the ability to adjust user workflow productivity to represent performance within  selected network and platform constraints. Figure 1-20 provides an overview of the CPT Design tab.

Each CPT Design tab provides a complete model of each project deployment milestone. Each Design milestone identifies peak user workflow requirements, network  bandwidth and projected network utilization, platform selection and  projected platform utilization, final hardware selection requirements,  and expected workflow average display response times and productivity  for each user site location. 

CPT Test tab:
The CPT Test tab was developed for use in validating workflow performance  compliance. The CPT Design tab uses workflow performance targets (software component service times) as input values to generate system  level throughput and utilization outputs. The CPT Test tab does just the opposite, it takes live system level throughput and utilization  performance measurements as input values to calculate workflow software  component service times (workflow performance targets that would  generate these results).

The CPT Test tab provides for four different ways to translate live software technology performance  measurements to CPT workflow service times. Measured throughput transaction rate (transactions per hour) is the most accurate. Throughput (TPH) entry will override the other three Test tab input options. Peak users is the second throughput input option. In this case, peak users is multiplied by user productivity (displays per  minute/user) to estimate the throughput transaction rate. The third and fourth options use measured map display render time (ArcGIS Desktop  author can use MXDPerfstat tool or the ArcGIS Desktop Map Publishing  tool can be used to measure MXD render time, PerfHeatMap tool can be  used to map ArcGIS Server map rendering times throughout a defined  service area.  Both of these tools can be used to measure map display  complexity during initial service design and implementation.  The Test  tool links map display complexity to the selected Web mapping software  technology pattern to generate baseline workflow service times. Figure  1-21 provides an overview of the CPT Test tab.



The CPT Test tab can be used by GIS "Authors" who create map documents  (MXD) for Web publishing. Map display rendering time can be measured during map publishing optimization or following initial server  deployment. This is the first milestone in validating workflow performance. During initial deployment, measured throughput values (map display transactions per hour or peak concurrent users) can be used to  validate workflow performance. During live operations, system performance measurements can be used to validate design compliance.

The Capacity Planning Tool provides a model that connects user workflow  requirements with system performance and scalability. Building a GIS based on a system design model that can both establish and validate user  workflow productivity requirements establishes a foundation for  successful GIS deployment. Identifying proper system deployment performance milestones and validating workflow design compliance with  established performance design goals will reduce implementation risk and  ensure system deployment success. The Capacity Planning Tool is designed to help GIS and IT managers understand business needs and  promote more productive GIS operations.

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 Video: System Design Process
The next Chapter will review the most common GIS technology patterns and  share best practices in making the right technology selection.

Previous Editions
[Spring 2010 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)