1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 09 February 2017
  5.  Subscribe via email
From E. Scott Menter: We regularly talk about BPMS “core” features, such as BPMN compliance, rules management, and predictive capabilities. But could it be that UI/UX development is the single most important capability of any BPMS?
Accepted Answer Pending Moderation
From the definition at this site "A BPMS is designed to support the activity of BPM. However there are many things a BPMS can do that are not BPM."

... examples being the management of both structured and unstructured work, assessing progress toward goals/objectives set in Case run-time environments (making Case another name for BPMS)?

My take is the UI/UX is the single most important capability of a workflow management system.

As for UI/UX development, we can't expect all vendors to agree on what a UI/UX should look like so whatever gets users on board and keeps them on board is fine.

My preference is something simple . .

See "The Last UI You'll Ever Need for BPM"
  1. http://wp.me/pzzpB-lz
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
I used to think that the User Interface of a Process Engine was a Core Capability, but on reflection it's the API for Interacting with Processes that's really the Core Capability.

Any User Interface is a straitjacket that mandates one flavor of User Experience, and what I've learned over the past ten or so years of implementing BPM solutions is that there are as many flavors of desirable User Experiences as there are Process Participants.

Process Engines that are tightly coupled to their UIs (you probably know which ones) are inevitably a pain to work with when your clients wants a UX other than that which came out-of-the-box. A really good API gives you the ability to craft multiple UIs for multiple UXs with little headache..
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
An API is a good thing to have, of course. But the idea that we're going to continue to treat BPM systems primarily as state machines, with the user experience added by programmers, is not a direction I believe will be attractive.

The world has plenty of ways (such as CSS, for better or worse [I know, mostly "worse"]) to customize a user interface without resorting to APIs or other programming-oriented approaches.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Yes it's is the most important aspect of the resultant BPM supporting applications. It should be part of the architecture that orchestrates data to be delivered and collected via the UI (includes mobile) and as previously indicated be Adaptive.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
If the user interface is not clear and/or difficult to use, users will not use it [or not want to use it].
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Brian Reale
Blog Writer
Accepted Answer Pending Moderation
I agree with John. The days of the generic user experience are over (if they ever really existed). We live in a world now where the API is king. Any system where the front end is not completely decoupled from the API will fail, and fail in the relatively short term. User experiences are changing rapidly. Generally, the less sophisticated the customer and/or application, the more important is the front end UI. However, these are also the customers with the greatest associated risk factor because they do not understand that the UI experience needs to be perfectly suited to the exact job at hand. Processing compliance issues on a gas pipeline cannot possibly have the same UI as processing auto-loans.
No a process is a process is a process. Sure compliance issues different but you customise as required. As for failing well not our experience the UI readily changes as new ways implemented as proven over 15 years. The UI is created as custom for specific instance of use in such way as easy for user to use entering information only once...it is simple yet powerful. Your way sounds like very complex sure to scare users...?
You need to visualise that the new outside in BPM approach works to support users and legacy the slave used as required sure that needs API's. All orchestrated as required even direct from the integrated UI. By the way it's generic supporting task types that are key not a generic user experience....every user experience will be different ...and liked...if not they can change...quickly as no APi's involved.

Looks like different definitions of UI are appearing here.

Suppose I am a worker whose sole job is to go to government internet sites, access an editable pdf form (many of these depending on the various sites worker goes to).

What's the UI?

Is the internet browser, that the worker uses to navigate to a site?, is it the PDF viewer API ? or is it the particular fillable PDF form?

Notice the approach our group took was one screen (to-do list on one side, calendar on the other). We call that the UI,

We call tasks that post "process steps" and each of these steps has various attributes, one of which is a form (one or more) that lays out the data fields that need filling in.

