Table of Contents

Overview

The purpose of registering your business critical application is to facilitate communication and coordination between your team and ITS. The Business Critical Application Registration service allows you to identify to ITS your business critical applications. This will allow us to keep you informed of planned changes to UH Login and other IAM services that may impact the availability of your application so that you can plan for testing. By working together we can better prevent interruptions to the services you offer to your community.

Registration request form

• Use this link to register a Business Critical Application: <request registration>

Original Blog Announcement

• <Announcing the new Business Critical Application registration service>, includes a helpful table for comparing the service levels.

Terminology

• Application – examples include Banner, Star, Laulima, gMail, Kuali Build, etc.

• BCA – Business Critical Application

• Business Critical – vital to the University's ability to perform its mission.

• Directory Services – an IAM service for listing people and related information about each person. LDAP is the primary software component of this service.

• IAM – Identity and Access Management, an ITS team dedicated to authentication, authorization, directory, and related middleware services.

• ITS – Information Technology Service, a system office.

• Production environment – AKA Production. Production supports the University's daily business operations. All changes to Production are first vetted in Test to mitigate the risk of interruption to University business processes.

• Service level objectives – AKA SLO. For a business critical application, the application should be available at least 99.5% of the time. There are a number of requirements that need to be in place in order for this objective to be met and sustained.

• Stakeholders – the executive sponsor and primary contacts for a business critical application.

• Temporary Production environment – a deprecated Production environment that is retained temporarily for applications that cannot initially work with the updated production environment. For example, we may maintain a deprecated UH Login environment supporting TLS v1.0 for a limited time if you are unable to correct your application before the test window ends and TLS v1.0 is retired in production.

• Test environment – AKA Test. Changes are first introduced to Test so that everyone has the opportunity to test for any breaking changes.

• TLS – used to secure Internet communications between your application and UH Login. The TLS version changes every few years as stronger cryptographic ciphers are required to ensure secure communications. Your application will periodically need to be tested to ensure that it works with the newer TLS versions as older ones are retired.

• UH Login – an IAM service for authentication. Identifies the person attempting to access your application. CAS and Shibboleth IdP are the primary software components of this service. 

Requirements

An application is business critical if, besides being critical to your daily operations, it is provided with the proper support staff and the proper maintenance activities are regularly performed. Each of the following is a prerequisite requirement for declaring an application to be business critical. A team that cannot meet all of these requirements puts a business critical application at a high level of risk.

Both sets of requirements must be met in order register your application as business critical. 

1) Operational requirements

Requirements for determining if an application requires a business critical level of service:

• This is for you to determine. You know best which business processes are critical to your operations.

2) Staff and support requirements

Requirements for ensuring that the resources are available for achieving a business critical level of service: 

• Assigned dedicated technical staff with the appropriate skills to manage the application.

• The application is updated regularly to ensure that it remains on vendor or community supported versions.

• There is a test environment or other means to test the application against the Test UH Login environment in a timely manner when requested.

• The application is on a manufacturer or 3rd-party support plan in order to ensure that support can be escalated as needed.

• The application is staffed such that it can meet ITS criteria for addressing critical security vulnerabilities (7-9 calendar days for applying critical security patches across all test and production environments).

• The application is hosted on physical infrastructure suitable for meeting its operational availability objectives.

Business Critical Application Workflows

Registration Workflow

Scope

Major changes have the potential to break your application. Preparation and testing in advance is paramount. This service is specific to the following:

• UH Login, AKA CAS and Shibboleth

• Directory Services, AKA LDAP

Major changes include major software upgrades and TLS upgrades.

Roles

• Stakeholder - Primary technical contact, in most cases, for the application to be registered.

• ITS - ITS staff responsible for the services being upgraded.

Workflow (who: action)

1. Stakeholder: determine that an application meets all of the requirements for business critical.

   1. Perform any internal changes needed to meet all of the criteria.

2. Stakeholder: submit a request to register a business critical application.

3. ITS: review the request

   1. Followup with any questions as needed to approve the request.

4. ITS: approve the request if appropriate

Outcomes

1. ITS: include the primary contacts in any stakeholder communications for coordinating application testing.

2. ITS: annually remind the executive sponsor and the primary contacts to renewal.

Annual Renewal Workflow

The annual registration renewal is essential for ensuring that ITS can successfully communicate and coordinate with your support team. Staff reassignment and turnover often complicate communications due to the accumulation of stale contact information. The annual renewal helps ensure that contact information gets updated. It is important that you respond to the annual renewals.

