Often, a gap lies between application development and the technical implementation on its hosted infrastructure. Successful integration of the application and its related infrastructure can:

• Increase the quality of Web implementations and launches.
• Proactively eliminate problems which can typically accompany a disjointed effort (an effort in which application development concludes without full incorporation into its infrastructure environment).

Proactive evaluations optimize stability, ease operation, and validate that the chosen host architecture will support the stated business objectives of the implementation. With these goals in mind, this article offers an assessment that can help you ensure smooth application boarding and delivery.

The following list is the basis of that assessment. It outlines 20 investigation areas and related tasks that can enable a successful technical analysis of Web applications. This list was developed by members of the Special Events Team in IBM Global Services as they performed Web-hosting assessments of customers' e-business infrastructures. The first 5 investigation areas focus on data gathering, while the remaining 15 areas are recommendations.

I. Data gathering:

• A. Business requirements
• B. Infrastructure components
• C. Historical performance data
• D. Application architecture
• E. Network traffic flows

II. Recommendations:

• F. Server health
• G. Software levels
• H. Database- and application-access methods
• I. Infrastructure and application redundancy
• J. Infrastructure and application scalability
• K. Infrastructure security
• L. Application security
• M. Backup and recovery
• N. User application function tests
• O. Non-production environments and promote-production procedures
• P. Application and content-change management
• Q. Content-publishing processes
• R. Traffic projections
• S. Monitoring systems
• T. Content-shedding plans

Project managers can incorporate the list into project plans. Application developers can design for the hosting infrastructure as they consider these focus areas. Hosting architects can use the list to audit solutions and ensure all needs are addressed. Ideas are revealed from best practices and proven methodologies.

Let's look at these ideas in greater detail.

I. Data gathering

The first steps to performing an assessment is to gather data and determine what elements are currently in use, how it all fits together, and how it synchronizes to deliver according to defined business requirements.

Let's look at a breakdown of the first five assessment areas. (I'll detail each assessment area by defining the goal of the specific area and then providing a list of concerns in that area to focus on to help achieve the goal.)

A. Business requirements

Goal: Define expectations for the e-business application and environment. Rank the business requirements that set the standards to measure success.

Focus areas:

• Business goals and environments related to applications with critical dates. Measurements of success of the Web sites, including number of customers served, revenue, savings, and so forth, along with growth projections.
• Application growth targets for new functionality.
• Critical data.
• Volume projections and target timeframes.
• Web site availability requirements and identification of mission-critical components.
• Scalability. Describe approach and requirements to enlarging the environment to accommodate expected growth.
• Site evolution plans with dates.
• Applications functionality and dependencies.
• Content -- types, volume, and update frequency requirements.
• Servers/architecture requirements:
• Load balancing
• High availability
• Redundancy
• Geographical diversity requirements.
• Scalability based on more detailed growth projections.
• Approach to capacity planning.
• Database.
• Operational support and availability requirements.
• Security.
• Backup and restore.
• Disaster recovery.
• Testing, modeling, production readiness requirements, and production launch date.
• Change management.
• Customer care and help desk.
• Monitoring and reporting requirements and expectations.
• Any key policies or procedures which govern site development or implementation requirements.
• Open issues.

B. Infrastructure components

Goal: Fully determine what exists today within the environment; this is usually done using a whiteboard. Gather relevant individuals in a room, draw the various components, and show how the components communicate by adding lines.

Focus areas:

• Server hardware
• Server operating components and configurations
• Middleware and other software components
• Communication paths and protocols used
• Monitoring tools and processes
• Build sheets:
• Physical layout
• Connectivity drawings
• Network diagrams
• Bandwidth capacity
• Internet providers
• Peering points (shared infrastructure) and capacity
• Routing paths and methods
• Remote access points (VPN) and communication methods

C. Historical performance data

