Outsystems BPM... how good can it be?

Outsystems BPM... how good can it be?


Hello all,

I would like your opinion on the offering of the embedded BPM that comes with OS Platform 5.0.

Two days ago i downloaded 5.0 and ran the tutorial on Business Processes.

I saw some imediate advantages:

- Business Processes made simple to develop and implement

- Map Human Activities to Code
- Provide task guidance to specific Users
- Email integration inside processes
- Wait until specific actions take place (or a timeout occurs)
- Change the status on the conclusion of activities...

and one small big detail:

If you embed processes into code, everytime you wish to change a process, you need to do some coding exercise. Ok, so Outsystems makes it simple to change, but what about the customer needs?

Shouldn't the process definition be available on backoffice, so that the customer may alter processes whenever he wants?

How does one sell this BPM to a customer? What advantages does this bring to "him" ?

Best regards,

Diogo C S Cordeiro

Hi Diogo,


I'm glad you liked the new BPM features.


> Shouldn't the process definition be available on backoffice, so that the customer may alter processes whenever he wants?


The process definition will be available for business profiles in a backoffice (not in ServiceCenter). Business users will be able to understand and propose changes for the process using the ECT submit feedback on top of a process definition diagram. Still the process changes need to be implemented by the developers, as it is the only way to ensure a smooth and stable operation for the final result.


> How does one sell this BPM to a customer? What advantages does this bring to "him" ?


Being able to implement business changes (either process oriented or not) with a minimum effort and risk is our most important goal. Our tools, methodologies, and best pratices are aligned with this goal.


What we have found in multiple customer installations is that BPM suites that are more business oriented (allowing business to completely change process definitions) are very good at the process definition level, but fail to offer the robust changing mechanisms that we promote with a single tool.


There is also a set of facts and falacies that should be understood when selling the OutSystems Plaftorm:

  • Business Users have a deeper knowledge of the processes than a developer - This is normally false. A developer needs to have a deeper process knowledge to be able to code an executable process definition that handles all the requested scenarios. Business users tend to have a cleaner high level view for the same processes (without a lot of details).
  • Business Users are able to define a process - This is only true in the early stages of process modelation. Business users are able to model process sequences, dependencies, conditions, events, but once the process definition reaches the development stage, it needs to be connected to a database model, user interfaces, security. The later stages require substantial development effort and integration in order to deploy an executable version of a process definition.
  • Changes are either process or application specific - This is normally false. Small changes require to change only the application User Interface, but business change seldom require to change only the process definition. The most common changes are similar to "Requesting specific data in a process activity to be used in a later process flow decision."
  • Processes are more important than applications - This is a very partial view of a complex system. We believe complex systems need to have higher abstractions like processes, human activities, activity load, and performance indicators. They are essential for good management, but the should not eclipse the need for efficiency and usability for the end-users. Human activities are relevant not only because the support management tools, but because they guide end-users in their activities, and completing these activities is more important than supporting an abstract process definition.


I hope this helps. These ideas were the foundation for the BPM Features that we added in 5.0. Let me know if you need more information.


Best regards,




Excellent post and reply, Lucio.
It shows that there was a reasoning behind the decisions taken by OutSystems and the product strategy.
I specially liked the facts and fallacies list, its really true, these are common illusions we have and good arguments for a sale in the costumer.
Good job!
Hello Lúcio,

I must thank you for your explanation and guidelines on the subject.

They seem really good arguments for most of the projects, where you have your processes well defined and stable.

Sometimes though there are projects when you are asked to think about the future, and leave the business definition opened to certain trained users, so that they can adapt themselves to the reality they embrace, without having to hire some extra services, to alter those processes, or even create new ones...

Do you know of any sort of statistics, demonstrating how locking business definition to the development level is more profitable for the customer, than letting it open for trained users? Or any numbers on the average nr of times maintenance teams are requested following up issues on having business definition at the user level?

Best Regards,

Diogo C S Cordeiro

 Hi All,

Besides the fallacies that Lúcio depicted very clearly, I’d just want to add something I believe it’s one of the biggest differentiators of the Agile Platform 5.0, which is bringing together two different lifecycles, the application development and the business process management, into a single and unified environment.

Now, in Service Studio 5.0 you can model the application and the process together, side-by-side, in one single model, and in one integrated environment, without the burden of complex and costly integration. This also means that whenever a change is needed, it happens both in the application and the process, you change it consistently and you deploy it once. Then in Service Center you will also be able to monitor applications SLA and processes instances as well.


If you can think in a process application, we just added a new layer – the process layer –but taking full advantage of all the other existing layers, the Database model (to trigger process events), the User Interface (binding process activities to screens), Security settings (reuse the existing permissions areas in the process), and Integration (using all integration adapters you have in place). But above all, the TrueChangeTM mechanisms that you had for applications are now extended to the process, and guess this, they are done on-the-fly!


Last but not least, as you know one the major goals of a BPM initiative is flexibility and performance improvement. As such we also introduced a new set of powerful business activity reports and graphs in 5.0. You can review process performance, trends, service level agreement fulfillment, team workload and more to help you keep an eye on your organization's processes performance. And they are all accessible through simples and one click-away web blocks.

Hope this helps.

Manuel Dias

Hi guys, I wanted to comment on Diogo's last question:

"Do you know of any sort of statistics, demonstrating how locking business definition to the development level is more profitable for the customer, than letting it open for trained users? "

While I don't have any statistics at my finger tips I wanted to share a comment from the analysts at Forrester when we showed them 5.0. Their first reaction was that our solution was offering process mash-up capabilities. Then when they began to understand the process execution, monitoring and analysis capabilities the decided we really had a lightweight BPMS. What was interesting was that they said we were directly addressing a key problem they see in most of their end user clients - process have been delivered that are very 'brittle' due to the amount of hand coding, integration work, etc required for implementation.

I think this 'brittleness' speaks directly to the fact that for human centric processes, where system interactions are needed, the process definition must be very flexible (dare I say Agile;-) and will typically be owned by IT who has the skill and resources to handle all the needed change. With 5.0 and the new Business Process Technology the Agile Platform's core value proposition of rapid delivery and fast change has been extended to the business process level.
Hi all,

I'd like to comment on something Diogo said. «Sometimes though there are projects when you are asked to think about the future...»

Unfortunately not all that seldom we get these type of questions from customers and I'm sure you also have had them to Diogo. Customer says "I'm investing now so might as well get an application that can adapt and that I can configure so that it keeps working in the future". To me this is one of the greatest fallacies in software development and you can apply it to BPM also. What you get we this is a much more complex application that takes much longer to code and test and that ultimately has a higher chance of failing and as Murphy taught us it will fail.

To me the biggest differentiator of the whole Agile Platform, BPM included, is that the cost of change is very low. This along with our Agile Methodology is why our projects have success, and with success I mean not only that they are on time and on budget but also that the users adopt the system, being this the most important KPI to measure success in application development.

Returning to your concerns regarding open specifications in BPM I think you should adopt this position which is not always easy. Make sure your customer understands that building a generic application or process costs more than solving the problem at hand today. Explain to him that the cost of change is low and future changes are for sure more solid if they are made considering the full life-cycle of the application (process, user-interface, integrations, etc) instead of trying to adapt an application to do something it wasn't suppose to do because the process or business has changed.
André Vieira