Do we have one UI or do we have 1,000 ?
"The days of the generic user experience are over" - I agree, but try telling that to the low-code crowd :-)
Karl. It's really simple the UI is from web or client server which gives required information to help do the work and then enter new information. There will be many as required each customised (could be 1000s) ready to be created when needed. The to do list is sign on form informing the authorised user of work available. Looking at the example you gave there must be reason to get a pdf which someone wants which would start the process. So it appears on his list. He clicks and taken to another UI which allows him to access the pdf from wherever (could be automated) then if required extracts info and enters or maybe just clicks to pass on to someone else maybe by automated email. The to do list automatically removes that task. All recorded who did what when. The information extracted used or even just the pdf whatever goes through the next steps. Every UI is a form all linked within the architecture with a process engine automatically orchestrating required data for all users in the end to end process.
  1. John Morris
  2. 3 years ago
  3. #3306
+1 @Bogdan: ["The days of the generic user experience are over" - I agree, but try telling that to the low-code crowd.]
Got it..

A UI is " . . . . a form that is context/situation-appropriate for an element of work. i.e.. display of data or pickup of data or both"

That said, we probably need another word (shell? framework? application system?) to describe the run-time environment users find themselves in following log-in (whatever that may be, including a Case Management System or a BPMs).

As Alexander points out below, we need at least two of these (web, mobile) and I would immediately add a 3rd called desktop.

Hopefully the environment we are talking about does not have to be different from one silo to another, one corporate division to another. We want it to be intuitive, easy to master and friendly such that users actually find it more productive/convenient to get their work done than by any other approach.

Then, "development" for those who like to write code or for those who do not, ends up with steps, logically connected by directional arcs, with any number of UIs (read forms) as attributes to steps.

Bringing all of this together requires different skills depending on the software you are working with (ordinary users with some help from IT, super-users, database programmers, application development programmers, in some cases, maybe alchemists).

Yes in agreement but the last comment is where we discovered that building our platform contained all requirements in one environment allowing business knowledge to build the end to end process...no coders for core including UI forms. However where UI is being used by external users then a web designer skill is advisable but internal are simple functional easy to use forms without marketing clutter. Another advantage with all forms creation and data in one architecture is building intelligent processes to aid decision making is possible and we think more to come.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
The end user interface is something that will ultimately decide about the success of implementation. Even the most technologically sophisticated solutions will fail if the interface is crude, slow and unintitive. The question is how to approach the case of UI? To customize everything? That's a lot of work. Not only to adjust, but also to maintain and deliver each and every business application. To standardize with out-of-the-box functionalities of BPMS? That would require a system to look at least good-enough and initial resistance might be hard to come by.

A sort of compromise can be observed in SharePoint-based systems where look & feel settings (colors, logo) of SharePoint sites can be inherited by BPMS and therefore two birds are killed with one stone.

From my perspective one thing is clear. If you ask 5 people on the meeting how would they like for interface to look like, you'll get 6 opinions on that.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
From the point of view of BPM-suite tool architecture (which is suitable for a digital business execution platform), I recommend the following principles:
- decouple UI from other capabilities to open it for innovations
- offer out-of-the-box min 2 options (e.g. web and mobile)
- use publicly-available API for decoupling to attract 3th parties
- use standardised API (if any) to attract investments
- be able to auto-generate as much as possible UI components to simplify prototyping
- be friendly for test automation tools to reduce testing cost
- be friendly for RPA tools to reduce integration cost
- have template functionality to allow enterprise-wide standards
- consider UI as one of the coordination technique - manual coordination

This is not exhaustive list and, please, feel free to enrich it.

Great list Alex - we're doing it all, short of building our own API. I'd add one point on the list - by far the most painful:
- hire that elusive UX/UI designer able to empathize with so many user personas that are present in so many corporate environments.
  1. John Morris
  2. 3 years ago
  3. #3307
+1 "decouple" - UX and BPM are two different things.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
John and Alex nailed it for me. UX/UI and process engine are core capabilities of a Digital Business Platform and they must interact via APIs.

