In any case I will be subscribing to your
feed and I’m hoping you write once more very soon!

Sounds like we are thinking alike. The mobile phone literally transformed my life when I was a field sales representative. No longer did I have to stop at the nearest hotel or gas station pay phone to make my calls. The smart phone can have a similar impact. However, it has to be easy. I for one am not going to navigate SFDC and type in a bunch of notes on my smart phone. It is hard enough on my notebook computer. But if we let sales people create their own wizards, an interaction pattern that works for them, and tie it together with voice to text and thumb clicks, gone will be the days of typing meeting notes on the airplane, for example. Think of getting your report done, capturing all the data, in the taxi cab on the way to the airport and watching a movie on the plane!

Mark

I especially like your notion of a new interaction pattern. One way to approach the solution is by asking what salesteams really need the most when they’re on the road in front of customers and prospects.

My husband was a sales road warrior for years. Because he worked in complex technical settings (large, lean manufacturers and their first-tier suppliers), he found he really wanted immediate answers. He wanted instant access to the information that would help him close a sale, on the spot.

Voila–something mobile devices are great at! But, the app *must* be sleek and simple.

We think sales teams will use mobile in this task-oriented, simplified way. What is your opinion on that approach? Could a (useful) behemoth like Salesforce be adapted practically to mobile?

Thanks.

This posting discusses the various criticisms of BPMN 2.0 and proposes that the real issue isn’t the notation, but how vendors chose to implement the specification….

We really dug into this and bet you likely will too….

We’re simply answering the gauntlet you (plural) have thrown down. When you announce a project and give it a mission — in this case to replace BPMSs — you have to be prepared to take the resulting discussion.

What call “trash talking;” we call it making our points in an clear, forceful way. Interestingly, the Activiti people have stopped engaging. Is that how an open source community deals with feedback it doesn’t like? How about we have a conference call, invite the community and let Tom and Michael discuss it?

We used only content that had been presented jointly and which has been posted here on our blog for months.

Alex

I have to admit that I don’t get why you’re being so defensive and vitriolic about Activiti. it amazes and confounds me, Alex, that you came out with guns blazing a few mere hours after Activiti was launched…

For my part, I don’t agree with Tom Baeyens’s assertions that “Standalone BPM is dead”. I think we can all agree that many processes can encompass business activities that transcend different silo’ed systems (ECM, ERP, CRM, etc.) and it’s therefore preferable for certain organizations to have a BPM system that lives “outside” and can orchestrate these activities.

If it’s just Tom’s comments that have your feathers ruffled, be comforted in knowing that those are simply the opinions of an individual, no need to attack the Activiti project (or Alfresco) based on that.

I do have some points to make with regard to your webinar…

In the presentation, Mike Monitz incorrectly suggests that ECM vendors see all processes as being composed of content. I believe this to be a fallacy, more importantly, it’s an attempt at invoking FUD to try to make such assertions.

I would go as far as to accuse Mike of creating a point of contention where, in fact, none exists. I know, how dare I accuse a VP of Marketing of such a vile thing!

When wielding the BPM hammer, not all problems are BPM nails and I’ve never known an ECM vendor to claim that the workflow engines they embed are intended to supplant the need for external, standalone engines.

At Alfresco, we embed JBoss JBPM and will switch to Activiti when the time comes. This offers us the opportunity to continue to offer powerful document-centric workflow processes while leveraging the newer BPMN spec and switching to Apache licensed code instead of LGPL, something our customers and OEMs desire.

Too bad ActiveVOS isn’t open source, it would’ve made things easier.

Making a case for “embedded” BPM, I noted in the webinar recording that someone asked about UI integration and you answered that such a thing was not possible.

- Why should I leave the ECM UI just to review or approve a document?
- How does one edit document metadata from within a process step? What if the metadata model changes, must we update the process to support it?
- How does authentication and authorization get seamlessly handled?
- What if the process need not touch systems outside of the ECM repository?

While I would love it if we could get deep UI integration, metadata editing and SSO with ActiveVOS and other standalone BPM engines, it’s easier and more practical for customers when we can include an embedded BPM engine can address these needs.

Past experience with Alfresco’s customers has taught me that a great many processes can be entirely executed within the context of just the ECM as they’re internal to how content is produced. What that tells me is that while there may be overlap in some areas, there are justifiable reasons for having either embedded BPM, standalone BPM, or more likely, *both*!

I conclude my diatribe with the following:

I’m tired of hearing about mutant chicken-fish and I would appreciate less trash-talking and more constructive discussion and debate.

Alfresco and ActiveEndpoints had been in partnership conversations prior to the Activiti announcement but things have gotten quiet. I’m extending an olive-branch to see if we can rekindle the relationship and address the actual needs of customers (UI integration, SSO, deeper metadata support, etc.) and not the needs of our respective egos.

Finally, the diagram seen on slides 9 & 10 of the webinar is copyrighted Alfresco images, kindly cease using it. Busted!

Regards,

Luis Sala
Alfresco Software, Inc.