We know the answer, but what was the question?

Peter: "SAM means service activity monitoring".
Paul: "So, you are going to monitor service activities"
Peter: "Right. That's what I said."
Paul: "But it's two different things, isn't it?"

A typical hallway chatter. You just want to grab some coffee and then you bump into somebody, who completely turns your world upside down. It's a small question, but in this case an important one.

The last week I spend thinking about SAM infrastructure, basically getting an idea on how SAM might fit into different application/service landscapes. So you have SAM "monitoring" what your services do, and you put instrumentation code pushing "events" to SAM. Anything that might potentially be interesting to SAM, but it should figure our itself what's considered relevant. Hence the CEP backup behind it, right?

Fortunately I got distracted by some console work (moving the jBPM console to GWT), which made me think more thoroughly about what information will be relevant to people using the BPM console. There is process definitions, from which you create process instances, which again consists of work items (aka nodes). You can't tell upfront what path of execution will taken, neither you know what particular node types do.
At least from a monitoring perspective, you are forced to keep a more general look onto things. Coming from the technical side, this quiet naturally leads to a static view onto things: Process start and end dates, overall number of executions, average execution time. These sort of things.

But is it really what console users are interested in?
If I put on my "chief of sales operations EMEA" hat, I would probably like to see key performance factors relevant to my business. This might be anything from missed opportunities to SLA breaks of certain partners. But what are key performance factors?
Especially without knowing the business domain beforehand, how should I (the console developer) enable "chief of sales" to get the information relevant to him?

Let's look at the catchy title again: If I would have known upfront what you are going to ask me, I could have prepared myself. But I don't, and I never will.
I am just "Service Activity Monitoring" and you are monitoring service activities.

Now that we know "chief of sales" actually exists, we can start wondering about what actually enables him (or her) to do a successful job. IT is just the tool set here. If we do that, we will probably see that any business is goal driven (did we achieve it or not?), it has a number of participants (partners, systems, colleagues)
and suffers from derivations (exceptions, compensation). To "chief of sales" the underlying IT infrastructure is irrelevant. It exists and enables business, that's it.

Back to SAM.
To SAM the infrastructure exists but is irrelevant, too. Things that happen inside or outside your company can be relevant to the business. SAM just makes it visible to you and raises your attention.

Paul: "Great, sounds like a match."
Peter: "Yes, it is"
Paul: "But what's with the BPM console then?"

Well, the work on the BPM console made me realize that "chief of sales" questions are not restricted to BPM. It covers anything that enables particular business aspects. IT is just an implementation detail here. And so is BPM. Or ESB, or web services. But still all of these SOA components will provide information relevant to the business. And so does the BPM engine.

For the BPM console it means, that it doesn't need to be tight to the BPM domain. I believe that to a large degree general service information (goals, participants,derivations) which SAM can deliver would be sufficient. However, we may still add pluggable console components that are specific to BPM or even proprietary to jBPM. But to begin with, we should focus on a general monitoring concept.

Paul: "OK, back to work."
Peter: "Yep, talk to you later."