It is a mistake to strongly couple a BPMS to interfaces (and while at it, to strongly couple anything with anything - the time for monoliths is almost up and a Great Unbundling will come). Core components of a DBP (process engine, databases, UX/UI layer, BI, DMS, whatever) must be loosely coupled via API / webservices etc.

And while we're at the "UX/UI is core" conclusion... anyone notice how the "low code" movement departs so much from this?
CEO, Co-founder, Profluo
This is what I'm sayin'. +1
  1. John Morris
  2. 3 years ago
  3. #3309
Once more again ... +1@Bogdan - "decouple" - UX and BPM are two different things.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Why bother? Robots don't care about user interfaces.

Oh wait, the goal of BPM isn't to make people useless by automating everything?
Sharing my adventures in Process World via Procesje.nl
Some robots do "care" because they will

1. reject incoming signals via data exchangers/parsers if not in the right format
2, see any signals they send out via an intermediate data exchanger/formatter as being rejected if not in the right format
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Scott Francis
Blog Writer
Accepted Answer Pending Moderation
I'm chiming in late here, but I think the answer is pretty simple.

First, A good BPM(S) should provide a good user experience. It is a core feature to supply at least a basic and appealing user interface.
But why?

  • Because part of the philosophy of (most) BPMSes is that they support quick and agile development of processes. Which includes the presentation to users - e.g. user interfaces.
  • Doing that quickly usually implies having it as part of the core functionality of the platform- a single IDE so that the same person who draws the process diagram can quickly implement basic screens that incorporate and interoperate with the process diagram. (or are incorporated into the process diagram.

Second, a good BPM(S) should provide a clean API for accessing all of the interesting features. In particular, a clean API for building User Interfaces outside of the product and building integrations from outside the product. But why?

  • Because some applications of process need to integrate into existing products and user experiences
  • Because some applications of process require very customized treatments (think consumer facing process elements)
  • Because sometimes the basic UI just isn't good enough for final delivery
  • Because it is important to support the decoupling use case described above in other comments (which is release dot the first three bullets here)

Third, UI/UX is incredibly important. It is the main focus of investment for BP3, for example - rather than engine and other aspects of the BPM stack. We think the commercial and open source vendors produce pretty awesome product for the back-end. But we like our approach to UI/UX better than any of the BPMS vendors we work with (sorry!) and therefore we produce a UI/UX stack that integrates with any engine with an API. I suppose an interesting strategy would be to scrap the "core functionality" and just use Brazos as the UI/UX stack. (A variation on this is all the folks who go straight to angular etc. and roll their own... but there is a bit of secrete sauce involved in building great UIs for process engines vs. great UIs without an apparent process.

Why is UI/UX important? it's what the participants in the process experience. In the same way that the steering and navigation in your car are important, the process UI/UX is important. And I'd also offer up that it isn't just the nuts and bolts of technology for building UI that matters. I've seen horrible angular- and react-based UIs... and I've seen great ones. You have to put in the work and the insights to make a great UI/UX.
  1. John Morris
  2. 3 years ago
  3. #3310
Cool business model where the BPM engine etc. are a given, and the focus is on the UI/UX. Let the vendor worry about the execution semantics, while you are wrangling the messy world of humans and work-to-be-done. I'm not sure which is more difficult.
Brazos is terrific. And the idea of a pluggable UI in general is a good one. But it's kind of like replacing the remote control that came with your TV with a generic variety. The generic one may do some cool things, like also control your other devices, or glow in the dark or something. But inevitably it's missing the one button you care about most (in my case, it's the brightness controls: I hate looking at a bright screen in a dark room). So you leave the old one lying around anyway. And now you have two.
@John - I tend to think that the UX is the far more difficult undertaking.
Interestingly, with Brazos you usually get functionality not provided in the base BPMS platforms ;)
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
What's an engine? In our discussion here it is synonymous with BPMS or BPM product. A stricter definition would say that the "engine" is a BPM execution engine only. In the diagram in the Dimensions of BPM Technology Diagram I put UX as part of tooling and integration,i.e. outside the BPM Core. Good engines and good UX are both really hard to do. As several correspondents have noted above, "decoupling" ensures that each technical domain can receive the attention it deserves.

We could relax our original definition a little,and ask if "UX is an essential capability of full BPM product", and as many people have pointed out, the answer is surely yes. Relax even more and we get to DBP, or Digital Business Platform. Or any software application. Or even physical machine and the world of design.

But is there anything uniquely "BPM" about UX that is not also true of any other technology? UX is UX is UX -- to coin a phrase. That said, there are certainly unique interface requirements for any given software, including BPM. And as lots of people have noted, delivered BPM product interfaces have often been disappointing. So for sure, UX is an essential aspect of any productized technology.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
Setting aside the API discussions for a moment (as I've commented on those above already, should anybody care, though I can't imagine why they would)...

I certainly agree with the “generic UI” remarks. I've been amazed at the tenacity of skeuomorphic UI designs in industrial settings. People still design e-forms that look like PDF versions of something some bureaucrat created on an IBM Selectric in 1964. (Check out some social security forms for some great/horrifying examples.) Even as their mobile teams release animated, graphical, whiz-bang customer UIs that do little but collect a bit of data to feed the real applications, organizations still crank out desktop applications (for internal, customer-facing, or partner-facing use) that could have been rendered on a 3270 terminal without any perceivable visual or interactive degradation.

To the extent that the-software-previously-known-as-BPM is now being used as a digital application development platform, it must afford the rapid, code-free creation of flexible, multi-device user experiences.
Scott's opinions only. Logo provided for identification purposes only.
Hey Scott, I disagree with your assessment from the last paragraph. Today UX is such a complex undertaking that I simply cannot see it as a code-free effort. FWIW, the code-free interfaces of today do work a lot like the skeuomorphic interfaces of 5 years ago. Simplistic, with zero intelligence (call it enterprise context) and empathy (call it suited for a particular user or role) and flexibility (I want to see a zero-code UI that treats responsive tables well).

For that reason, your TV + remote example is misleading to me. Selling BPM is not like selling TVs, but like selling magical TVs that adapt to the program being watched. In such a case, a stock remote that is barely useful in all scenarios is not something that will drive adoption of these magical TVs.
Yep.. . . I also agree with Bogdan

The two UIs featured in the video illustrating a) Process Mapping in one environment and then, from 12:25 onward, the b) run-time Case Management environment that hosts the BPM engine, took two programmers many months to design/develop.


