System Implementation 42nd Edition

From wiki.gis.com
Jump to: navigation, search
System Design Strategies (select here for table of contents)
System Design Strategies 42nd Edition (Spring 2018)
1. System Design Process 42nd Edition 2. GIS Software Technology 42nd Edition 3. Software Performance 42nd Edition 4. Server Software Performance 42nd Edition
5. GIS Data Administration 42nd Edition 6. Network Communications 42nd Edition 7. Platform Performance 42nd Edition 8. Information Security 42nd Edition
9. GIS Product Architecture 42nd Edition 10. Performance Management 42nd Edition 11. City of Rome 42nd Edition 12. System Implementation 42nd Edition
A1. Capacity Planning Tool 42st Edition B1. Windows Memory Management 42nd Edition Preface (Executive Summary) 42nd Edition SDSwiki What's New 42nd Edition


Spring 2018 System Implementation 42nd Edition

Successful system implementation requires good leadership and careful planning. A good understanding of every component of the system is critical in putting together an implementation strategy. Enterprise IT environments involve integration of a variety of vendor technologies. Interoperability standards within commercial software environments are voluntary, and even the simplest system upgrade must be validated at each step of the integration process.

Enterprise GIS environments include a broad spectrum of technology integration. Most environments today include a variety of hardware vendor technologies including database servers, storage area networks, Windows Terminal Servers, Web servers, map servers, and desktop clients, —all connected by a broad range of local area networks, wide area networks, and Internet communications. All these technologies must function together properly to support a balanced computing environment.

A host of software vendor technologies including database management systems, ArcGIS Desktop and ArcGIS Server software, Web services, and hardware operating systems—all integrated with existing legacy applications. Data (including business layers, basemap layers, and Imagery) and user applications are added to the integrated infrastructure environment to support the final implementation. The result is a very large mixed bag of technology that must work together properly and efficiently to support user workflow requirements.

The integration and implementation of distributed computer technology have become easier over the years as interface standards have matured. At the same time, enterprise environments have become larger and more complex. The complexity and risk associated with an enterprise system deployment are directly related to the variety of vendor components required to support the final production solution.

Centralized computing solutions with a single database environment are the easiest environments to implement and support. Distributed computer systems with multiple distributed database environments can be very complex and difficult to deploy and support. Many organizations are consolidating their data resources and application processing environments to reduce implementation risk and improve administrative support for enterprise business environments.

GIS Staffing

People are the most valuable asset to any organization. GIS managers have the special opportunity and challenge to bring people across their organization together to share responsibility for building and maintaining enterprise GIS operations. In most cases, building a GIS is not a single department responsibility – and in many cases the quality of the GIS depends on people outside the organization. GIS brings people together because they depend on each other in establishing the framework for building geographic information products that support their business needs.

Identify Key Staff Functions

Figure 12.1 Key operational staffs participate in data management, planning and analysis, field mobility, and operational awareness disciplines. Key supporting positions include skills in application development and enterprise GIS management.

A broad range of technical skills are required to build and maintain effective enterprise GIS operations. Key operational staffs participate in data management, planning and analysis, field mobility, and operational awareness disciplines. Key supporting positions include skills in application development and enterprise system administration. Figure 12.1 provides an overview of the variety of GIS workflows and key functional responsibilities required to support enterprise GIS operations.

The complexity of these responsibilities will vary with the size and extent of each individual GIS implementation, although every organization will need some level of support and expertise in each of these areas.

Building Qualified Staff

Training is one way to build qualified staff and improve GIS user productivity. Business organizations should develop and maintain a comprehensive training plan to make sure their teams have the resources and skills they need to be effective in their job.

GIS Organizational Structure

Figure 12.2 GIS management must be organized to facilitate implementation across multiple departments and often extend to include a variety of business units within a broader community of GIS users.