Goal: Create a baseline of site performance, both today and in the past. Several tools like Analog and IBM's SurfAid Analytics are available to generate graphs and reports from Web-access logs. rrdtool is also a great tool to save performance-related data and create graphs on the fly from servers and network gear.

Focus areas:

• Month-to-month server performance (such issues as CPU, memory, disk utilization, file system growth, database utilization).
• Response times of the Web site (Keynote, SurfAid, Gomez, end-end, server-server, unique users).
• Page Detailer report -- shows decomposition of the Web page into its component parts (HTML, GIFs, Applets) and the activities involved in retrieving them. Where is request spending most of its time?
• Cachebility check -- determines if content is a good fit for the caching solution, like the Content Serving Utility.
• What is the acceptable download time for a page?
• Stress testing -- Web Performance Tools is a set of applications that allows stress-testing of a Web server, a Web site, or a Web application.

D. Application architecture

Goal: Understand how the application behaves, how it performs, and associated data flows.

Focus areas:

• Data structures
• Directory structures (Place similar content together)
• Data flows among application components
• Application dependencies
• Backend connections
• Packaged applications versus custom applications

E. Network traffic flows

Goal: Understand network architecture, connections, and routing, and ensure sufficient capacity exists.

Focus areas:

• WAN network components and service providers:
• Router equipment and IP addresses
• Routing protocols
• Available bandwidth and current utilization
• Remote access points and usage (such as Frame Relay, Dedicated Frame Relate, ISDN, or PPP)
• Firewall components and throughput
• Load-balancing capabilities
• Redundancy and failover capabilities of network architecture
• LAN network components:
• Switches and bridges installed (Note vendor and models)
• Broadcast and collision domains
• Network traffic loads
• Network segments (Are too many machines on a given area of the network?)
• VLAN architecture
• IP address scheme (Is current address space wasted or under-utilized?)
• Protocols utilized over LAN segments
• Network processes and procedures

Back to top

II. Recommendations

The second step, now, is to analyze the information gathered and build a list of recommendations. These recommendations should be a combination of both short-term fixes and long-term goals.

The remaining 15 steps provide insight into vital areas for reviewing and building the list of changes. The end result is to successfully integrate an application and its related infrastructure. We consider an e-business environment "ready for prime time" once attention has been given to each area.

F. Server health

Goal: Identify areas that will improve application performance, security, and reliability.

Focus areas:

• Configuration files (server health)
• Correct time and time zone settings (health)
• Error and message logs (health)
• Log file cleanup (health)
• Critical processes, running and monitored (health). Spong is a simple, Perl-based monitoring package
• Scheduled batch jobs documented and running (health)
• Tuning parameters (server performance)
• Network and TCP/IP settings (performance)
• System limits (performance)
• Paging and swap space usage and size (performance)
• Data layout across disk drives (performance)
• Performance gathering scripts, graphing, and trend analysis (performance)

G. Software levels

Goal: Determine software levels, and exposure to defects and security holes by comparing to current available levels. Determine interoperability or not supported issues between versions and other software used.

Focus areas:

• OS-level and patches applied versus current available levels
• Microcode/BIOS levels on hardware versus current available levels
• Code in use that is no longer at supported levels
• Bug fixes that would be beneficial
• Hardware and software compatibility
• Effect upgrading might have on custom application code
• Alternate products that might better serve business goals

H. Database- and application-access methods

Goal: Determine whether data storage locations and access mechanisms support requirements for response times, concurrent users, transactions per minute, and security. Quest Software has numerous tools to assist in database analysis.

Focus areas:

• Total quantity of data stored
• Types of data stored (audio, video, numeric, character, images, and others)
• Frequency of updates and requests (total transactions per minute)
• Average size of data objects transferred during a transaction
• Applications that require read only, write only, or read and write access to data store
• Connection to data store by application:
• JDBC, ODBC, OLE DB, SQLnet, and others
• Connection pools
• Potential bottlenecks in the data-flow layer
• Indexing
• Deadlocks
• Connection limits between components
• Bandwidth requirements