Small point of clarification.

The forms that are shown being built in the video are rudimentary.

A real form that features 20-50 form fields with labels, pick lists where needed, radio-button sets, checkboxes and, to the extent needed, rule sets that operate on data at the forms, takes about 1 hour to "paint".

Few corporations have more then 200 forms and some of these are near duplicates of others.

Clearly you cannot expect a form with 50 fields to push out nicely to a smartphone - a desktop form used to collect data at a cell phone typically needs to be adapted to go on to several narrow vertically-scrolling pages.

Language translation is a problem, more so with some languages. Fortunately, we can provide a language translator that allows a customer to take the English version of an app and simply overtype until no English remains.
Thanks for the comments!

Of course, I believe you both to be spectacularly mistaken. :)

Coding your UI is about the fastest path to obsolescence and customer abandonment I can think of. And it wipes out a big part of the reason you want a BPM platform in the first place: the ability to deliver a UI that is driven by the data and process underneath, a UI that will change appropriately (and without intervention) as those drivers change.

Many of our customers use well over 200 forms, and the majority of our customers are utilizing forms with well over 50 fields. And, of course, forms aren't the only important UI element anymore, though they are one that is very demanding in terms of user experience, flexibility, and device adaptability.

Very small devices, like phones, are not ideal for large-scale human data entry regardless of UI. Data entry just isn't a realistic handheld use case, unless that data is sensed automatically by the device (or a connected sensor or set of sensors). (In fact, we're finding that even fairly traditional uses of phones—even large ones, and even tablets—such as entering free-form text, is pretty cumbersome in a lot of commercial use cases.) To the extent, therefore, that somebody is designing forms for both handheld and desktop use, they're unlikely to have to worry about the mobile data entry use case.