Figure 12.2 shows an overview of a traditional GIS matrix organization. Enterprise GIS operations must be supported by an executive committee with influence and power to make financial and policy decisions for the GIS user community. The GIS manager should establish a coordinating committee responsible for providing technical direction and leadership. Committee leaders should chair working groups assigned and aligned with each technical discipline to address organizational issues and report on system status. The user community should be represented throughout the review process.

A formal organizational structure provides a framework for establishing and maintaining the long-term support required for successful enterprise GIS operations. This basic organization structure can be useful in managing GIS in small to large organizations, and the same type of organizational structure can be effective in managing community GIS operations.

Integrated system design process

Figure 12.3 Integrated business needs assessment promotes proper and timely business system design decisions.

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 12.3 shows an overview of the system architecture design development methodology. Enterprise architects now have tools they can use to complete an integrated business needs assessment.

There are four architecture domains that are commonly accepted as subsets of an overall integrated 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.
Best practice: System architecture design should be included as an integral part of every business planning process.


The GIS integrated business needs assessment (user needs/system architecture design) provided in the SDSwiki documentation shares a tailored architecture development methodology to promote successful Enterprise GIS operations. The primary steps for completing an integrated design solution include the following:

  • Business architecture
>Enterprise vision identifies how GIS technology can best support your business needs.
  • Information systems architecture
>Existing business architecture reviews your current data center operations to identify existing experience for deployment and maintenance of available target architecture options.
>Workflow loads analysis identifies business workflows and peak processing loads that must be supported by the target architecture solution.
>Technical architecture strategy identifies data center and business user locations and network connectivity for the proposed target architecture solution.
>User requirements analysis combines user location and workflow loads analysis to identify distributed network and platform processing loads and user productivity.
  • Technical architecture
>Network suitability analysis identifies peak network bandwidth requirements during peak system loads.
>Platform architecture selection identifies data center platform configuration for the target architecture solution.
>Software configuration identifies Enterprise level workflow software loads applied to the data center target architecture selection.
>Enterprise design solution provides a summary of the final target architecture solution that includes required platform nodes, projected platform utilization, peak user workflow loads, and projected user productivity.

The SDSwiki Capacity Planning Tool provides a framework for completing the system architecture design. Once the user requirements and architecture solution are configured, the CPT completes the system architecture design loads analysis to identify network bandwidth and the platform target state design solution.

Once you have completed your System Architecture Design and identified your target architecture solution, suggested guidance for deploying Enterprise design solutions are provided for each of the following implementation phases.

  • Opportunities and Solutions identify the architecture deployment roadmap that will deliver continuous business value.
  • Migration planning identifies the optimum deployment strategy for maintaining existing operations while upgrading operations to the target state.
  • Implementation governance establishes oversight and monitoring required to manage successful deployment migration to the target state.
  • Architecture change control establishes procedures to maintain successful operations through the migration to the final operational target state.
  • Requirements management ensures procedures are in place and followed to successfully execute the migration strategy.

The primary TOGAF Architecture Development Method (ADM) is described in Part-II of the TOGAF®9.1 online documentation.

Best practice: The optimum deployment approach will depend on your specific Enterprise design and business operations complexity.


Pre-design efforts

Figure 12.4 Business needs establish the foundation for any enterprise GIS design. The enterprise vision, existing business architecture, and user requirements must be understood to select the best GIS solution.

Figure 12.4 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 12.5 GIS technology has evolved to support a broad integrated range of business needs across the organization. Each GIS technology pattern is optimized to address specific organizational needs.

Figure 12.5 shows an overview of the ArcGIS technology patterns. GIS enterprise vision looks at how GIS technology can best support your business needs. ArcGIS 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:

  • Asset management
  • Planning and analysis
  • Field mobility
  • 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.


Existing Business Architecture

Figure 12.6 Business architecture defines the current state of how you are meeting your business requirements.
This includes a review of your platform and network architecture, governance and political landscape, types of user communities, operational constraints and priorities, and existing funding constraints. This is information that can be leveraged to identify a GIS design solution that builds on your current business operations.