I. Infrastructure and application redundancy

Goal: Ensure that redundancy in the system is suitable for application reliability and availability requirements.

Focus areas:

• Fail-over-plans for each component if it is lost
• Facility and power:
• Emergency power (UPS)
• Generator
• Handle outages and surges
• Servers:
• Dual power supplies
• High availability and load balancing
• Disk mirroring, RAID, or enterprise storage solutions
• Application components:
• High availability and load balancing
• Dual communication paths
• Network:
• Dual ISP
• Multiple firewalls
• Multiple intrusion-detection devices
• Multiple paths from ISP to servers
• Dual site:
• Plans if site is lost
• Five nines (the Web site was available 99.999% of the time) availability through multiple hosting sites

J. Infrastructure and application scalability

Goal: Determine if the application has a scalable design. Locate dependencies on a single path and the inhibitors to configuring clusters. A teriffic Redbook, "WebSphere V5.0 Applications: Ensuring High Performance and Scalability," discusses scalability as it relates to WebSphere. You can apply concepts in this book to many aspects of a Web environment.

Focus areas:

1. Application's ability to use clusters or multiple paths
2. Ability to maintain session state across paths
3. Dependency on one database for all Web and application servers
4. Load balancing possible configurations allowed by application design
5. Credentials follow user (Multiple paths used based on the means of authenticating a user)
6. Content synchronization and propagation
7. Monitoring the ability of tools to recognize failure and mark corresponding path
8. Application's ability to utilize additional hardware without modification
9. Fail-over capabilities (Can it be transparent to the user?)
10. Application fault tolerance
11. Vertical scalability options (fewer but larger servers) versus horizontal scalability (more servers) versus server consolidation
12. Best technique to increase capacity based on how the application scales:
• Faster hardware
• Create cluster of machines
• Appliance servers
• Segmented workload
• Request batching
• User data aggregation
• Connection management
• Caching

K. Infrastructure security

Goal: Understand current security posture and identify key areas that need addressing.

Focus areas:

1. Firewall policies and architecture
2. Host- and network-based intrusion detection programs like Snort, the open source network-intrusion detection system
3. New, reset, strength, aging, and other password controls
4. Vulnerability alerts and patching process
5. Settings, retention, protection, use-of-logging servers, and other log-management issues
6. Confidential data protection
7. Tripwire or similar product to ensure file system integrity
8. Encryption
9. Anti-virus and anti-Trojan sofware
10. Removable media
11. Extranets and B2B issues
12. Vulnerability monitoring (CERT advisories)
13. Session timeouts
14. DOS detection
15. Log reviews:
• Firewall
• IDS
• HTTP
• Syslo
• Window event log
• Router logs

L. Application security

Goal: Understand security requirements of the application, how they compare to the security of the infrastructure, and the current security components implemented in the application. Identify missing security components within the application and the security vulnerabilities. (Items 1-15 apply to application code; items 16-19 apply to authentication; items 20-21 apply to authorization.)

Focus areas:

1. Strip metacharacters
2. Avoid explicit pathnames
3. Input validation
4. Secure programming practices
5. Plain text passwords in config files
6. setuid/setgid
7. chroot
8. Privilege dropping
9. Source code auditing
10. Read/write files
11. IPC
12. Wrappers
13. Server-side includes
14. Penetration testing
15. E-commerce protection
16. Global sign-on products such as Tivoli Access Manager
17. Password never seen by application (Tivoli Access Manager and Trust Associations)
18. Certificates versus passwords
19. ID creation, management, and deletion
20. Single silo (LDAP) for authorization information
21. Role creation, management, and deletion

M. Backup and recovery

Goal: Determine if backup and restore architecture meets business requirements.

Focus areas:

