Tideway Foundation discovers the "as is" state of the environment. A filtered subset of that (as defined by a set of "scope rules") is viewed in Lifecycle Management, providing the opportunity to authorize changes, mark elements of the infrastructure as part of the "Authorized" state.

In conjunction with Tideway Export, Lifecycle Management views also serve as a means of controlling the export of Foundation data to downstream systems. A view's contents, can be used as the basis for an export.

The following diagram shows how Lifecycle Management fits with Tideway Foundation and Export.

The need for Lifecycle Management

As part of an organization's change control management process, Lifecycle Management allows operators to establish a baseline of approved hosts, and of the hosts on which an application's execution is approved, by changing the state of dependencies. Dependencies have a state that reflects whether Tideway Foundation was able to discover their components. As dependencies' lifecycles are changed, alerts are raised as a result. This means that changes relative to an approved baseline may be detected efficiently. Lifecycle Management' dependency display then allows these changes to be quickly categorized as due to planned or unplanned change in the environment, scan failures due to invalid login credentials, application modelling issues, or other failures such as hardware or network problems. This makes Lifecycle Management a key tool for both diagnosing the causes of infrastructure change and maintaining the effectiveness of Foundation's models.

In order to aid the investigation and remediation of changes, users can create notes, and associate them with a set of dependencies to group together changes believed to be due to a single root cause, for example a specific planned change. A note maintains a log of comments describing their activities, and can contain customizable structured data to aid reporting and gathering of metrics around infrastructure change.

Lifecycle Management users monitor and manipulate dependencies using views. A user sets the scope of a view to expose a cross-section of the data discovered by Foundation. For example, one view may show the infrastructure dependencies for a particular application, another may show all dependencies on production infrastructure in London. Another may be used to manage the status of all hosts running a particular operating system or connected to a particular switch.

Lifecycle Management views also provide a means of exercising control over exports of Foundation data. Users can tailor the items in a view to select subsets of Foundation data for different export targets. Policies can be established whereby explicit approval of an infrastructure component or an application's dependency on it is needed before Business Service Management tools are made aware of it. This is further enhanced through close integration with Tideway Export.

One way in which these capabilities may be used is in the context of reviewing changes which have occurred in the environment in order to determine whether the change should be propagated to downstream systems via Tideway Export.

Changes observed through Lifecycle Management will be the result of a number of different root causes. The ways in which different classes of change might be handled are discussed briefly below:

Planned Changes

A change in the environment has been introduced which is covered by a valid Request For Change (RFC)

An example would be the introduction of a new infrastructure component into the production environment. The Lifecycle Management user is likely to want to authorize this change so that it becomes part of the baseline.

Unplanned Changes

An unauthorized change has occurred. There is no explanation for or description of this change in the Change Management system. At this point, the next step might be to raise an incident to flag the unauthorized change, though the precise actions would depend both on the nature of the observed change and local working practice.

Transient Changes

These changes generate "noise" and require investigation in order to identify whether or not they are significant. Example of these kinds of changes include processes which are intermittently visible (for example, batch jobs) but which form part of a Business Application, or hosts which are temporarily unavailable at the time of scanning.

An example of a transient change are component which are only sometimes visible to scanning and therefore are identified as lifecycle changes to nodes that represent them in the Foundation Model.

The way transient changes are handled is detailed in Treatment of Transient Processes.

Errors in Discovery

Failures in Discovery can give rise to apparent changes which may not accurately reflect reality. Various kinds of errors may occur:

• Temporary network failure at the time of scanning.
• Failed credentials to log into a host or changes in access to configuration files.
• Inability to run some commands.

Lifecycle Management supports the rapid identification and resolution of such issues through its tight integration with Foundation. Users can click through from a Lifecycle Management view to the relevant nodes in Foundation. Once in Foundation the provenance data available with Foundation can assist in problem resolution.