Sure, I'd like it if the color mix, brightness, motion blur, and other key behaviors of my TV were in fact responsive to what I was watching. (And there's no reason they couldn't be, by the way; connected TVs have all the information necessary... but I digress.) The issue is what happens when the TV responds to one program in a way that may be consistent with its rules, but differs from how I would have preferred for that specific show. Do I have a mechanism for changing that response? Can I make it permanent? Might depend on how expensive my magical TV is. Will the generic remote work with the low, middle, and high end models? From all manufacturers?

OK I think that metaphor is now officially beaten to death.
I'm not sure where we disagree, Scott: "the reason you want a BPM platform in the first place: the ability to deliver a UI that is driven by the data and process underneath, a UI that will change appropriately (and without intervention) as those drivers change."
Nobody says you shouldn't reuse your UI assets in projects - what I'm arguing is that someone that is not skilled at understanding UX and at understanding the corporate context that UX is being delivered (and this someone would be a typical customer of zero-code UI platforms) is able to create a compelling UX just from stock elements, that mostly consist of generic UI objects and layout templates.
UX is more than just inputting data into forms and consuming that data from tables and reports. It's, among others, about what data is appropriate for a particular decisions / action, it's about how the application nudges the user towards completion of goals, it's about using sensors and other devices / apps in creating that seamless context that is appropriate for that particular task/process etc.
I have yet to see the stock UI set of templates that achieves this, universally.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
Good debate but let's just remember what BPM is about in context of the variety of users. At core it is about people at work being supported by software. CEOs and CFOs want to know that information created is the truth to make good strategic decisions and retain confidence of investors. Most want to see an empowerment of their people to encourage continual operational improvement in reaction to the inevitable change. Internal users want ready access to relevant data to help in their jobs in knowledge change can be supported if required. Customers are now becoming direct users and want to feel engaged as they make choices in making a purchase/receiving a service. The point is every one of these fundamentals involves the UI including reports and the resultant UX. This relies on the BPM supporting software to do its job presenting and collecting data via UIs. This surely suggests the UI is a core requirement as BPM addresses all needs of all users?
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
In properly designed BPM system process engine should be entirely isolated from user interface through well-crafted API. If user interface is mixed with process engine, it is an evident disaster. Process engine should run as a service in unattended mode and, ideally, should be also clustered for fault tolerance. User interface of a process engine is normally an administrative dashboard showing its status and notifications on accidents. Nobody cares about it much, as far as it works smoothly. Quality of BPM system is in inverse proportion to attention, which its users should pay to user interface of its engine.

User interface is crucial for instances of running processes. But these process instances may not even belong to BPM system itself. For example, if a user receives a message as a part of a business process, he or she need not even know that it came from a BPM engine. User can read a message in any message system and take proper actions to execute process, while being not aware about all complexities of BPM processing behind. Better BPM system is organized, less visible it is. BPM engine is a service to make all dirty work of process automation behind the scene. As with any service, it should stay invisible as much as possible and provide end users with results they expect timely and free of errors.

Running good BPM engine should be similar to running a car. Driver should watch the road instead of inspecting how gears move inside the vehicle.


User cockpit vs. engine in Formula 1 car

You are so wrong in fact the process engine orchestrates required data to the UI recognising who and the instance and so Adaptive is automatic. Maybe you have misunderstood there is no need for a UI for a process engine? The process engine creates the users UIs as required. All so easy and quick to build if you have the right architecture.....
@David, Thank you for feedback. I know some BPM engines really generate form flows and other kinds of UI. However, I cannot consider it as an obligatory part of BPM engine itself. BPM may well orchestrate other systems to run tasks. In these terms, UI are entirely optional. If tasks are, e.g. not human related, then they don't need UI at all and will just execute as scripts or binary code. I agree that an option to produce UI directly from processes can be handy in many situations. But I cannot consider it obligatory for the engine itself. Engine is just engine. It should drive processes well and nothing else. And processes are not always visual or even feasible for visualization.
  1. John Morris
  2. 3 years ago
  3. #3324
