Different business domains require different solutions for their operational supervision and coordination needs. For example, the precise needs of a major construction project differ radically from those of an emergency response command center, or a sports stadium's operation center.
However, there are many basic structural requirements common across these domains:
- Alerts come from the field
- Response teams need to be organized
- Standard operating procedures need to be supported
- Performance needs to be tracked through key indicators
- Improvements need to be made
The IBM Intelligent Operation Center is a software environment that supports the implementation of such solutions by providing an architecture supporting these features. It provides multiple integration points through which solution delivery organizations can provide domain accelerators. The IBM Intelligent Operations Center V1.5 United States Software Announcement 212 – 250, July 3, 2012 (see Resources) provides more detail.
Standard operating procedures
A standard operating procedure, or SOP, is a collection of predetermined steps designed to ensure an effective response to an incident through the coordination of people, products, properties, and processes. Steps can be further defined as a series of activities; they can begin with no feedback requirement, or they can require some level of feedback before the SOP can continue to the next step. The specific feedback required is different for different activities.
Some common requirements exist: the system needs to know when an activity has started and when it has ended; people need to be communicated with; new alerts need to be raised. The Intelligent Operations Center provides some of these capabilities through its integration of IBM Tivoli Service Request Manager.
A common use case for SOP implementation, not currently provided by the Intelligent Operations Center, is for an activity to require some predefined feedback or a specific set of data from an operator. Typically, forms are used to support this use case. The Federal Emergency Management Agency (FEMA) website provides a large range of forms covering different activities within their scope (see Resources).
Standard operating procedures in Tivoli Service Request Manager
Three Intelligent Operations Center artifacts are required to create an SOP in Tivoli Service Request Manager: a standard operating procedure, a selector matrix, and a response plan. The SOP consists of the complete set of steps and activities that constitute a procedure. An example of a SOP in the context of public safety is shown in Figure 1.
It consists of two steps, one of which will trigger a workflow. Both of the steps have roles assigned to them. (Assigning roles and workflows are optional.)
Figure 1. SOP example in Tivoli Service Request Manager console
(View a larger version of Figure 1.)
The SOP Selection Matrix application is used to build an SOP selector matrix that defines an SOP selector value based on event category, severity, certainty, and urgency. The matrix and value for the SOP selection matrix for the bomb threat SOP is 7 and can be seen in the Figure 1.
A response plan then is used to define a link between the SOP selector value and an SOP to be applied – see Figure 2.
When an Intelligent Operations Center incident is created within Tivoli Service Request Manager, triggered by an event from Intelligent Operations Center, an SOP selector value for the Intelligent Operations Center incident is chosen, based upon the SOP selector matrix, which is based upon the event parameters. The Intelligent Operations Center events trigger Tivoli Service Request Manager to create an incident. Applying the event’s parameters to the selector matrix to create a selector value and matching that value to the Intelligent Operations Center response plan determines the SOP that is assigned to the event.
Figure 2. Response plan example in Tivoli Service Request Manager console
(View a larger version of Figure 2.)
Current Intelligent Operations Center approach to SOP
An Intelligent Operations Center incident is created in Tivoli Service Request Manager each time an alert-type Common Alerting Protocol (CAP) message is received. An SOP is applied to the incident, and the activities portlet in the Intelligent Operations Center console displays any linked activities.
Although the portlets provided by the Intelligent Operations Center allow some level of interaction with the underlying Tivoli Service Request Manager activities, the interaction is limited and changes are not always reflected in the underlying artifact. To edit Intelligent Operations Center incidents and activities so that the changes are fully reflected in Tivoli Service Request Manager, a link is provided by the Intelligent Operations Center to the Tivoli Service Request Manager web UI. This UI does not follow the general Intelligent Operations Center UI approach and can be difficult to navigate for Intelligent Operations Center users.
Let's discuss an approach to extending the Intelligent Operations Center to support soliciting activity-specific feedback as a form. We won't focus on the development of the form or the business scenario.
The Intelligent Operations Center requires the following major components to support activity-specific forms:
- A registry that maintains a relationship between activities and forms
- A form container portlet that reacts to activity selections
- A mechanism for persisting data structures for an activity instance
- A mechanism for ending an activity
What follows is our approach to implementing these components.
Our addition to the current approach
The primary use case was to present activity-specific data to users, gather data from them, persist that data and use it in the context of a subsequent activity. To support this use case, we used and extended the functionality of some existing Intelligent Operations Center portlets.
We also retrieved extra incident data using the latitude and longitude of the incident to find out what recorded resources were located near the incident. This extra information was stored and linked to an incident so it could be both viewed and modified by different activities as part of the same incident. We provided extra functionality to allow the direct updating of an activity's status, which previously was done through the Tivoli Service Request Manager user interface using a link provided by the Intelligent Operations Center.
The diagram in Figure 3 shows the addition to the current Intelligent Operations Center support for activities functionality. On the left side there is the current Intelligent Operations Center flow and on the right side there is our addition. The numbers in the callouts on the right side represent the sequence of steps that our software components implement. We describe them in detail in the next section of this article.
Figure 3. Our approach on the current Intelligent Operations Center
Example scenario that uses our approach
The inspiration for the presented solution came from a need to support some standard operating procedures related to severe weather emergency management. After the Intelligent Operations Center recognizes an event that is escalated to an incident a sequence of activities will start in accordance with the corresponding SOP.
In reality some activities may require manual steps to be done by several Intelligent Operations Center users, such as the incident operator, the incident commander, or other public safety officials.
The following describes what happens:
- The CAP comes in
- Activity appears for the incident operator
- The operator selects corresponding activity
- A form is displayed which shows resources near the incident that need to be selected
- The operator selects resources
- The activity is marked as complete
- Next activity appears
- The incident commander sees list of resources selected by the operator
- The commander authorizes the resources
- The activity is marked as complete
Activities portlet modifications
The standard Intelligent Operations Center activities portlet code was cloned and modified to support the extra functionality that allows the communication with the servlet that retrieves extra activity data.
After the user selects the activity, the portlet calls the servlet with
dojo.xhrGet method. The servlet URL takes two
parameters: action named
dojo.xhrGet method also loads a callback
function that is invoked when the data is returned from the server. The
data returned is in JSON format. In the same callback function, the parsed
response from the
dojo.xhrGet servlet call is
published with the
Afterwards the activity data can be used by other portlets and widgets
that exist on the same page where the activities portlet is placed. In our
example, the forms portlet, which we describe later, uses them.
Servlet that retrieves extra activity data
When a user selects an activity in the modified activities portlet, the activities portlet publishes information about the selected activity to a Dojo topic. The information published to the topic should be able to uniquely identify the step in an SOP that corresponds to this activity, that is a step type.
We use a concatenation of the step number and the SOP identifier (ID) as our activity type, for example type = WCONFIRMED_20 for an activity corresponding to step 20 in a SOP called "WCONFIRMED".
This information isn't available in the activity portlet, so we used a servlet to retrieve the information from the Tivoli Service Request Manager web services MXWO and MXINCIDENT. We used Tivoli Service Request Manager web services because the Intelligent Operations Center database doesn't store the SOP ID in any of its tables.
The servlet takes a comma separated list of activity IDs as a parameter and returns an array of JSON elements where each element contains the following information about one activity:
Table 1. JSON elements returned by the servlet for each activity.
|sequenceNo||The step number in the SOP (WOSEQUENCE from MXWO web service).|
|ticketId||The ID of the incident associated with the activity. (ORIGRECORDID from MXWO web service).|
|activityId||The activity ID. (WONUM in the MXWO web service).|
|SoPId||The identifier of the SOP. (TEMPLATEID from MXINCIDENT web service).|
|uniqueStepIdentifier||The 'type' of the activity which is a concatenation of SoPId and sequenceNo.|
The forms portlet was designed to fulfill the desire to collect and associate data with an ongoing incident. When handling an emergency it might be necessary to fill in forms for approval of resource allocation, or to record information that was retrieved in one activity that can feed in to another activity at a later stage.
To achieve this, we developed a generic container that could load different widgets or "forms" for entering data or displaying previously collected data. We associated the forms themselves with activities in a standard operating procedure, so when a particular activity in a standard operating procedure came into effect, the container would display the correct form.
The forms portlet has two main functions. The first is to act on a selected activity by displaying the correct form for dealing with it. The form loaded will have it's own logic, so the container does not need to know more than which form to instantiate. The second is to end the activity after the form has been completed.
Instantiating a form
When an activity is selected, a message is propagated across the web page using a Dojo publish. The form container is subscribed to this publish, and uses the information sent to determine the correct form to load. A registry table in the database maps activity IDs to form class names and allows for an API call that passes back the class name of a form widget that is associated with the selected activity. Using reflection, the form container will create an instance of the desired form and pass in the information about the activity.
The form life cycle
Each form widget is a Dojo style widget, with it's own template and collection of APIs. Using the information passed to the form at creation time, the form widget can contact various API's to determine the current incident type, location, etc. Each form can have unique functionality to enable it to handle different activities. For example, one might create a form to show the resources in the area of the incident, allowing an operator to select the desired resources for handling a situation. The form can then persist the users input to the back end using API calls. This persisted data can then be used in further forms for the incident when viewing other activities. After the form has reached its desired endpoint it will notify the container it is finished.
Ending an activity
After a form is submitted, it passes a message back to the container to let it know that its life cycle has completed. When the container receives this message, it calls an API to end the activity for which it is displaying the current form. The container will then sit idle until a new activity is selected that has a corresponding form.
Servlet that updates activity status
This servlet allows the status of an activity to be updated in Tivoli Service Request Manager. The parameters passed are the activityId and the new status. The servlet uses the MXWO web service to update the status of the specified activity to the specified new status.
Additional tables in the database
The following tables were added to the Intelligent Operations Center database.
During handling of an incident, a user can enter data into a form as part of an activity associated with that incident. This registry table records data entered by users on these forms.
This table has one row for each form filled in by a user. The table has the following fields:
Table 2. IOC.JSON fields and descriptions.
|ID||Primary key for the table.|
|INCIDENT_ID||ID of the incident.|
|FORM_ID||Identifies a form in an incident.|
|JSON||The data collected from the user with this form.|
Each form instance is associated with an incident and is uniquely identifiable in the context of an incident.
This associates a form type to a step in a SOP, that is an activity type. The forms portlet uses this table to determine which form to display based on an activity type. We saw earlier that the type of an activity is the concatenation of the SOP identifier and the sequence number. The table has the following fields:
Table 3. IOC.FORMID field descriptions.
|ID||Primary key for this table.|
|SoP_STEP||The type of the activity which is a concatenation of SOP identifier and sequence number|
|FORM_ID||Identifies a form type.|
The IBM Intelligent Operation Center is a software platform that provides multiple integration points through which solution delivery organizations can provide domain accelerators. We illustrated a possible way for software architects and developers to problem solve and implement a solution for activities supporting standard operating procedures. Based on IBM products, the Intelligent Operations Center is solid and flexible enough to add implementations needed by customers.
- IBM United States Software Announcement 212-250 July 3, 2012: Summarizes how IBM Intelligent Operations Center V1.5 delivers new applications and enhanced functionality in user experience, intelligent response, and optimization rules.
- The Federal Emergency Management Agency FEMA website
- IBM Intelligent Operations Center: Providing insight, oversight, and smooth collaboration (developerWorks, March 2012): Learn more about the Intelligent Operations Center's features and benefits.
- IBM Intelligent Operation Center key performance indicators (KPIs) (developerWorks, August 2011): Learn more about how KPIs are modeled, implemented, and tested from this two-part article series.
- IBM Intelligent Operations Center: See how to coordinate your city to deliver exceptional service to citizens. Learn about the features, benefits, system requirements, and more.
- IBM Smarter Cities: Get information about IBM Intelligent Operations Center for Smarter Cities and how it can be used to synchronize and analyze efforts among sectors and agencies as they happen, giving decision makers consolidated information that helps them anticipate, rather than just react to, problems.
- Implementing IBM Tivoli Service Request Manager V7.1 Service Catalog: This IBM Redbooks publication provides information that can be used by clients, partners, and IBM field personnel who want to implement ITIL based Service Catalog processes in an enterprise environment.
- developerWorks Industries: Get all the latest industry-specific technical resources for developers.
- developerWorks on Twitter: Join today to follow developerWorks tweets.
- developerWorks podcasts: Listen to interesting interviews and discussions for software developers.
- developerWorks on-demand demos: Watch demos ranging from product installation and setup for beginners to advanced functionality for experienced developers.
Get products and technologies
- Evaluation software: Find more trial software. Download a trial version, work with product in an online, sandbox environment, or access it in the cloud.
- IBM Smarter City Solutions on Cloud: IBM Intelligent Operations Center on IBM SmartCloud offers a straightforward, user-based subscription service at a single price that includes all costs, including hardware, software, maintenance, support, and networking.
- developerWorks profile: Create your profile today and set up a watchlist.
- developerWorks community: Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
Dig deeper into developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.