Deployment planning: Where to start?

Engineering Lifecycle Management (ELM) deployment has two distinct aspects:

• Technical deployment of ELM products and solutions that includes planning and design; installing, upgrading, and migrating; integrating; configuring and tuning; monitoring; and troubleshooting. Technical deployment results in a ELM development environment that is flexible, scalable, available, resilient, secure, and supportable.

• Organizational deployment, which includes technical deployment, but also includes the business change, adoption, development best practices, enablement, and mentoring needed to improve an organization's development capability.

This topic outlines several key planning and design considerations for designing an ELM environment. These considerations focus on the environment and non-functional options that typically effect how successful your deployment and ultimate adoption will be.

Introduction and approach

One of the questions that customers most frequently ask is:

How should we deploy an enterprise Engineering Lifecycle Management environment that is flexible, scalable, performant, available, resilient, secure and supportable etc.?

Quite rightly, you balk at an answer that only points you to the system requirements or gives you a myriad of permutations along with an ‘it depends’ answer. You want stronger guidance!

While no recipes or approaches guarantee success, this topic and section outline the general approach for planning and designing an ELM environment that meets your requirements. Subsequent topic sections cover specific design considerations.

ELM deployment way forward

• Focus on a few recommended deployment topologies: the guidance and best practice captured in this wiki
• Focus development and testing, particularly system and performance testing, on the recommended topologies
• Reduce permutations that are of little or no business or technical value to customers
• Focus ELM field engagement and best practices on the recommended topologies via presales, services, and support engagements
• Provide one repository for all additional deployment guidance and best practices for customers, partners, and Rational staff: this Deployment wiki!

Vision: Improve your time to value by providing more prescriptive guidance and simplifying the deployment of ELM solutions

Plan and design, deploy, monitor and manage for flexibility, scalability, and performance

1. Design and plan the deployment of your ELM environment against your potential usage model, functional and non-functional requirements, constraints, etc.
2. Build flexibility and scalability into the design and deployment
3. Monitor user and automated usage against ELM application and system performance
4. Manage your environment to meet your changing requirements, constraints, and needs while maintaining adequate performance

The following sections outline key considerations for designing and planning a development environment against this basic approach.

Properly consider and document the real non-functional requirements for your development environment

The following list includes some of the most critical non-functional requirements you must understand and document for a development environment:

• Capacity, performance, and monitoring: Consider common user operations as a bench marks of required performance as well as automated monitoring
• High availability: What is the real availability you need to support your operational systems?
  • Almost no organizations need their software development environments to be 100% available!
• Disaster recovery: What is a reasonable recovery time and how much data can you afford to lose?
• Security: What corporate, industry, compliance or government security standards to you need to adhere to?
• Audit and control: What are your organization, industry, or regulatory requirements?
• Compliance: What industry or regulatory standards to you need to comply with?

Develop a usage model for your ELM environment

Consider short, medium, and long-term. Understand the potential capacity and scalability requirements from the outset so that you can design in flexibility to meet your changing needs.

At a minimum, this model should include this information:

• Your development roles
• Numbers of staff per role
• Staff locations and numbers per role
• Expected usage or process per role

Further, try to estimate the amount of SCM data the environment will need to support, both initially from migrating for previous SCM tools and the rate of growth of data over time.

Estimate your potential usage, but design an environment that can scale to support at least twice the usage

Estimate your potential usage based on a potential usage model.

Use IBM Support and your trusted business partner, technical sales engineineer, and/or professional services person to help you size your environment. IBM Techline provides this assistance:

• IBM server sizing for IBM software and for selected software vendors
• Solution design, configuration, validation and assistance.

Build as much flexibility, scalability, and performance into your design by using these methods:

• Application server virtualization
• Separation of Jazz applications onto separate virtual or physical servers: use an enterprise standard topology
• Database clustering; for example, Oracle RAC and DB2 HADR
• A reverse proxy server that you can use to refactor your environment in the future

Consider using virtualization for flexibility and scalability

Virtualize the application tier, including your reverse proxy server. Database tier flexibility and scalability is best served by database clustering.

Well-managed virtualized servers permit modifying CPU, RAM, and disk image sizes with much greater ease than physical servers.

A virtualized infrastructure can support certain levels of high availability and disaster recovery:

• Monitor the application, application server, and virtual server, and automatically restart if unresponsive
• Cope with single hardware failure; for example, VMware HA and PowerHA
• Failover between data centers; for example, VMware vSphere/vMotion, Platespin.

Principles of good virtualization:

• Manage and monitor virtualization
• Ensure that CPU, memory, and network resources are dedicated and uncapped
• Do not overcommit a virtualization environment

Reuse common managed IT infrastructure services

The infrastructure services you reuse might include the following services:

• Central database service
• Virtualization or cloud environment
• Backup, high-availability, and disaster-recovery services
• Authentication and licensing
• Complete hosting or Platform-as-a-Service offering

Make sure that the Service-Level Agreement (SLA) meets your requirements:

• Typically an SLA is an operational SLA, so it is more than sufficient for a development environment
• Usually, it has a higher quality of service than an individual team can support

Separate infrastructure from tools and methods administration if possible.

Start by making major decisions about platform, operating systems (OS), and middleware

Where possible, choose the middleware and editions that meet your ultimate requirements:

• Reduce the need for major migrations as you scale-up the environment
• Reduce the amount of time you spend re-learning how to tune new middleware or editions

Where possible, choose a platform, OS, and middleware that you already have experience with. Standardize on the same platform, OS, middleware, editions, and versions for the whole of your Rational environment, where possible.

Choose a deployment topology that meets your requirements and that can scale to meet your needs. It is easier to scale-down an enterprise topology/environment than scale-up an evaluation topology.

Plan for multiple instances of specific application servers

Plan for multiple application instances if you think you are going to scale to need them:

• Split teams/projects across multiple instances along organizational boundaries or due to low dependency
• Typically Rational Team Concert and occasionally Rational Quality Manager require multiple instances
• Rule of thumb: A typical instance of the Change and Configuration Management (CCM) application can support 350-400 concurrent users

Each instance requires a separate context root; for example, two instances of the CCM application might be ccm1 and ccm2.

Cross-instance working is supported by Open Services for Lifecycle Collaboration (OSLC) work item linking and distributed SCM.

For more details, see Planning for multiple Jazz application server instances.

Management and improvement are impossible without monitoring

Understand what systems monitoring methods you already perform within your organization and reuse them if appropriate. Monitoring methods might include homegrown tools, 3rd-party packages, or Tivoli monitoring.

A well-managed development environment is monitored. Identify a handful of measures and start capturing them on a regular schedule, either manually or automatically. Consider measuring all of the following information:

• Database: Uptime, database size, log size, index age, time to make backups, size of backups, threads, sockets, and query statistics
• Application server, web server: Uptime, CPU%, JVM size, threads, connections, and memory usage
• Licenses: Number and type used
• Network: Latency, bandwidth, pings, tracert, and packet loss

For more guidance and best practices, see the Monitoring section of the Deployment wiki.

Manage your environment to meet your changing requirements, constraints, and needs while maintaining adequate performance

Actual usage will always differ from the potential usage model you originally captured for an environment:

• Maintain a living usage model to understand how to an environment is used
• Use the system, user, and usage monitoring to inform the living usage model
• Review your design constraints and architectural decisions, and design against the current and new future usage

To avoid an under-performing environment, use the flexibility you built in to scale the environment.

Measure and review whether other non-functional requirements and targets are being met; for example, HA/DR, audit/control and compliance:

* All non-functional requirements must have specific and measurable targets * “The Rational environment must perform”, is not a requirement

Include a reverse proxy

A reverse proxy provides a web server, on a single host, that forwards requests to the Jazz applications.

The benefit of using a reverse proxy is the ability to mask the complexity or changes to the underlying deployment from your end users. You can start with a simpler topology and refactor to a more complex topology later as needed. For more information, see the understanding reverse proxy topic.

You can refactor the physical topology and still maintain links:

• Enhance or replace hardware: scale hardware vertically
• Split Jazz applications onto separate hardware: scale hardware horizontally
• Scale hardware horizontally and vertically

Hardware and software requirements

Before you begin the installation, verify that your hardware and software meet the minimum requirements. A 64-bit operating system and a minimum of 8 GB of server memory provide the best environment for running Jazz Team Server. For a complete list of system requirements for the Rational solution for CLM, the Rational solution for SSE, and their related products, see Installing, upgrading, and migrating section.

Deployment workshops and reviews

A typical 2 day deployment workshop or review for an enterprise scale Rational development environment:

IBM Rational software supports deployment workshops and reviews pre- and post-sales. A more detailed sample agenda can be found at Deployment Workshops and Reviews in Detail.

Related topics: Principles of good virtualization, Standard deployment topologies overview, Planning for multiple Jazz application server instances, Understanding reverse proxy, High availability principles, Disaster recovery principles, Approaches to implementing high availability and disaster recovery for Jazz, Typical Deployment Planning Workshop Questions

External links:

• None

Additional contributors: None