Governance and political landscape

Organizations often develop policies and standards that support their software and hardware investment decisions. A review of management preferences and associated vendor relationships will provide insight into a design solution that can be supported best by the organization.

Meet with the GIS and IT managers to review any policies or preferences they may have for the design. Major system upgrades often provide a chance for reviewing new platform technology directions, and management may want to include specific alternative technology patterns they are considering in the design effort.

Use the right language

It is important to recognize and use the proper terminology when discussing design issues.

Best practice: Take time to listen.

Successful design consulting requires some communication skills.

  • Often the language used by the technical staff is very different than what is used by the user community.
  • Performance and user productivity is often viewed differently by the IT staff and the user community.
  • Technology is changing rapidly, along with the words that are used to describe system loads, architecture patterns, system performance and capacity needs.
  • Words that are used to describe GIS technology patterns change and many design concepts are not well understood.
Best practice: The words you use, how you listen, and how you speak establishes your credibility with both the user community and the technical IT staff. Credibility is very important in leading a mixed group of business users, technical architects, and system administrators toward a proper design decision.

Platform and network environments

The current IT environment can provide insight into administrative staff experience and policies in working with available technology. 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.

Best practice: Proposed GIS design solutions should take advantage of corporate experience gained from working with the established platform and network environment.

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 availability requirements

Most enterprise operations include several additional platform requirements in addition to their production environment.

  • Development and test platforms
  • Staging platforms
  • Redundant maintenance and publishing database environments
  • Possible remote backup data center
  • Possible cloud collaboration and publishing services
Warning: All business requirements and priorities are not the same, and it is important to listen and understand what is important in making the final design recommendations.
Security requirements

Identify the level of security governing the current business operations

  • Basic - no sensitive data.
  • Standard - moderate consequences for data loss or integrity
  • Advanced - sensitive data

What security standards are currently in place?

  • Published Web services standards
  • Data production and distribution access standards
  • Access protection for Web application servers and data sources.
Performance requirements

Identify any performance concerns being addressed by the new design

  • User productivity
  • Remote access
  • Public web services
  • Geoprocessing timelines
  • Batch process timelines
Best practice: High availability, redundancy, security, and special performance considerations drive requirements for increased hardware and software costs. Recommendations should be backed up with facts to support proper cost and benefit analysis.
Funding constraints

Recommended solutions must fit within reasonable organizational funding constraints or they will not be accepted.

Warning: 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.


Maintain a current plan

Figure 12.7 GIS planning should be updated annually and integrated into your overall enterprise business planning process.

Figure 12.7 emphasizes the importance of maintaining a current GIS plan.

Planning is critical for:

  • Providing a framework for enterprise GIS implementation.
  • Ensuring upper management support for required GIS investments.
  • Managing the evolution of 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.
Best practice: Enterprise GIS planning is an ongoing process, and should be updated on an annual basis to keep pace with technology.


Figure 12.8 CPT can be very useful tool for representing your enterprise GIS operations.

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.

Figure 12.8 shows the CPT Design, a snapshot of a GIS plan identifying user needs, site locations, peak system loads, and platform solution for a specific target architecture (point in time). Changes in user workflow requirements will adjust loads on the selected platform solution. Changes in the platform architecture will identify expected performance improvements and system capacity. The CPT is a simple analysis tool that is easy to change and understand. The CPT provides an adaptive design model representing your GIS enterprise environment.

Best practice: The Capacity Planning Tool provides simple to use framework for GIS system design analysis and planning.


System architecture design

Figure 12.9 System architecture design provides the foundation for building a successful GIS.

Figure 12.9 shows the system architecture design process. 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.
Best practice: Infrastructure requirements should always be understood and considered before making a final software technology selection.


System Design Process

Figure 12.10 System Architecture Design process provides a logical step by step methodology for using the CPT to complete your System Architecture Design.

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