1. Data that requires backups (sizing)
2. Percent of data that changes daily
3. Amount of time given for the backup
4. Backup architecture
5. Requirements for restore
6. Retention requirements
7. Off-site storage requirements
8. Tape rotation and life policies
9. Ability to restore database and files back to a point in time using a product like IBM Tivoli Storage Manager

N. User application function tests

Goal: Develop a baseline of how the application functions relative to documentation. Identify response times, errors, and nonfunctional components. Understand what is not functional today so that future enhancements to the environment made as a result of this assessment are not blamed.

Focus areas:

1. Identify critical functions within the application.
2. Validate that interactions behave as designed and note those that do not.

O. Non-production environments and promote-to-production procedures

Goal: Evaluate the suitability of current non-production environments used to develop, test, and stage the application. Identify areas where these environments are not supporting a smooth promote-to-production process. Also, evaluate procedures for moving the application through these environments on the way to production.

Focus areas:

1. Current development and testing environments.
2. Software and hardware configurations and communication between the environments.
3. Usage and performance of these environments.
4. Procedures related to use of environments.
5. Staging adequately resembles production.
6. Additional hardware and software needed.
7. Is the environment be used for stress testing the application the same hardware and software configuration as production?

P. Application and content-change management

Goal: Identify weaknesses in the documented and undocumented change-management plans for hardware, software, and data associated with the application. (Note: Items 1-6 deal with procedures and policies; items 7-10 deal with the communication flow process; items 11-13 deal with the existing change-management situation; items 14-18 deal with application-level logistics; and items 19-21 deal with the promote to production process.)

Focus areas:

1. Change severity criteria
2. Emergency change criteria
3. Change windows
4. Approval and exception requirements
5. Notification lists and criteria
6. Change-management software used and versions
7. Processes used for inter-group and team communication
8. Communication of change-management systems with other systems (such as problem-management systems in call centers)
9. Follow up procedures for successful and failed changes
10. Mechanisms, processes, and policies for documentation updates following changes
11. Existing change records show policies and procedures are being followed
12. Approval process shows approvals are requested from relevant parts
13. Problem records indicate problems with change-management policies or procedures (such as user was unaware of a change or had problems because of a change)
14. Current or acceptable number of versions to retain
15. Legal factors that drive time-dependent retention
16. Version control systems used (like RCS, CVS)
17. Integration with license-management systems or other software-control systems
18. Periodic testing of versioning and rollback is performed
19. Change-control procedures in all steps of promote to production process
20. Testing procedures as changes move through this process
21. Lock mechanisms and identify problems in concurrent development scenarios

Q. Content-publishing processes

Goal: Identify types of content published along with volume, frequency, and timeliness requirements. Identify source, path, and destination for all published processes and what triggers publishing.

Focus areas:

1. Content types:
• Static versus dynamic
• Database
• Servlets and ASP pages
• Server-side includes
• CGIs
2. Average size of content type being published
3. Critical and non-critical content
4. Protocols used during publishing
5. Source and destination locations
6. Network segments used
7. Software used to publish (Needs to keep content syncronized across servers)
8. Primary and secondary publishing paths for critical-content publishing
9. Monitoring of the publishing process
10. Triggers used to switch publishing paths
11. Plans for publishing outages
12. Frequency (monthly, daily, hourly, every minute, less than a minute)
13. Size (terabytes, megabytes, kilobytes, less than a kilobyte)

R. Traffic projections

Goal: Predict traffic growth and patterns for the application; determine the scalability requirements based on these projections.

Focus areas:

1. Growth this year versus last:
• Page views
• Bytes per second
• Unique visitors
2. Comparisons:
• Per day (Increase over corresponding day in previous year)
• Monthly total (Increase over corresponding month in previous year)
• Peak (Increase in peak daily traffic this year versus last year)
• Spikes (Increase in spikes measured in intervals of an hour or less)
• Multi-year (Increase counted over more than a single year)
3. Identify growth in similar applications
4. Advertising and other impacting factors
5. Project numbers for initial deployment and year growth percentages
6. Scheduled special events

