Remedy on-premises solution architecture

The Remedy solution consists of components in the Remedy stack that integrate with each other and other applications to support your business service model. Before designing a Remedy deployment solution to support your business service needs, you must understand the different architecture layers, the basic deployment model, and alternative deployment options available in Remedy.

Remedy solution architecture tiers

The Remedy solution architecture is a multi-tier, client/server architecture that consists of the client tier, the web tier, the server tier, and the data tier.

The client tools in the client tier enable you to access, manage, and build applications.
The applications in the web tier make web services accessible and enable you to access the server tier from a browser.
The server tier enforces the business logic and runs the Remedy applications and workflows.
The data tier holds data that applications can create, access, and manipulate.

The following illustration shows the Remedy solution architecture tiers:

The tiered architecture enables you to deploy applications such as Remedy IT Service Management, BMC Service Request Management, and BMC Service Level Management in a scalable and flexible manner.

Remedy IT Service Management

You can use ITSM Suite to streamline and automate the processes around IT service desk, asset management, and change management operations. You can also link your business services to your IT infrastructure to manage the impact of technology changes on business and business changes on technology, in real time and into the future.

BMC Service Request Management

IT department and other business departments can use the BMC Service Request Management application to easily define available services, publish those services in a service catalog, and automate fulfillment of those services for the user community, enabling users to help themselves. BMC Service Request Management works with other applications, such as BMC Incident Management and BMC Change Management, to resolve user requests. BMC Service Request Management manages the entire process, from submission to completion.

BMC Service Level Management

IT department and other business departments can use the BMC Service Level Management application, to formally document the needs of its customers or lines of business by using service level agreements, and to provide the correct level of service to meet those needs. BMC Service Level Management also provides a means to review, enforce, and report on the level of service provided. It streamlines the most important task of all, which is the communication between a service provider and its customers.

Remedy solution architecture components

The following illustration shows the relationship among the components that reside within each of the functional environments of the Remedy deployment architecture, the architectural layers, and the layout of the applications in these layers.

The Remedy solution architecture consists of the following applications per tier:

Tier	Application
Client tier	The Client tier consists of client tools that help you access a service made available by a server. The tools in this layer are responsible for presenting services and displaying data to clients through various interfaces, which include the following: Browsers Cell phones PCs Personal Digital Assistants (PDAs) Remedy Developer Studio API programs
Web tier	The Web tier consists of applications that enable you to access the server tier from a browser and make web services accessible. The following applications are included in the Web tier: Remedy Mid Tier - The Remedy Mid Tier enables you to access AR System server from a browser. The Mid Tier contains components and add-in services that run on a web server, enabling users to view applications on the web. Remedy Mid Tier translates client requests, interprets responses from the server, handles web service requests, and runs server-side processes that provide Remedy AR System functionality to web and wireless clients. A browser is a generic client that has no inherent knowledge of any application that might run within it. By acting as an interpreter, the mid tier allows a browser to become a fully functional Remedy AR System client. Remedy Single Sign-On (RSSO) - Remedy Single Sign-On (RSSO) is an authentication system for a multi software environment that enables users to present credentials for authentication only once. After Remedy SSO authenticates the users, they can gain access to any other application with automatic authentication without providing the credentials again. Remedy Smart Reporting - Remedy Smart Reporting is an easy-to-use reporting application for non-technical users that delivers drag-and-drop support for formatting and data selection. Remedy with Smart IT - Smart IT user interface makes it easier for you to perform basic BMC Remedy ITSM processes reducing the number of steps involved in performing the tasks. Smart IT sets a new standard for the modern, collaborative workplace with an intuitive, social, and mobile service desk experience to users. BMC Digital Workplace - BMC Digital Workplace is a self-service application for business users to connect with IT and HR anywhere, anytime, on any device. With BMC Digital Workplace, users can solve problems themselves before filing an incident, opening an HR case, or talking to support staff. IT and other support staff can create knowledge articles, and create links to the online (internal or external) product documentation, troubleshooting tips, tutorials, videos, and other resources. End users can then access those resources through search or from the profile of an asset or service. BMC Digital Workplace Catalog - BMC Digital Workplace Catalog is an enterprise app store solution designed to be the center of your digital workplace. Through a single administration dashboard, IT departments can aggregate, manage, deliver, and track hardware, software, and services from multiple cloud-based and on-premises sources. BMC Digital Workplace Catalog integrates with external fulfillment systems through service connectors to enable communication between the catalog application platform and the different fulfillment systems.
Server tier	The Server tier consists of applications and workflows that enforce the business logic. The following applications are included in the Server tier: Remedy AR System server - Remedy AR System provides a consolidated Service Process Management platform for you to automate and manage Service Management business processes. It is request-centric with a workflow-based architecture. Remedy AR System is optimized for efficiency in Service Management business process delivery and includes pre-built modules for notifications, escalations, and approvals. The AR System server processes data it receives from Remedy AR System clients and stores the data in the database server. BMC Atrium CMDB - The BMC Atrium Configuration Management Database (BMC Atrium CMDB) enables you to implement a configuration management database (CMDB) in your environment. Any application that is integrated with BMC Atrium CMDB (for example, a data provider like BMC Atrium Discovery and Dependency Mapping or a data consumer like BMC Asset Management) can access the data from a centralized database. Remedy ITSM applications - Remedy ITSM Suite applications enable you to streamline and automate the processes around IT service desk, asset management, and change management operations. The following applications are included: BMC Service Desk (includes BMC Incident Management and BMC Problem Management) BMC Change Management BMC Asset Management BMC Knowledge Management
Data tier	The Data tier holds data that applications can create and manipulate. The Data tier can use any of the following database platforms: Microsoft SQL Server Oracle PostgreSQL (Linux) The following databases are included in the Data tier: AR System database - Stores definitions and data for the Remedy AR System server. Smart IT database - Stores definitions and data for Smart IT. Smart Reporting database - Stores definitions and data for Smart Reporting.