System Architecture Deployment Strategy

Figure 12.11 A phased system deployment strategy includes prototype development testing, initial production roll-out and final production roll-out on an established implementation schedule that enforces system configuration control.

Planning is the first step in supporting a successful system deployment. A system design team should review current GIS and hardware system technology, review user requirements, and establish a system architecture design based on user workflow needs. A deployment schedule, as shown in Figure 12.11, should be developed to identify overall implementation objectives.

Phased implementation strategies can significantly reduce implementation risk. Computer technology continues to evolve at a remarkable pace. Integration standards are constantly changing with technology and, at times, may not be ready to support immediate system deployment needs. New ideas are introduced into the market place every day, and a relatively small number of these ideas develop into dependable long-term product solutions. The following best practices are recommended to support a successful enterprise GIS implementation.


System deployment phases

Pilot Phase

  • Represent all critical hardware components planned for the final system solution.
  • Use proven low-risk technical solutions to support full implementation.
  • Include test efforts to reduce uncertainty and implementation risk.
  • Qualify hardware solutions for initial production phase.

Initial Production Phase

  • Do not begin until final acceptance of pilot phase.
  • Deploy initial production environment.
  • Use technical solutions qualified during the pilot phase.
  • Demonstrate early success and payoff of the GIS solution.
  • Validate organizational readiness and support capabilities.
  • Validate initial training programs and user operations.
  • Qualify advanced solutions for final implementation.

Final Implementation Phase

  • Do not begin until final acceptance of initial production phase.
  • Plan a phased roll-out with reasonable slack for resolving problems.
  • Use technical solutions qualified during previous phases.
  • Prioritize roll-out timelines to support early success.

Implementation strategies are accelerating with faster technology evolution

  • Production upgrades are scheduled to enable required technology advancement.
  • Product upgrade deployments are integrated into production roll-out schedule when ready.
  • Enterprise GIS environments are upgraded incrementally to meet operational requirements.
  • Functional and performance testing is completed before production roll-out.
  • Configuration control for each upgrade is critical for implementation success.

ArcGIS Enterprise Deployment

Enterprise deployment of ArcGIS setups is now possible starting with the ArcGIS 10.2 release. With enterprise deployment of ArcGIS products, GIS managers or system administrators can efficiently plan for and control ArcGIS installations and updates. Any enterprise deployment tool that supports Windows installation packages (MSI files) can be used to deploy ArcGIS software setups. ArcGIS 10.2 Enterprise Deployment technical paper discusses the enterprise deployment of ArcGIS software setups using Microsoft Systems Management Server (SMS), System Center Configuration Manager (SCCM), and Group Policy.

Virtual Desktop and Server Technology

Figure 12.12 Virtual server deployments provide options for adaptive virtual desktop environments for development, controlled virtual server environments for testing and staging, and protected high available virtual server environments for production.

Virtual server technology is reducing the cost of managing a rapidly changing IT environment. Figure 12.12 identifies a deployment strategy taking advantage of virtual server technology. Many ESRI development and testing operations are currently supported in virtual desktop or virtual server environments. Vendors are improving management and performance monitoring of virtual server environments, and it is becoming more practical to manage and deploy production environments in virtual server deployments. A majority of GIS operations are being deployed today with virtual server environments.

Platform virtualization technology provides IT managers with a way to abstract the installed platform software environment from the physical platform hardware. There are two fundamental levels of virtualization, one being virtual desktop environments hosted within a physical platform operating system that interfaces with the physical platform hardware and the other being a virtual server environment hosted on a hyper-visor layer that interfaces with the assigned physical platform hardware. In both cases, the virtual desktop or server contains its own dedicated operating system and software install separate from other virtual systems deployed on the same hardware.