+2 @Boris -- first for the terrific F1 pix themselves! And secondly for how the pix illustrate very well the distinction between engine and interface. It's no disrespect to either concept to note that they are very different. One could say "ontologically distinct" -- which is a fancy way of saying that there are fundamental, real and consequential differences between the domains of BPM engine and BPM UX. The casual intermixing of the two in practice hides both problems and opportunities.
@John, thank you. As always, you picked precise word: "ontology" (or "semantics") is exactly the primary area of BPM engines. A single ontology can have multiple UI projections, which quickly evolve according to modern UI fashions and client taste, while core semantics empowering these projections remains much more stable and mostly hidden from end users.
I guess it depends upon the architecture that allows the orchestration as required. This should include populating the UIs with required data. Our approach discovered how this could be extended to include creation of the UIs recognising the user and their particular needs at that instance. In fact the process engine also sets up the application ready to run by using a declarative technique from the graphical model where business knowledge builds the application. I am sure others ways exist and deliver but the acid test will be time and cost to build and of course support change. Our rule of thumb is number of UIs / forms equal the number of man days to build the BPM supporting application. The challenge is often linking to legacy where APIs are often required. It's not just the process that needs to flexible for change but also the UI so having a seamless link has significant benefits?
@David, no doubt, it is very powerful technique and much demanded among clients. Normally, it is called form flow, although I prefer to name it process scaffolding by analogy with web form scaffolding, which is so popular in web GUI design where forms are generated directly from underlying database and object schemas. However, I still believe that this part of application is principally distinct from core BPM engine, which has no imminent visual manifestation and can have multiple UI projections. Clients often have very individual UI habits, which prevents shipping single UI technology universally.
There probably are many ways to build "a properly designed BPM system process engine", but we need to immediately qualify this by stating that we need two "engines" for apps that feature BPM as a core service.

Anyone building a BPM flowgraph in a graphic environment needs a UI (e,g, menu bar, icon bar, drawing canvas, in the case of a desktop app). No arguments.

The user drags and drops objects on the canvas, effects a save and on re-load, the app simply brings the user back to where they were. No engine here - all the software is doing is re-drawing a map.

The plan side "engine" kicks in when you "compile" the graph - this generates a template consisting of the process steps, written out step-by-step to RDBMS records, each with a BPM process name, step name, predecessor/successor tags, links to any needed forms, routing information, whether a step has an imposed delay, etc. If the compile is not successful, the Case Manager will see an advisory and will need to clear the problem. You don't get a template until the last advisory has been cleared.

Moving over to the run-time environment we have a 2nd BPM background engine that manages instances of templates generated by the plan-side engine e.g. the RT engine posts steps as they become current, tracks which steps have been committed, which steps are "current", which steps are not yet current and which steps have been skipped.

Here, it's not the BPM engine that needs a UI, it's the run time environment itself, which, in the normal course of events. will be hosting an arbitrary mix of ad hoc steps inserted by users/others as well as structured steps along BPM template instances.

The UI will typically consist of at least a to-do list of current steps, except that users need to be able to go to past due steps, record data at forward steps, and, in some situations, be able to view an entire process map to see what sub-pathways the instance navigated, and what steps remain downstream from current steps.

As Boris points out It "If tasks are, e.g. not human related, then they don't need UI at all".

True, for tasks or steps encoded to user 'system' i.e. auto-commit tasks- we don't want/need anyone other than a Case Manager to see these, so, no need for a UI.

As auto-commit tasks become current, user "system" looks at available data, takes some action (performing calculations, providing gatekeeper services).

