Skip to main content
H
humil914
January 24, 2023
Question

State-full vs State-less

  • January 24, 2023
  • 18 replies
  • 0 views

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  ? 

18 replies

stefanhelzle0001
stefanhelzle0001
January 24, 2023

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.

H
humil914Author
January 24, 2023

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 ? 

stefanhelzle0001
stefanhelzle0001
January 24, 2023

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.

    davel001150
    davel001150
    January 24, 2023

    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.

      H
      humil914Author
      January 24, 2023

      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 ? 

        davel001150
        davel001150
        January 24, 2023

        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.

          Terms & ConditionsAccessibility statement