There are many recognized benefits with virtual desktop/server deployments.

  • The benefits include faster provisioning times, physical server platform consolidation, fast recovery from system failures, simplified production delivery and recovery, and optimum configuration control. All of these benefits directly contribute to lower overall systems management costs and a more stable operating environment.
  • The disadvantages include additional software cost and some performance overhead. There may also be functional limitations (limited access to hardware graphic cards and performance monitoring software) which in many cases can be managed with the proper deployment selections.

The real need for more rapid adaptive deployment schedules (to keep pace with changing technology) which also must be coupled with more stable production deployments (reduced production downtime and more rapid failure recover) drive the need for virtual platform environments - virtualization is one solution that addresses some real IT management needs.

The potential disadvantages can be managed by proper deployment strategies. The performance overhead for virtual desktop environments is much higher than for server environments, and for this reason virtual desktops are normally limited to software development environments where performance and scalability is not a critical factor.

Server consolidation benefits can be leveraged in a Staging environment, were multiple release candidates can undergo test and validation in preparation for production deployment. Several production release candidates can be testing in parallel on the same physical server platform.

Production deployment can benefit from deploying an existing virtual server install (Staging configuration that has completed final test and acceptance) to a higher capacity production physical server by simply moving the Staging server release to the production platform. If there is a production failure identified after deployment; it is a simple process to move the production environment back to the previous release. Deploying virtual server staging environments to a physical server production environment is also a viable option - ensuring optimum performance and scalability for the production environment. Virtual server migration software is available to accomplish these provisioning tasks during live operations with no production downtime.

Virtual server performance impacts will depend on the workflow environment, and can vary between 10 - 40 percent (and sometimes higher) in the most efficient virtual server configurations. Hardware platform performance has improved over 80 percent within the past two years, which more than overcomes the virtual server processing overhead. The new servers also provide higher capacity (discussed in chapter 9), which opens the door wider for server consolidation benefits.

Virtual server deployments appear to be moving to mainstream IT production environment. The big question is no longer whether it makes sense to deploy on virtual servers, but rather when and which software vendor solution will provide the highest return on investment.

Technology Product Life Cycle

Figure 12.13 Software technology life cycle represents the risk facing current GIS managers. Buying too early can cost more, and buying too late impacts user productivity.

Figure 12.13 provides an overview of the technology product life cycle, from initial introduction of a new idea (product innovation) through end of life. Technology is changing faster every year, and managing technology change within a production environment is a challenge for GIS managers and IT administrators.

We are seeing an increasing number of new ideas introduced into the marketplace, with each idea promising improved user productivity and simplified system administration. These new ideas must integrate with existing systems that are constantly changing, and initial implementation can be painful.

Some of these ideas deliver on their promises, and in time they provide significant productivity advantages and reduce overall cost of administration. Soon a new idea comes along that performs better at reduced cost, and organizations must move on to new frontiers leaving legacy systems behind.

Selecting the right technology at the right time will optimize business performance. Introducing new technology before it is ready for prime time can reduce productivity and increase implementation cost. Delaying too long can result in missed opportunities. Getting the timing right promotes success.

System Testing

Conducting proper testing at the right time can contribute to implementation success. Functional component and system integration testing should be conducted for new technology during prototype development and before introduction into production. The primary focus during this testing is to make sure everything works. Performance targets established during the initial system design can be evaluated during early testing, paying close attention to map display performance and layer complexity (see Chapter 3 Software Performance). This is an opportunity to evaluate workflow functions and reduce processing overhead.

Enterprise system environments are becoming more complex. Testing should be conducted in a production software environment (same operating system, service pacts, software architecture, etc). Configuration challenges such as firewall access, security, and high availability should be configured and tested before deployment. Development and test environments should be established to represent the complete software configuration for each production release cycle.

Functional Testing

Figure 12.14 Formal functional testing should be completed before any system upgrades are introduced into a production environment.

Figure 12.14 identifies best practices for planning and conducting functional system testing. Conducting proper testing at the right time can contribute to implementation success. Functional component and system integration testing should be conducted for new technology during prototype development and before introduction into production.

