Posts by DavidKelly

These days, everywhere you look there’s more and more information bombarding us. Our email inboxes are flooding over, blogs, websites and RSS feeds provide a constant stream of updates, and new social networking sites such as twitter.com even allow your friends and family to track every movement you make – from running out to Starbucks to kicking back and watching the latest thriller on DVD. No matter how you slice it, the general public is exposed to a whole lot more information today than they were ten or twenty years ago.
Of course, it’s the same for businesses – only it’s worse. As I’ve explored in previous columns, today’s businesses are consuming, generating and repurposing huge amounts of data these days. And it’s not just coming from traditional order entry-type applications or individual users. Today, organizations have to deal with a wide range of data sources that are constantly delivering new information. The range is almost endless-it could be financial market data, network events, application data, RFID or sensor events, Web/click events or just about anything else. The effect is the same-many organizations need a proactive way to analyze, process, and act upon this ever-expanding volume of information flowing through the company from a myriad of (potentially time-critical) sources.

Over the years, the view of what IT was (and is) has expanded. Initially IT was a mainframe computer, a few programmers, and batch programs that generated reports for a limited number of internal employees. Then it was mainframes and terminals, with applications that handled the most mission-critical (or at least computationally-critical) portions of a company’s business process. These were used by even more employees. Then, over time, IT evolved to mini-computers with many users, personal computers for all employees and now Web- or Intranet-based solutions intended to be used by employees, partners, customers and just about anyone else.
At the same time that this expansion has been happening, there’s been an expansion of the notion of the role of applications, as well as an expansion of the importance of application management. For example, initially, applications were managed centrally, but over time organizations have either stopping managing them (remember client/server?) or invested in IT-oriented solutions that can now package, deploy, and manage applications across a wide range of systems and users.

Sometimes people can look at something and come to completely different conclusions. Take my ten-year-old son. To him, if he has to do something (or if he’s required to do something) it’s not worth doing. He can always think of something else that’s more interesting or more worthwhile.
However (perhaps just because I’m a parent) I believe the opposite. That just because you have to do something doesn’t mean that it’s not worth doing. In many cases, the things that we’re required to do can end up being very beneficial for us. It’s just that it’s not always obvious how they’re beneficial.
I believe that the same thing principle operates when it comes to compliance, IT compliance and auditing. By now everyone’s aware of the impact that regulatory and industry requirements have had on just about all sizes of organizations. And while the majority of regulations and compliance requirements apply to public companies, in many cases even private companies have been swept along on the compliance tide. Over the past few years, all types of organizations have had to implement a wide variety of compliance-oriented tasks, steps and processes to help them define, document and manage data and processes.

Doing performance management correctly is like trying to get my kids to wash their hands. Sure, I can create a process or rule for it: When our hands are dirty, we wash them. Then I can ensure that the components of the process are available and responsive: There’s soap by the sink and the hot and cold water turn on easily. But even when I’ve set everything up, and have the metrics established (we need to wash our hands daily!), how can I be sure that they’ll be achieved? And if they are achieved, are they being achieved correctly?
For example, it’s pretty easy to identify when my older son isn’t meeting our performance goals: His hands are clearly filthy. But it’s a bit tougher with my younger son: He did wash his hands. But did he use hot water? Did he use soap? Did he actually scrub for a reasonable period of time (or did he simply pass them under the water)? It can be hard to tell. I’ve also discovered that there’s usually no adequate feedback mechanism to help me identify when there are user or system problems. For example, we can be out of soap for days in their bathroom and I’ll never hear about it. Or they may decide on their own to use one of those liquid hand sanitizers instead of actually washing their hands. It’s hard to know sometimes.
The point is, even with the right process (or application) and tools, the effectiveness of the result really depends on actions of the users. If there are user failures (like failing to report missing soap, using cold water, etc.), then the resulting process is going to be ineffective.
As I will explore in my next column, it’s the same with enterprise performance management and an organization’s applications. When enterprise applications like SAP, Oracle or Seibel aren’t being used effectively and efficiently by users, the business results will suffer.
One solution to this problem is putting solutions in place that can collect and manage information not only on your applications, but on the user experience of the users using those applications. Let’s look at what that means.
Of course, you’d want to start by collecting traditional application management-related information like response time and availability. You’d also want to know the transactional response times-for example, how long does it take the application to respond after the “enter” key is pressed? But-and here’s where it starts to go beyond traditional management solutions-you’d also want to know how long it takes for users to navigate through the application screens.
Are they spending too much time on difficult to navigate or complete screens? Of course, you’d also want to collect information on which applications (and transactions) what people are using. It would also be helpful to collect information about quality of the users’ experience and any errors in the infrastructure or application, whether they’re cause by the user or by something in the IT environment. For example, perhaps users are getting errors trying to connect to certain applications or databases, but such errors aren’t getting reported.