Comment lines: Building a Smarter Planet, one operations center at a time

The act of building a smarter city has parallels with the act of helping a company succeed and grow. A central view of operations and the analysis of operational data is one of those parallels. Here is a high level look at the issue of instrumenting operations from the perspective of IBM®'s Smarter Cities™ initiative, although many of the ideas and approaches could relate equally to any business environment as well. This content is part of the IBM WebSphere Developer Technical Journal.


Anthony Bernal (, Chief Programmer, Industry Solutions, IBM

Anthony (Joey) Bernal is the Chief Programmer for the IBM Intelligent Operations Center, a part of IBM's Smarter Cities initiative. He has an extensive background in the design and development of WebSphere and WebSphere Portal applications. He is a developerWorks Professional Author and the author or co-author of several books, including Web 2.0 and Social Networking for the Enterprise, Application Architecture for WebSphere, Programming Portlets, and several others. He is currently helping to build a smarter planet working on IBM’s Intelligent Cities Operations Center.

02 November 2011

Looking at what makes a city run

Earlier this year IBM announced the release of the IBM Intelligent Operations Center for Smarter Cities. This product and platform provides a comprehensive set of functions and capabilities designed to enable the integration and analysis of data across the many departments that make up today’s modern and well functioning city. Around the time of that release I talked about building a smarter planet one city at a time, and how cities can make themselves smarter through instrumentation and data analysis. This isn’t confined just to cities by the way; all types of industries and organizations can benefit from an ongoing analysis of system operations. After all, operations touch almost every aspect of an organization, and efficient operations can help propogate efficiency everywhere. Here, I want to follow on from my previous article with a couple of key points that need to be well understood as you begin to learn what an operations center can provide and how you start to instrument your own operations.

Measuring what’s important

Key Performance Indicators, or KPIs, can be used to monitor important, sometimes complex operations and functions within an organization or domain. The idea of using KPIs for analysis and measurement is fairly basic; however, defining a realistic KPI or a comprehensive set of KPIs that are actionable and relevant to your needs can require some hard thinking. Any form of measurement needs to be clearly defined, not only for what you are going to measure, but how you are going to measure it.

An important rule for defining KPIs is that they need to be quantified to specific measurements. It’s not enough to simply state that you want to know if there are problems with water quality; rather, you have to define specifically what aspects of the quality to measure and which measurement values to compare. This level of exactness is necessary for any KPI regardless of the domain, whether based on some amount of revenue, a specified process, or a physical measurement that can be taken and evaluated at regular intervals.

A second component of creating well defined KPIs is making sure they are actionable in ways that are easily understandable. In Figure 1, you can see that the key defines three simple KPI levels that can be easily understood by system operators. In many cases, these values can be much more complex, but depending upon the audience it might be necessary to define reasonable thresholds where clear explanation can be provided about the level of adherence to the KPI expectation.

Figure 1. KPI heat map and details drill-down
Figure 1. KPI heat map and details drill-down

The IBM Intelligent Operation Center for Smarter Cities focuses mainly on real-time KPI measurement. Historical KPI results, however, are another aspect that can be important to look at for finding other places within operational systems where improvements need to be made. In addition, alerts and notification processes should be put in place when specific KPI values go beyond specific thresholds.

Another important point is to consider your audience when defining and visualization KPIs. An executive user will be interested in KPI changes at a gross level. For example, a mayor will be interested to know when the water quality is affected within a city. Although he or she might be interested in having some additional details, the managers or operators within the water department will likely be the ones interested in lower level details, such as whether pH and other levels are higher than normal and how they compare with other KPI values within the system.

Visualizing on-going events and incidents

Real-time visualization of events is important in knowing what is going on at any given point in time. These events can involve most anything that occurs in a city and that can be reported, such as traffic, energy, water, safety, fire, as well as weather or natural disasters that could occur. An event can be submitted in an automated fashion from other systems when specific triggers occur. More likely, events are input and updated manually by operators on duty within specific citywide operations or call centers, from mobile resources directly in the field, or by citizens commenting on community issues like graffiti, potholes, or potential sanitation issues.

Being able to view and operate events in different ways enables operators to both visualize and prioritize them based on a number of parameters associated with each event. Figure 2 shows how this visualization can occur in a comprehensive and cohesive way.

Figure 2. Table view and GIS map visualization of identified events
Figure 2. Table view and GIS map visualization of identified events

One important aspect of managing events is to ensure that a standard is used in reporting and updating events into the system. Within the Intelligent Operations Center the Common Alerting Protocol or CAP standard is used to manage events within a city. This standard defined by OASIS is a general format for exchanging emergency alerts and public warnings. The CAP standard can be simplified to just a small set of required data fields, yet can also be extended to include the much more rich data required by GIS and multimedia information sharing. Basic event messages can be sent with a minimum of information, such as date/time, status, scope, category, type, severity, certainty, and urgency. Custom applications for PCs and mobile devices can be easily built to enable the easy creation and submission of event messages for many different types of situations.

Knowing what events occur is only the first half of the equation. Understanding what actions to take when responding to these events is the other half. Public and government operations often refer to these actions as Standard Operating Procedures, or SOPs. These are a set of predefined and formalized workflows that should be followed by operators and responders when events do occur. These flows are generally documented in many operations centers, however many of them can be automated to provide a more consistent and efficient response to emergency situations.

Operations centers everywhere!

The idea of an actual operations center is not a fit for every situation, but there are many situations within various organizations and industries which could benefit from the real-time visualizing of ongoing operations. Factories, manufacturing, and processing plants all have the need to measure real-time KPIs and events within a large industrial complex. Industries such as shipyards, docks, and large scale transportation warehouses are also good candidates for the capabilities that an operations center can provide. Another could be in industries or organizations where public safety or the security of large groups of users is critical, such as stadiums, amusement parks, cruise ships, or other entertainment venues.

In non-city use cases, the event types and KPI values will typically be completely different from what you might see in a city, but I have no doubt that as more use cases are realized, both industry-specific patterns and common-to-all (or to-most) patterns will emerge. For example, shipyards might require updates on the status and location of vessels, or the loading and off-loading progress of each. Stadiums, amusements parks, and other entertainment venues might need to process events and incidents regarding everything from public safety and security, such as a public disruption or restaurant fire, to much more mundane events, such as an overflowing toilet in a VIP lounge.


My objective here is simply to get us all thinking and talking about what is possible. Some use cases already exist, but many more can be realized as citizens and industries start to apply the vision of a smarter planet to their particular area of expertise. Domain specific applications will continue to drive instrumentation technologies forward and help everyone who needs operation center capability within their environment. Already some specific products have been released, such as IBM Intelligent Building Management and IBM Intelligent Transportation, with more on the way. It is everyone’s job to drive these initiatives forward into more industries and really make the planet smarter.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

Zone=WebSphere, Web development, Agile transformation
ArticleTitle=Comment lines: Building a Smarter Planet, one operations center at a time