State-full vs State-less

We cut a larger business process into smaller pieces and create an Appian process model for each. This is from a very high level and a misses many details, but we do almost never have any issues with this approach.

I am not a fan of trying to use Appian as a pure UI layer and reimplement all the process functionality using a database.

If you cut your larger business process into small chunks it means that you are keeping the state of the that process in the database, which means your larger process is not BPM driven and APPIAN as BPM platform is not utilized (in the BPM sense).

What is your criteria for large vs small ? 

I use Appian very much as a BPM platform. In the old days, before 2014, records did not exist and we had to keep state in process instances. Nowadays, I do a hybrid approach where I control the process using Appian BPM, but still persist the data to the database.

Large vs. small ... I typically try to have one model per each user input task. But not as a hard rule.

I guess it would be fair statement to say that having one PM per user input task is not a BPM implementation, as any back end is doing approximately the same without all the bells and whistles of BPM. Your main state management and logic is out of a PM space, so... why APPIAN (just in the sense of BPM) ?  However the other way around, having the state and logic maintained in a PM serves the idea and the mission of APPIAN. While the process is alive, use process based records for reporting. When the process is over do whatever you need with the generated data... this was my understanding of the APPIAN platform.

I did not say that these smaller process stand alone. I create larger dynamic processes driving integrations, automation and user tasks.

I completely agree that it is the idea of Appian to put the business process into software. The implementation is just not that dogmatic and more of a hybrid.

appian.rocks/.../

Appian is now more than BPM.  And even if it weren't, if it were simply BPM, I'd still use the best approach for my use case rather than the best approach for my tools.  I wouldn't care if I was maximizing the potential of Appian if I was doing it at the cost of a less performant system.

The processes can be long, they can be complex, they can have loads of exceptions, loads of different branching paths, and they can call multitudes of other processes.  That doesn't change.  All that changes with Stefan's approach, which I think virtually all us old-timers agree with, is how long the processes park in one spot doing nothing but taking up RAM.

Let's call it state-full for as long as it needs to be state-full, and then not.  Why not let the DB contribute something?  Especially if you get a better product as a result.

But.... how can one tell what is the best approach ? Going  state-full or going state-less ?  How do you weigh the pros and cons ?  The issue of idle processes, waiting long time for a trigger should not be a criteria, as the framework should be able to hibernate such processes with minimal overhead. .However going state-less requires mixed structure of state management as part of it is in the data layer and part of it is in active processes, so the art of breaking up your long lived process to shorter ones is artificial in nature and breaks the tooling of BPMN. So I guess Stefan's approach of keeping small short lived processes, is actually a shift towards the state-less approach, towards the data driven world, giving up all the goodies of BPMN.  I can totally agree to this approach if you need to scale horizontally and give up the state-full world, however if you are OK with vertical scaling then why do that and and still be fined with a premium cost of a BPM platform ? 

It sounds like you're saying "Why bother with Appian unless you can have long-lived processes?"  I've never heard anyone that actually liked the idea of long-lived processes before.  I don't see how it breaks the tooling of BPMN.  You're making really good processes and denoting them correctly.  Part of what makes them such good processes is that they stop in a timely manner.  How does using software to implement an efficient process ruin the functionality of the software?

And if you want to leave a process parked on a user input task for three days before someone completes the task, you can.  It's in there if you want to do it that way.  You can keep the goodies of BPMN.  But don't you lose more than you gain overall?

Plus, why Appian is also SAIL, mobile ready with no additional dev, countless integrations with other systems and vendors, process mining, RPA, IDP, and several other features; apps that can be built 10X faster than by traditional code.  I'm OK with not using BPMN to some theoretical ideal.

There's also folks out there who don't use the Process Modeler or process models for anything if they can help it.  They run ALL SAIL.  You can build Portals that way too; in fact you basically have to.

Not arguing all other goodies APPIAN has to offer, just questioning the BPM architecture. If you break your long lived process you have lost the view of your entire process (there is no a single canvas you can see your process end to end). You need to look at multiple PMs, and create a network of "chained" processes and/or cross boundaries via the data layer, your state is a collection of sub-states, some of them  live  in short-lived processes and some of them are parked in the database - quite a mess. Your short-lived process instances  are ''almost" equivalent of traditional web service calls (perhaps more capable, however simplified process models).

In that sense this is a "waste". If that all you need from a BPM platform then APPIAN/BPM is overkill. 

Thus, if your application is BPM one you should go APPIAN all the way and not break up your long lived process. Unless there are other factors which are strong cons, like hardware constrains, or other limitations imposed by the platform (like reporting, process upgrade concerns etc).