Basic deployment model for Remedy

The basic on-premises deployment model for Remedy demonstrates the possibility of deploying the applications in the web tier that can be co-located with each other in a single server.

Note

The basic deployment model does not change or replace various alternative deployment options that were previously supported for high availability and other requirements.

Consider a basic deployment model, if you have the following requirements:

If you are looking to deploy a small model.
If your objective is to reduce the hardware footprint.
If you want to reduce the overhead of hardware, OS, and application maintenance.
If you do not have high availability requirements.

The basic Remedy deployment model includes applications that run in different designated tiers. It also includes web tier applications that run on different Tomcat servers within the same physical server. For example, Mid Tier and Smart IT can be deployed on the same server because all users logging on to these applications are ITSM users. When two applications are run on the same server, the user load is shared efficiently by these applications. However, in such a shared deployment, the biggest drawback can be the monopolization of the shared resources when an application misbehaves. Thus, to achieve a stable deployment, you must consider all aspects of business and technical requirements when deciding on a suitable deployment architecture.

This model represents the simplest way of deploying your Remedy applications. Based on your environment and system requirements, you can modify the deployment to support your organization's high availability and other needs. This basic model depicts a minimal deployment model. It has only one instance of each application. While this is a functionally complete model, it does not provide the high availability (HA) support that BMC recommends for an enterprise class application such as Remedy.

This basic model can be easily extended to provide HA by adding additional servers and application instances at each tier.

Sizing baselines for the basic deployment model

The sizing baselines in the following table are based on performance lab benchmark test results and real-world customer experience. For more information about performance tuning and configuration checklist, see the Knowledge Article 000114508.

The basic Remedy deployment model can support up to 800 concurrent users. Concurrent users indicate the number of users logged in and actively working on the system. If your organization is using a significant number of web-based clients (utilizing the mid tier) and the thick-based BMC Remedy client tool, you should calculate the totals for each and use the total number as the estimate for concurrent users.

The following table lists the configuration for the type of deployment:

Type of deployment	Number of Remedy ITSM concurrent users	Number of Remedy Smart Reporting concurrent users	Number of Digital Workplace users
Small	800	50	800
Medium	2000	100	2000
Large	5000	250	5000

The following table lists the sizing baselines for small deployment:

Deployed components	Small deployment
Only Remedy ITSM stack
Web tier	12 CPUs, 36 GB RAM* *_{(12 CPUs includes the CPU requirements of each component of the Web tier. 36 GB RAM is needed for deploying Remedy Mid Tier, Remedy Single Sign-On, Virtual Chat, and Smart Reporting on the same server. See the Knowledge Article 000114508).}
Server tier	12 CPUs * 32 GB RAM
Data tier	8 CPU, 16 GB RAM
Remedy ITSM stack with Smart IT
Web tier	16 CPUs, 48 GB RAM* *_{(16 CPUs includes the CPU requirements of each component of the Web tier. 48 GB RAM is needed for deploying Remedy Mid Tier, Remedy Single Sign-On, Virtual Chat, and Smart Reporting on the same server. See the Knowledge Article 000114508)}
Server tier	16 CPUs * 48 GB RAM
Data tier	8 CPU, 16 GB RAM
Remedy ITSM stack with Smart IT and Digital Workplace
Web tier	24 CPUs, 64 GB RAM* *_{(24 CPUs includes the CPU requirements of each component of the Web tier. 64 GB RAM is needed for deploying Remedy Mid Tier, Remedy Single Sign-On, Virtual Chat, and Smart Reporting on the same server. See the Knowledge Article 000114508).} DWP Catalog server with 8 CPU, 16 GB RAM
Server tier	AR System server with 20 CPU, 64 GB RAM
Data tier	16 CPU, 32 GB RAM

