Monitor the process not the machine

Every application logs a varying amount of information about what occurs when users or other systems interact with it. These logs are sent to a database or a file location - it doesn't really matter which because what you end up with is a silo of data that means nothing unless correlated and placed in the context of an overall business process. With most users interacting with anywhere between 5 and 15 applications daily, you'll have a similar number of these silos - all containing different pieces of data, which don't tell the full story.

So why not just have this information stored in the same place and correlated to give you a single process based view? Well, most software products deployed to collect desktop events only look at operating system messages. These types of events are only good at showing you what applications are running and perhaps how people are using the clipboard to transfer data. What it doesn't give you is the context of each application, such as which customer record the user is looking at in the CRM system, what fields they are changing, which field they just copied and pasted etc. Without this information you're logging data that really isn't showing the context of your business process - so why bother at all.

With the launch of OpenSpan Events, a passive monitoring platform with a simple upgrade path to full automation capabilities, you now have the ability to monitor exactly what is happening within every application. You don't even have to alter your existing applications - OpenSpan runs in process and looks at events that are fired down to individual objects such as Text Boxes, Buttons etc. Events can be generated automatically (generic events) or at specific times within an overall process (custom events) - both types sending the contextual information about the event to a central place on your network.

Events are configured centrally via the OpenSpan Studio visual development environment, with the next release adding support for building everything within MS Visual Studio. Projects are deployed to user desktops in a rapid and secure fashion - with remote configuration capabilities and integration to Active Directory, you have complete control over your infrastructure.

Client machines publish events from the desktop using a publisher defined in the OpenSpan Studio. This controls how information is transmitted and where it's stored. The default setup allows you to publish events via message queues (MSMQ, IBM MQ, Tibco, WebMethods, WebLogic), to a file or via SOAP. The publishers are pluggable mechanisms, so it's possible to push events in any format to any existing system you may already have in place - so events can be easily communicated directly to leading BPMS, BAM and BI tools.

Visibility of the collected events is possible from the tool of your choice - the default setup has OpenSpan Events push data to our Events Collection Server where the data is written to a database (MS SQL or Oracle). The database is customised automatically based upon the event data being collected and is configured via the OpenSpan Studio environment. The schema of the database is well documented and can easily be used by any reporting tools on the market to visualise the status of your process.

For more information please visit www.openspan.com or email sales@openspan.com

Understand the process

From time to time people will ask me what's the most important thing to get right before you start down the path of automating a process (or part thereof). I've finally decided that actually the best thing you can arm yourself with is knowledge of the existing process.

Isn't that so obvious? Well it maybe to most people but why is it that time and time again projects are started and in some cases finished, without first of all understanding where the problems are in the initial process. How can you fix something when you don't know where it's broken? The answer is you can't and that's why you find these projects either fail or you end up with massive delays as you're forced to go back and understand the initial problems.

With a platform like OpenSpan, it's possible to rapidly prototype a solution and run it past the business within what could be a matter of hours. This approach helps to show the business users what they'll actually receive once the project goes live and keeps your timelines as short as possible. Francis Carden refers to this as failing faster and I tend to agree with him - it's a nice way to learn what works and what doesn't.

I always tell customers that I want to see the process in action. Show me how you do it today, let me watch the manual task, let me understand the pain. More often that not, with this knowledge we can make tweaks to the process very quickly that will have a massive impact when it becomes automated. This initial work doesn't even have to take up a lot of time - I find that with the small processes we automate, this work can be completed anywhere between 1-4 days (including documentation).

Another obvious point to make that just about everybody fails on, is ensuring you are using like for like systems across your environments. So many projects are delayed by environments being different between development, test and production. These differences are picked up earlier in the development cycle if you've seen how the process is completed the "manual" way and it's documented step by step (including screen shots).

OpenSpan has recently launched the OpenSpan Events product which allows you to monitor generic and custom events from virtually any application. This product can help you understand the current process by monitoring exactly what users do within each application and logging it to a central place. Analysis of this data will give you a good understanding of the problems with the process, for example it's possible to see when a user cuts and pastes the same piece of data across different applications. You could even use OpenSpan Events to check that the systems are the same between your different environments by having it log version numbers as users interact with the applications.

One of the major benefits of using the OpenSpan platform is to decrease the time it takes to integrate your applications and automate your processes. With a typical project lasting around 5 weeks from start to finish, if you're not prepared to start this rapid development approach you'll see project times extended and you'll loose some of the benefits we bring to the table.