It is my understanding that the "Appian" way is writing state-full applications - where the processes model instances hold the state of the application.
The main drawback is of course that being state-full means vertical scalability only.
However, given current state of the horse power provided by standard hosting and the nature of Appian application this is a non issue.
However being state-full means that long lived running processes cannot easily be upgraded in order to introduce new functionality.
Reading the documentation, I am aware about an upgrade process which requires developing per upgrade plug-in which needs to be submitted and approved by APPIAN.
Development of such a plug-in requires Java and Appian internals know-how, as well as locally deployed instance.
This is of course beyond the rich of an average Appian developers.
What is your stance ?
Discussion posts and replies are publicly visible
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/.../