A test plan should be developed with clearly defined test requirements, establish configuration control (software versions, operating system environment), and provide test procedures. Testing should be completed before production deployment. Testing should be conducted using the software versions and operating system that will be deployed in the production environment.

Test planning:

  • Complete a risk analysis: Identify new functionality that requires testing.
  • Identify test objectives and establish configuration control plan.
  • Identify test hardware and software configuration.
  • Develop test procedures.

Test implementation:

  • Identify implementation team and establish implementation schedule.
  • Order hardware and software and publish installation plan.
  • Conduct test plan and validate functional acceptance.
  • Collect test performance parameters (CPU, memory, network traffic, etc.).

Test results and documentation:

  • Document the results of the testing.
    • Include specific hardware, software, and network components that were tested.
    • Include installation and test procedures that were followed, test anomalies, and final resolution.
    • Complete test compliance matrix identifying validation of functional requirements.
  • Publish the test results and make available for reference during system implementation.
Best practice:
  • Complete prototype integration testing before production deployment.
  • Test in a production environment (configuration control).
  • Document functional requirements and test procedures.


Performance Testing

System test is a free desktop application from Esri that enables GIS administrators and users to quickly and easily create functional and load testing procedures within a GIS environment.

Figure 12.15 Performance testing should be conducted throughout system design, deployment, and during production and should always follow the scientific method.

Figure 12.15 identifies some best practices associated with system performance testing.

Performance testing can be expensive and the results misleading. Normally initial system deployments need to be tuned and optimized to achieve final performance goals. Often system performance bottlenecks are identified and resolved during initial deployment. Early application development focuses primarily on functional requirements, and performance tuning is not complete until the final release. Actual user workflow environments are difficult to simulate, and test environments seldom replicate normal enterprise operations.