Deployment High Availability (HA) can be accomplished through standard horizontal scaling. The entire deployment model can be duplicated with the original resource allocation in place. The simplest HA can be achieved when the deployment is virtualized; that is, the entire deployment model is duplicated and enough resources are allocated to the VMs.

One example of enabling HA in your environment is that if you are using only the Remedy ITSM stack, configure two servers, each with 12 CPU and 36 GB RAM for the Web tier. One server is for primary use and the other is for HA. Therefore, as per the above sizing guidelines, if you have a single server with 12 CPU and 36 GB RAM for your base Web tier, you would have two servers with 12 CPU, 36 GB RAM in HA deployment.

For information about sizing baselines for medium and large deployments, see the Knowledge Article 000114508.

Alternative deployment models for Remedy

The basic layout for Remedy deployment is to deploy all the Web tier applications on the same physical server. However, the other options for deployment include Web tier applications that can be installed on different physical servers. An example would be to deploy Remedy Single Sign-On (RSSO) or Remedy Smart Reporting or BMC Digital Workplace separately on different physical servers.

The following illustration shows a deployment variation for the Remedy solution:

A practical approach in architecting a deployment solution is to ensure that you perform the following actions:

Isolate the services that are common and can be re-used or consumed by other services.
Separate the major services so that the service can be assigned dedicated resources.
Duplicate the services that require high availability (HA).

With reference to the preceding deployment model, you should perform the following actions:

Isolate the Remedy Single Sign-On (RSSO) service because RSSO is multitenant and can act as a shared service across multiple environments such as development, QA, and production.
Separate and deploy Remedy Smart Reporting on its own server because Smart Reporting is a major service and can consume considerable amount of resources for generating large reports. If Smart Reporting is deployed on the same server as that of Mid Tier or Smart IT, it might impact the performance of those application for end users.
If you have heavy Reporting usage, have a separate Reporting environment by using a separate database server.
For Smart Reporting that is run with other web applications, it is also possible to have a dedicated AR System server for Smart reporting application to isolate the reporting load.
Use multiple AR System servers, a subset of which is used for user-facing activities and the rest of the servers are used for background processing tasks such as email, approvals, and assignment. This separation is done to ensure that the background activities do not impact the user-facing activities.

For information about the sizing baselines, see the Knowledge Article 000114508.

For information about the sizing baselines for a medium model deployment, see Hardware requirements.

For information about sizing baselines for Digital Workplace, see the Knowledge Article on BMC Communities.

Remedy Migrator memory usage and disk space requirements

Before installing Migrator, ensure that you have a Microsoft Windows server with a minimum of 2 CPUs, 4 GBs of memory, and 40 GBs of free disk space.

If you plan to use the Delta Data Migration (DDM) tool that is bundled with Remedy Migrator, BMC recommends that you install Remedy Migrator on a standalone Windows server. Install in the same LAN as the destination Remedy AR System server but not on the source (current production) or destination (production staging) AR System servers. If the Windows server resides outside of the LAN segment, BMC recommends that you deploy a separate server for the Delta Data Migration tool, and that you run that server on the same LAN segment as the current production and staging servers.

Alternatively, if you do not have an additional Windows server, you can use the mid tier server in the production staging environment as the host for Remedy Migrator and the Delta Data Migration tool. Ensure that the mid tier is disabled when you migrate your delta data.

To avoid performance issues, do not install any other application on the computer where the Remedy Migrator is installed.

Remedy security architecture

Encryption enables the Remedy Action Request System (Remedy AR System) server and its clients to communicate securely over a network by encrypting the messages sent between them. At the beginning of every client and server connection, a key exchange protocol negotiates shared encryption keys between the client and server. These keys encrypt all communication between the client and server, ensuring that the communication is secure and that third parties cannot decipher the messages in transit. Note that if you choose the encryption options during installation, it does not encrypt the communication between the browser and the Remedy Mid Tier. To enable the encryption between the browser and mid tier, you must install the X.509 certificate to be installed on the mid tier or on the load balancer depending upon your deployment and security requirements. Data encryption is invisible to users.

The following illustration shows the Remedy security architecture:

The Remedy AR System client libraries provide built-in encryption capabilities to enable and secure the connection to the AR System server. Higher levels of encryption are available from BMC if you need stronger encryption. Remedy AR System is also tested with database encryption products from your database vendor to ensure that this connection can be encrypted. The communication between the AR System server and the database are not natively encrypted. The encryption is subject to the capabilities provided by the database vendor.