It's easy to see that auto-commit tasks are no different from ordinary user tasks i.e. they have attached forms plus rule sets that operate on the data (e.g. convert deg F to deg C) and for tasks that are part of a decision box, their forms will have form value rules that allow the form\step to "fire".
@Karl, Your comment, as always, is encyclopedic to exclude all ambiguity. Not much to add really.

Although, visual process designer might still be not a part of BPM engine. It is rather an external instrument for process architects.

Take a typical RDBMS:

1. It has engine, which stores records and runs SQL queries. Engine has typically no GUI, apart from scarce service controllers and execution logs. -- In case of BPM, its analog is core BPM engine.

2. It has a management studio to write and execute queries, configure databases and monitor engine performance. -- In case of BPM system, it is a visual process designer and administrative console to view running process instances.

3. It has a pool of user applications using RDBMS. These applications are built in various technologies and only rely on SQL standard for their interactions with the engine. -- In case of BPM, these are running process instances in end user contexts.

When BPM will grow mature enough to follow universal process standards, it will evolve into something similar to RDBMS systems in terms of above component architecture and interoperability between vendors. The only principal difference here is that RDBMS manages data, while BPM manages data flows.

@John, thank you so much for pointing out to my misprint in above comment: "immanent" is the right word: "BPM engine has no immanent visual manifestation". Alas, comments are not editable to fix it directly in context.
+1 "RDBMS manages data, while BPM manages data flows"
  1. John Morris
  2. 3 years ago
  3. #3334
+1 @Boris re: the future of the BPM engine. -1 @Me for saying anything about spelling!
RE “If tasks are, e.g. not human related, then they don't need UI at all and will just execute as scripts or binary code” – my reality is slightly different: automated tasks need some UI to handle them in case of problems. It is similar to “no-human-direct-involvement” equipment, e.g. turbine, that has an observation window which allows one to observe the workings of a turbine.
RE "populating the UIs with required data" -

This, if I understand it correctly, refers to context/situation-appropriate forms AT steps [ each form is a UI ], as opposed to a "shell" (also commonly called a UI) where the nominal presentation will be an empty "to-do" list of tasks/steps.

It is the job of the BPM "engine" to load tasks/steps. The user sees a list of tasks/steps, typically for a day. - accordingly, with a list of 20, these could belong to 1 Case with 20 current steps, or belong to 20 Cases with one current step each.

It 's interesting to debate the extent of coupling of forms to any step.

Too close and you end up unable to call the same form at different steps - many forms, especially insurance forms, tend to have zones where one user fills in one zone, then another person fills in another zone, then at the bottom a "for internal use only" zone.

For forms like this, you want to be able to call the same form multiple times at different steps.

For this reason, the architecture we use allows steps to link to forms (one or several). This allows you to have the same form referenced at several processes \steps (good as well as not good). Not a problem if you go "record holder\subcase\pathway\step\form".

A side benefit of linking to a form FROM a step as opposed to attaching a form TO a step is that if the form changes (add new form fields, change the rule set) you don't need to re-compile and roll out your process as a new template to reflect the changed form.
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Accepted Answer Pending Moderation
I like "the RDBMS manages data" the trick is to store the BPM tasks and flows as data and then you have one environment which can do it all......believe me it works including the UI. Interestingly Microsoft tried to patent storing tasks as data but too late our 10 years of prior art means no one including us can patent so that door is open ........
@David . . . . . very silly of Microsoft.

The thing is an rdbms does not know the difference between data, tasks, rules, documents, images, other than that specific data types need specific fields.

We store almost everything in MS SQL, contrary examples being large video/voice recordings. i.e. Today, with 4K recording devices, you accumulate 50GB every 10 minutes. Whereas you can store such recordings in BLOBs, performance suffers. A pointer to an external file solves the performance problem.
Our process engine inside the database does indeed recognise the differences you mention...that's the key to that door....
To ensure good performance we built in memory working capability which helps where UIs complex and lots of data used.
I ve used RDBMS analogy above only as an illustration of proper multi-tier application architecture and UI isolation. Optimal process storage is too large topic, which lies outside of current question.