S. Monitoring systems

Goal: Evaluate monitoring relative to business requirements for uptime, response time, problem resolution time, and security.

Focus areas:

1. Monitors identify root cause.
2. Monitors trigger automatic actions to resolve failure.
3. Ability to disable or acknowledge alerts is present.
4. Ability to correlate events into one alert is present.
5. Ability to adjust thresholds on the fly is present.
6. Escalation paths, auditing requirements, and documents outlining corrective action are in place.
7. The monitoring system itself is monitored for outages. Send a test alert each hour and ensure it is received.
8. Health check servlet probes all components and returns pass or fail.
9. Every component is adequately monitored with appropriate frequency, notifications, and actions.
10. Outside view from services like Keynote or Gomez.

T. Content-shedding plans

Goal: Create content-shedding plan to remove content and reduce the frequency of publishing when denial-of-service, hardware failures, or heavy traffic result in the environment being overloaded and immediate need is required to reduce hits on the site.

Focus areas:

1. Prioritize components that can be removed to improve performance.
2. Adequate monitoring to recognize and trigger content-shedding plans.
3. Maximum supported traffic limits for the site (Maximum database, Web server, and application server connections).
4. Process to shed content.

Back to top

The final check

After your assessment is complete, the next phase is to implement the short-term fixes and long-term goals resulting from your evaluation. Keeping an e-business application and its components running smoothly on the related infrastructure is an ongoing cycle of evaluating and implementing. By following this path, the result is the ever-increasing quality of Web implementations and launches. Successful assessments ensure smooth application boarding and delivery and proactively eliminate problems.

Resources

• Feel free to view or download this printable, text-only version of the checklist items from this article when assessing your e-business infrastructure for Web readiness.
  
  
• Analog 5.31 is the highly configurable Web-log analyzer that shows you the usage patterns on your Web server.
  
  
• IBM's SurfAid Analytics offers custom reporting, new database cubes, integration of non-Web-log data, and user-defined data categorization to ensure meaningful Web analysis.
  
  
• RRDtool is a great tool to save performance-related data and create graphs on the fly from servers and network gear -- it presents useful graphs by processing the data to enforce a certain data density.
  
  
• Page Detailer shows decomposition of the Web page into its component parts (HTML, GIFs, Applets) and the activities involved in retrieving them.
  
  
• IBM Managed Hosting - Performance services offers flexible services that are designed to enable greater Web site responsiveness, availability, and reliability, including load-balancing and content-distribution solutions.
  
  
• alphaWorks offers Web Performance Tools, a set of applications that allows stress-testing of Web servers, sites, and Web applications.
  
  
• Spong is a simple, Perl-based monitoring package designed to help keep critical processes running and securely monitored.
  
  
• Quest Software offers the following tools to assist in database analysis: QDesigner (database and application design); Benchmark Factory (pre-go-live load testing and capacity planning); and DataFactory (application testing).
  
  
• "WebSphere V5.0 Applications: Ensuring High Performance and Scalability" is a great resource that discusses scalability as it relates to WebSphere.
  
  
• Take a look at Snort, the open source network-intrusion detection system that is capable of performing real-time traffic analysis and packet logging on IP networks and can perform protocol analysis, content searching and matching, and can be used to detect a variety of attacks and probes.
  
  
• The CERT advisories are a strong, consistent warning source for system vulnerabilities.
  
  
• Tivoli Access Manager is a policy-based access-control solution for e-business and enterprise applications that lets organizations control both wired and wireless access to applications and data, and provides Single Sign-On (SSO) for authorized users.
  
  
• IBM Tivoli Storage Manager protects your organization's data from hardware failures and other errors by storing backup and archive copies of data on offline storage.
  
  
• For version-control systems, try RCS and CVS.
  
  
• Find out more about the products and services that IBM Global Services can offer.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• I. Data gathering
• II. Recommendations
• The final check
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Web development on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers