Standard deployment topologies overview

Since April 2019, CE, CLM and the Jazz product set were renamed to Engineering Lifecycle Management (ELM). The Renaming the IBM Continuous Engineering Portfolio article explains what each application will be referred to from now on. For consistency, older names have been kept in this article, only where they do not apply to the ELM 7.x release.

One of the most frequently asked questions is how to deploy the full ELM solution so that it performs well, runs robustly, and evolves without restriction. Administrators ask about possible deployment strategies because they must balance two sometimes opposing forces: the desire to build what's right for their organizations and the desire to stay within the mainstream of the ELM product evolution so they can easily and quickly reap the benefits of new capabilities.

ELM system requirements permit a range of supported middleware platforms and topologies upon which to host the solution. This article presents an opinionated set of deployment patterns which, all things being equal, are likely to be optimal. For example, we strongly recommend using a reverse proxy server in front of either a centralized or a distributed set of web application servers. To simplify the wide range of choices, this article outlines several standard topologies which are the expected and most frequently chosen deployment patterns in recent years.

Publishing these standard topologies represents tried and true examples of successful deployments. Additionally, the ELM solution system testing organization uses these topologies to perform deep “customer simulation” testing, which includes installation, upgrade, functional, performance, and robustness testing. By adhering closely to one of these standard topologies, you will have an easier time characterizing your deployment in the event of an interaction with IBM software support. These topologies are a “shorthand” reference that can be used whenever an ELM deployment is discussed. For example, when system performance testing results or a high availability configuration is discussed, the appropriate standard topology can be referenced.

Several teams came together to define and document these standard topologies. These teams design and execute system, performance, and reliability testing, develop and support the ELM products, and work directly with clients to design and implement the ELM solution at locations worldwide.

Some considerations and opinionated recommendations

1. If your enterprise can support RedHat Enterprise Linux, then we recommend using that. Some advanced capabilities (most commonly clustering EWM or ETM) require the MQTT broker Eclipse Amlen (formerly IBM Watson IoT Message Gateway), which requires at least one server running RedHat Enterprise Linux x86-64. Additionally, we have found in many customer environments (and our labs) that deployments on Linux have performance advantages over deployments on Windows, other factors being approximately equal.
2. Meeting your organization’s mandate to quickly apply patches to address vulnerabilities: beginning with ELM 7.0.3 all deployments must use WebSphere Liberty as the application server. Traditional WebSphere Application Server is no longer an option, because it does not work with Java 11. A new option is available in the ELM 7.0.3 installer to deploy the ELM applications for use in a stand-alone Liberty profile similar to how ELM applications were deployed for traditional WebSphere in past releases. The advantage of using stand-alone Liberty is that you can upgrade to later versions and fixes with the latest security updates to Liberty (and Java) as soon as they are released. The ELM teams do not typically update the embedded Liberty.
3. Selecting the optimal database for your deployment involves many factors, including the following:
   1. If you expect your data to grow to be quite large (millions of artifacts or artifact versions), you may wish to deploy Oracle Enterprise. With DOORS Next and Test Management we have found Oracle’s query planner/optimizer provides significant advantages. We strongly recommend Oracle Enterprise Edition instead of Oracle Standard Edition as noted in the ELM 7.0.3 What’s new topic.
   2. If you expect to consider moving to an IBM-hosted environment of ELM, consider Db2. This would save you the effort of migrating to Db2 later.
   3. If you wish to minimize database license costs, consider Db2. ELM includes limited use licenses to use as many instances of Db2 for your ELM deployment as you have user licenses.
   4. Note that beginning with ELM 7.0.3 Microsoft SQL Server is no longer supported. If you are using this database and wish to upgrade to ELM 7.0.3 or later, you will need to migrate to Db2 or Oracle before upgrading. For more information see [link: TBD]

Please Note: The above guidance is not meant to steer you away from deployments on z or POWER systems or signal a lessening of our commitment to these environments.

Key topology variants

The ELM applications and Jazz Team Server can be installed on shared application servers or distributed across multiple application servers for improved scalability. Although this flexibility allows you to design a topology to best fit your needs, that flexibility also adds complexity to the planning process. As a result, it is important to plan your deployment topology carefully as changing your topology later can be very complex and require substantial application downtime. Potential deployment topologies are divided into three key topology variants: Department, Enterprise and Federated.

With CE/CLM 6.x we decided to retire the Evaluation Topology. With the additional capabilities recently added it is no longer practical to deploy everything on a single server: the primary applications, supporting capabilities such as reporting, and the database. The different workloads of user interactive applications, automated reporting data processing and database workloads do not work well together on a single server. Since the vast majority of our customers deploy ELM on virtual servers, it makes much more sense to use a Departmental Topology with minimum resources. The article Proof of Concept Sizing when using Application Lifecycle Management capabilities in 6.x (which also applies to ELM 7.x) provides specific guidance on deploying a proof of concept or evaluation environment.

There is also specific guidance on how to evolve your topology from a Departmental to a partial or full Enterprise Topology.

Departmental topologies

The Departmental topology is the minimum topology we recommend for any production environment. Use a stable, company-approved host name and register it with the domain name server (DNS) to keep the URLs of the data stable (see Planning your URIs). In this type of installation, databases are installed on a dedicated database server, and one or more other applications are installed on an application server. The DCC and LQE applications must be installed on separate application servers. A key advantage of the departmental topologies is that they require less hardware and are easier to deploy initially. These topologies are best for smaller projects and smaller-sized teams. Due to the resource constraints of the departmental topology, it is also recommended that the DCC collection jobs are only run once daily, during "off hours". Crucially, if you expect that your deployment will expand, you should consider starting with a Modified Departmental pattern. The following diagram is a generic example of a departmental topology for the ELM 7.x solution. If you are deploying Rhapsody Model Manager (RMM), please review Deployment options for IBM Engineering Workflow Management with Architecture Management Extension article for additional guidance.

A Modified Departmental pattern is a combination of application servers that serve single applications with other servers hosting multiple applications. This can be used initially or as an interim step towards full Enterprise deployment based on application usage and resource availability.

• Generic Departmental Topology for ELM 7.x:
  

Please see the Modified Departmental pattern for further guidance on how to scale your Departmental topology as you grow, such as when you intend widespread use of Global Configuration Management or higher usage of a single application.

Enterprise topologies

Enterprise topologies are useful for production or medium-sized to large-sized teams and multiple server (or distributed) deployments. Use a stable, company-approved host name and register it with the domain name server (DNS) to keep the URLs of the data stable (see Planning your URIs). Enterprise topologies distribute the ELM applications, Jazz Team Server, the database software, etc., and are more flexible. These topologies enable you to incrementally adopt applications into your deployment and configure them to use the same Jazz Team Server. In this type of installation, databases are installed on a single database server and each application is usually installed on its own dedicated application server. In addition, to connect multiple application instances to a shared Jazz Team Server, the instances must all be authenticated from the same authentication realm and thus share the same set of users. The following diagram is a generic example of an enterprise topology for the ELM 7.x solution. If you are deploying Rhapsody Model Manager (RMM), please review Deployment options for IBM Engineering Workflow Management with Architecture Management Extension article for additional guidance.

• Generic Enterprise Topology for ELM 7.x:
  

Please Note: * All the databases in this topology are shown hosted by a single logical Database Server. However, for medium to large deployments we recommend multiple database servers or database clustering using Db2 or Oracle. Typically the Data Warehouse (DCC) and most utilized applications (typically RM or CCM) are first to be separated onto their own Database Servers, see Multiple Database Servers.

Federated topologies

Federated topologies are useful to very large enterprises who tend to deploy an ELM solution per product line or organizational division but would still like to be able to pull together a program-level or enterprise-wide view of their entire portfolio of work. Often versions of products or subsystems in one division are used as a part of a larger solution. Use a stable, company-approved host name and register it with the domain name server (DNS) to keep the URLs of the data stable (see Planning your URIs). The following diagram is a generic example of a federated topology for the ELM 7.x solution. If you are deploying Rhapsody Model Manager (RMM), please review Deployment options for IBM Engineering Workflow Management with Architecture Management Extension article for additional guidance.

• Generic Federated Topology for ELM 7.x:
  

Please Note:

• This topology contains multiple data warehouses. Use the instructions from How to upgrade data warehouse for Generic Modified Federated Topology document to upgrade data warehouse.
• Business Unit 1 represents a larger business unit whereas Business Unit 2 a smaller business unit or a business unit just starting its adoption of ELM. Business Unit 2 can be easily scaled to the pattern of Business Unit 1 or incrementally through the Modified Departmental pattern.
• All the databases in this topology are shown hosted by a single logical Database Server. However, for medium to large deployments we recommend multiple database servers or database clustering using Db2 or Oracle. Typically the Data Warehouse (DCC) and most utilized applications (typically RM or CCM) are first to be separated onto their own Database Servers, see Multiple Database Servers.
• Since CE/CLM 6.0.6.1 you can separate the LDX Server onto its own server, see Installing Link Index Provider (LDX) on its own Server.
• It is important to monitor the performance of the server where LDX resides. A federated topology has single points of failure at the JTS and the LDX levels and with more contributors/subprojects, it is important to separate these applications to avoid contention.

Modified federated topologies

The modified federated topology is similar in intent to the federated topology but is implemented with a single JTS instance. The grey dotted boxes in the below diagram are only logical groups of servers, all within the same ELM instance.

• Generic Modified Federated Topology for ELM 7.x:
  

Please Note:

• This topology contains multiple data warehouses. Use the instructions from How to upgrade data warehouse for Generic Modified Federated Topology document to upgrade data warehouse.
• Business Unit 1 represents a larger business unit whereas Business Unit 2 a smaller business unit or a business unit just starting its adoption of ELM. Business Unit 2 can be easily scaled to the pattern of Business Unit 1 or incrementally through the Modified Departmental pattern.
• All the databases in this topology are shown hosted by a single logical Database Server. However, for medium to large deployments we recommend multiple database servers or database clustering using Db2 or Oracle. Typically the Data Warehouse (DCC) and most utilized applications (typically RM or CCM) are first to be separated onto their own Database Servers, see Multiple Database Servers.
• Since CE/CLM 6.0.6.1 you can separate the LDX Server onto its own server, see Installing Link Index Provider (LDX) on its own Server.
• It is important to monitor the performance of the server where LDX resides. A federated topology has single points of failure at the JTS and the LDX levels and with more contributors/subprojects, it is important to separate these applications to avoid contention.
  • A deployment pattern has been developed to assist with LDX performance. See Multiple Distributed LDX Servers in Modified Federated Topology

Datasheets and sizing guidelines

Find ELM-specific performance datasheets, sizing guidelines and performance-related case studies on the Performance datasheets and sizing guidelines page.

Related topics:

• Standard Topology Patterns Overview
• Deployment planning
• Deployment planning and design