In general SQL storage is not well suited for process storage. Processes are graphs, and graphs are best stored in specialized graph databases. Of course, classical SQL storage can appear as a back-end for this. However, recent NoSQL solutions can appear even better in this respect, especially in view of modern fashion for big data.

Still, most of vendors really store processes in SQL databases due to simplicity and tradition. We do it this way also.
The method of storage I suppose needs to be tailored to the favored mode of access.

If you are frequently calling up a graph with the intent to add, move, link, unlink steps and directional arcs, then storing a graph as a graph may not be the way to go.

We store sheets, nodes, arcs in our platform all in different tables and build the graphs on the fly.

However, once built, what we display is a giant bit map that you can drag right, down, left, up and see it scroll as fast as you can move the mouse. (a 10 ft x 10 ft graph is not a problem at all except that you probably need a zoom in to see where some process fragments are)

Each node, each arc on the map is a hot zone (how, I would have to ask) but you clearly want to be able to click at the start of an arc and drag it to a different node, click at the end of an arc and drag to a different node, click on an arc and delete it, lasso a cluster of nodes and arcs then drag to open up real estate so you can then insert new nodes and arcs.

If you looked at my video, it quickly becomes apparent that we don't have a construct called "decision box" - the developers obviously felt it was easier to let users lasso nodes (2, or more than 2) to form a decision box. Works for me, works for our customers.

I notice we have in our platform a loopback construct but it lacks a counter (i.e. this would allow us to implement for example a "3 strikes and you are out" protocol).

Another thing that helps productivity at run-time is to dovetail everything to one "end" node, even though your mapping platform may not require this - if is very helpful to be able at any point during processing of an instance to "skip" to a fake end node because, once there, one commit terminates the template instance.

I recall a discussion with Alexander where I figured taking a record-holder off a pathway (where the record-holder could be on say 5 sub-paths) and then placing the record-holder at the right "current" nodes on a new version of a pathway, is difficult. Alexander thought otherwise and I have yet to understand how to simplify this.

Suppose I have 1-2-3-4-5-6-7 and I make a change at #2 where I add a new field to the node form AND THEN reference that new field in an algorithm at #6.

Seems to me if an instance is at #1 or #7 then. no worries, but if the instance is say at #3 then you won't have the data value needed when the instance gets to step #6.

You may or may not get a fail at 6 - it depends on your rule set i.e. whether it accommodates “if blank or null then action"

This kind of situation is seen a lot in manufacturing where a change to a sub-assembly may require that you take an advanced assembly apart if it is too far down the line (i.e. re-work).

Statically, graphs store in SQL relatively well. I mentioned some wide spread techniques, such as adjacency lists in my recent comments on DMN thread of this forum. However, resulting tables have, as a rule, dynamic structures per graph type (methodology), which requires dynamically generated SQL tables per each methodology used or introduced.

Principal problems begin, as @Karl correctly notes, when we need to dynamically query and, especially, modify graphs efficiently (ultimately, in real time). Here SQL embedding of graphs gets utterly inefficient. There is no standard solution to this. Some specialized graph databases claim solving this in more or less efficient way. I know Dex library (http://www.dama.upc.edu/en/technology-transfer/dex), although didnt work with it in real projects. Interesting technical discussion on graph storage can be found in this blog: "On Building a Stupidly Fast Graph Database" (https://blog.directededge.com/2009/02/27/on-building-a-stupidly-fast-graph-database/). I did not hear on using these approaches in BPM applications though.
Just for clarity no need to store graphical design build in database. Ours sits outside as a separate entity linking into the database. We built the core engine tasks links etc only later we added the graph using task symbols similar to those used in 70s. We then built a declarative way to allow the configuration to be declared to the process engine which set up as "instructed"......just a click and ready to run. Way too simple for IT.....!
  1. more than a month ago
  2. BPM Discussions
  3. # 15
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.