The scientific method introduced with grade school science fair projects provides some fundamental best practices that directly apply to system performance testing. Performance testing should only be conducted to validate a hypothesis (something you think you know). The primary objective of a performance test is to validate the hypothesis (confirm what you know). The test is a success only if it proves the hypothesis (testing does not teach you what you don't know).

Initial performance testing often fails to support the test hypothesis. With further analysis and investigation, test bottlenecks and/or improper assumptions are identified that change the test results. Performance testing is only successful if it validates the test hypothesis. A scientific approach to testing (Scientific Method) can help develop a true interpretation of the technology. Technology is changing with each service pack release, and this requires an open mind and willingness to continually change what we believe to be true.

System performance testing is best conducted during the initial production deployment. During this phase, real users doing real workflows can generate a real user environment. Critical system components should be monitored during the initial deployment to identify processing bottlenecks and resolve system conflicts. Compliance with design performance targets can be validated by observing system throughput and utilization during initial user operations. Initial deployment acceptance should include validation that user workflow performance goals are met.

Systems Integration Management

Figure 12.16 Project schedule should be developed to identify implementation milestones and schedule dependencies.

Basic project management practices promote implementation success. Project teams should be established, individuals should be assigned specific responsibilities, a task plan should be developed to support implementation planning, a configuration control plan and change control process should be established, and an implementation schedule should be published to support project deployment milestones.

A system architecture design can provide the framework for establishing an implementation plan. The implementation plan should be developed after final selection of the hardware vendor solution. Figure 12.16 provides a typical system deployment schedule. Specific decision milestones should be included in the schedule and each major task effort clearly identified.

An implementation project manager should be assigned to make sure all tasks are well-defined, and every participant has a clear understanding of his/her responsibilities. A clear set of acceptance criteria should be developed for each implementation task and a formal acceptance process followed to ensure integration issues are identified and resolved at the earliest opportunity.

The capacity planning tool can be used by project managers to establish performance milestones and validate performance targets are met throughout deployment. Peak users can be identified for different project milestones, and system throughput and server utilization can be reported at each milestone to demonstrate performance goals are met.

Performance Monitoring

Performance validation tools were discussed in Chapter 3 (ArcGIS for Server analyze and preview map optimization tools and the mxdperfstat performance monitoring tools). The system performance terms discussed in Chapter 10, particularly the relationship between throughput (peak users or peak transaction rates) and utilization (server CPU or network bandwidth utilization), can identify if the deployed solution is performing within the initial project performance milestone.

Monitoring live performance metrics can provide excellent validation that the system environment is designed to support peak throughput loads. The challenge is to collect appropriate throughput and utilization metrics that represent actual business workflow loads (what are the current system loads).

The ArcGIS for Server statistics tab was a very useful tool for evaluating service usage time on a live active ArcGIS Server platform. This tool is no longer included in the new ArcGIS 10.1 Server Manager. The ArcGIS 10.1 Help provides an example script that can be used to derive map service statistics from the ArcGIS Server logs. The FINE grain ArcGIS Server statistics track which services are drawn and how long the draws take. The example script queries the logs and writes statistics on map service activity during the sample period. Results can be opened in Excel for final review and analysis.

Department (Business) managers can often identify the percentage of peak user loads (throughput) generated on the system during high volume events – these are the same high volume events that drive staffing and business planning needs. System performance monitoring tools can measure and report platform CPU utilization and network traffic during these high volume events. The problem is that business management and IT administration staff seldom share these metrics. These live performance measures are the most accurate resource for understanding whether the existing system environment has the capacity to meet expected peak system loads.

Several third party products are available for system tuning and Web load testing. The ArcGIS Enterprise Systems: Performance and Scalability presentation by our Enterprise test team shares our system tuning and testing experience and best practices. The ArcGIS for Server Performance and Scalability - Optimizing GIS Services presentation provides several tips on configuring GIS applications and data sources for optimum performance.

ArcGIS Monitor provides a tool uniquely tailored to monitor the health of ArcGIS implementations. ArcGIS Monitor provides insightful information about system usage and performance via noninvasive monitoring of enterprise GIS and IT infrastructure including databases, networks, and GIS software. The solution provides timely detection of potential and existing system infrastructure and operational problems to facilitate a rapid resolution. It also provides actionable reports and quantifiable metrics to improve communications among GIS and IT staff, business owners, and senior management.

Additional ArcGIS Server system administration monitoring applications are shared on the ArcGIS Resource center.

  • Popular Extents. This application plots extents requested from a map service as graphics in a JavaScript application. By extracting log records from the ArcGIS Server Administrator API in this manner, you can make more informed decisions about which areas of your maps are most widely used.
  • Services Dashboard. This application displays statistics usage for a service, such as the number of service instances in use, average response time, and the total number of errors, warnings, and successes that are logged. The Services Dashboard can be used to more closely monitor the current state of your service and help you make more informed decisions about its use.


Performance Validation

Figure 12.17 Monitoring performance compliance throughout development (map publishing), initial deployment, and in production can reduce implementation risk.

Figure 12.17 shows the importance of establishing performance milestones and validating performance during implementation. 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. The CPT test tab is designed to translate throughput and utilization measurements to workflow service times that can be compared directly to the initial project workflow performance targets. 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 - less layers or generalize layers with large number of features, reduce number of current batch jobs during peak system loads, evaluate preprocessing alternatives (map cache, generalized geodatabase layers, etc). Chapter 3 identified a variety of ways to improve GIS display performance. Identifying and resolving performance issues before they become production level performance problems will promote deployment success.

System Tuning

Figure 12.18 System performance tuning is a way to get the most out of your system investment. The weakest system component (chain link) will limit system performance. Make sure each component is pulling its own weight.

System tuning is a critical part of final system integration and deployment. Initial system deployment is the first opportunity to begin performance tuning. Heavy batch processing efforts should be identified and separated from interactive user workflows and supported through a separate batch process queue. System backups and heavy processing workloads should be scheduled during off-peak workflow periods.

System component performance metrics should be monitored on a periodic basis particularly during peak workflow periods to identify performance bottlenecks and address system deficiencies. Figure 12.18 provides an overview of the components supporting an enterprise GIS environment. Any component has the potential to introduce a weak link in the overall system performance equation.

Managing Technology Change

Figure 12.19 Managing technology change is the biggest challenge for any GIS Manager. Building a GIS is an iterative process requiring planning, test, and evaluation through each and every annual business cycle.

Enterprise GIS operations require a combination of strategic planning and a continued investment in technology. Technology is changing very rapidly, and organizations that fail to manage this change fall behind in productivity and overall cost management. Managing technology change is a major IT challenge. Figure 12.19 identifies a conceptual system architecture planning and deployment strategy for technology change management.

Enterprise operations should include a periodic cycle of coordinated production system updates.

  • Planning, test, and technology validation should occur one periodic cycle ahead of each production deployment.
  • Production deployment efforts should be coordinated to support operational technology needs.

Planning, test, and validation:

  • Planning activities should be established on a periodic cycle.
  • Coordinated to support the organization's operational and budget planning needs.
  • Strategic plans should be updated to support a multiyear deployment strategy and published periodically (normally on an annual cycle).

The planning and evaluation process should include:

  • A requirements evaluation (strategic plan update).
  • Technology refresh (training and research).
  • Requirements analysis (process and requirements review).
  • Test and evaluation (evaluate new technology alternatives).
  • Prototype validation (pilot test programs).
Best practice: Efforts should be scheduled to support the annual system deployment upgrade cycle.

System deployment:

  • Operational system upgrades should be planned on a periodic cycle.
  • Scheduled to implement validated operational enhancements from the planning and evaluation program.
  • System deployment phases should include initial implementation (implementing changes in an operational test environment) to support deployment authorization.
  • The program should also include planned schedules for new technology procurement and deployment on a periodic schedule (in some cases deployment upgrades can be implemented on a monthly or quarterly basis).
  • All production system upgrades should be planned and scheduled with full support for ongoing operations.

Conclusion

Successful implementation depends on a good solid design, appropriate hardware and software product selection, successful systems integration, and careful incremental evaluation during installation. A phased approach to implementation reduces project risk and promotes success, providing the opportunity for early success and flexibility to incorporate new technology at low risk prior to final system delivery.

Guidelines are available to support a successful system design, even for large complex systems. Final purchase decisions are influenced by both operational requirements and budget limitations, introducing unique challenges for system design. Good leadership, qualified staff, and proven standard practices support successful deployments.

Previous Editions

System Implementation 41st Edition
System Implementation 40th Edition
System Implementation 39th Edition
System Implementation 38th Edition
System Implementation 37th Edition
System Implementation 36th Edition
System Implementation 35th Edition
System Implementation 34th Edition
System Implementation 33rd Edition
System Implementation 32nd Edition
System Implementation 31st Edition
System Implementation 30th Edition
System Implementation 29th Edition
System Implementation 28th Edition
System Implementation 27th Edition

System Design Strategies (select here for table of contents)
System Design Strategies 42nd Edition (Spring 2018)
1. System Design Process 42nd Edition 2. GIS Software Technology 42nd Edition 3. Software Performance 42nd Edition 4. Server Software Performance 42nd Edition
5. GIS Data Administration 42nd Edition 6. Network Communications 42nd Edition 7. Platform Performance 42nd Edition 8. Information Security 42nd Edition
9. GIS Product Architecture 42nd Edition 10. Performance Management 42nd Edition 11. City of Rome 42nd Edition 12. System Implementation 42nd Edition
A1. Capacity Planning Tool 42st Edition B1. Windows Memory Management 42nd Edition Preface (Executive Summary) 42nd Edition SDSwiki What's New 42nd Edition

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