Workflow

1. ITS: email a request for confirmation that the application is still in service and request a review and update of the primary contacts information.

2. Stakeholder: ensure that the business critical applications requirements continue to be met and fully reply to the annual renewal request.

Outcomes

1. ITS: updates contact information as needed to ensure we can stay in touch, or retires the BCA if that is appropriate.

Test Notifications and Testing Workflow

Planned changes to IAM services are communicated in advance in order to give your team time to test your application. It takes a huge amount of coordination across the enterprise to plan a test window and the subsequent production upgrade such that we minimize risk to academic and business calendars. It is vitally important that your team make the best use of the test window.

Test Window notifications are communicated by email.

Workflow

1. ITS: plan and coordinate test windows as needed for upgrades and application testing.

2. ITS: announce test windows to all stakeholders.

3. Stakeholder: assign the necessary resources in order to ensure that testing is performed during the test window.

   1. Work with ITS, the 3rd party support resources, and the developer community as appropriate to resolve any compatibility issues. Compatibility issues may arise with the changes to UH Login, TLS, etc.

4. ITS: temporarily implement a temporary Production environment for applications that cannot meet the deadline.

5. Stakeholder: should testing indicate a major compatibility issue, utilize the depreciated environment to buy more time to resolve any compatibility issues. 

   1. Work with ITS, the 3rd party support resources, and the developer community as appropriate to resolve any configuration issues. The application will have to be reconfigured to referenced the temporary Production environment.

   2. Note that ITS will not configure your application.

Outcomes

1. ITS: concludes the test window and promotes the upgrades to production as scheduled.

2. Stakeholder: ensure that services continue without interruption.

Test Requirements

Application owners are provided a test window and should be prepared to performing testing as early as possible during the test window in order to have time to resolve any issues that may come up. It is recommended that the test instance of your application is configured to point to the respective Test environment

Referencing the Test Environment

IAM Test environment references:

• UH Login, CAS – <developer documentation>

• UH Login, Shibboleth Identity Provider – <developer documentation>

Terms and Conditions

The following help to manage expectations:

• Best effort support: ITS will provide best effort support. The UH App Developers list is an excellent resource. The best resource will be 3rd-party or developer support dedicated to your business critical application.

• Temporary Production environment: ITS will only retain one deprecated Production environment and only for a limited time, usually only 1-2 months. Less, if there are substantial security risks.

• Tests window: under normal circumstances are at least 8 week between initial announcement and the availability of the test environment and the date of changes to production. Test windows may be as little as 1-2 weeks for critical security patches.

Example Scenarios

For each of these scenarios the assumption is that testing is a requirement. While these scenarios mention UH Login, they are equally true for Directory Services (LDAP), etc.

Your application does not have a Test environment

It is best that you avoid this scenario, if at all possible.

• You will need to schedule a downtime such that you can reconfigure your application point to the Test UH Login environment.

• Concerns

  • The downtime reduces availability of the service to your community.

  • Reconfiguring your application (twice) introduces the potential for human failure.

  • If the test fails, troubleshooting and subsequent testing will require additional downtime(s).

Your application issue cannot be resolved before the test window ends

With sufficient preparation and planning, you can avoid this scenario.

• You will need to reconfigure your application to point to the designated regressed UH Login environment while testing continues.

• Concerns

  • Reconfiguring your application (twice) introduces the potential for human failure.

  • The regressed UH Login environment may be available for only 3 months. It will be upgraded to the next regression level during a subsequent UH Login upgrade.

Your application issue cannot be resolved for a prolonged period

A worst case scenario.

• Executive management will need to become involved in order to balance the business risks, security risks, and resource implications.

Additional Information

Data Governance Process

The Data Governance Process references the UH Login service, and the UH Login service in turn references the Data Governance process. For example, integration with a 3rd-party service living in the cloud, Kuali Build for example, requires integrating the cloud service with UH Login.

How are critical security patches handled?

Critical security patches are handled on a case-by-case bases.  A sufficiently critical patch may necessitate a very short test window with very little advanced notice.

What if my Application is not Business Critical?

You can remain informed by subscribing to the UH App Developers list. All planned changes and calls for testing are announced to the UH App Developers list. This forum is for the UH IT community, which includes IT staff, IT managers, IT professors and those participating in IT-related projects. More information is available.