A question from Garth Knudson, based on a quote from this discussion: "The trend I now see happening is that of BPM becoming a generally accepted application development toolkit. Organizations realize that process is part of every solution and BPM is a proven toolset for building user-friendly, adaptable, and cost effective web-based applications." What do you think?
Like any business applications in the past was essentially a database driven application, today any application has big chances to become a process application at certain point of its evolution. If your development environment is not tightly integrated with a process modeling environment and a process engine (i.e. is not a part of BPM Suite) then you as an application developer are in trouble because you'll hardly be agile enough to keep with process changes.
It's amazing that some BPMS vendors, while having all components needed for general-purpose applications development (data modeler, forms designer, automated testing and deployment etc.) don't give free access to these tools to their customers, enforcing them to do everything via processes. Seems that can hardly see around anything but traditional processes but for a customer it's just one form of enterprise work! The walls between process, project, case, record- and document-based work are conter-productive and must be broken.
On the other hand, BPMS vendors may have much to do to be fully competitive with more traditional development tools vendors on their playground. The debugging facilities of most BPMS, for example, are far from the industry standards and this distracts the old-school developers.
I would love to say 'YES!' as the concept is very compelling. In fact, many software vendors are building workflow capabilities into their products as their next generation platforms which shows the concept has merit. However, many of these 'workflow' enabled apps are not very well designed or executed.
Most of the modern BPM platforms I have seen would make excellent application development platforms with the features and capabilities built into the systems. However, I have seen this attempted on a number of platforms and all have been extremely disappointing.
One of the biggest challenges has been the change of architecture on the BPM platform either through redesign or via purchase of another vendor. I have been a part of at least 3 platform architecture changes where the solutions became obsolete and had to be rewritten on a newer/different architecture. That is severely disruptive, expensive, and hard to avoid unless you have excellent communication with the platform vendor.
Another challenge has been the data capture and presentation layer. You can see it with solutions using asp.NET pages, PDF forms, InfoPath, and other hit or miss technologies to provide a great user experience for the capture and presentation of data. This is getting much better in my opinion, especially with technologies like SmartForms for K2. These newer designers are finally allowing application like functionality without using much more challenging development requirements in the realm of asp.net.
Vendor /Subject Matter Expertise separation has been another challenge. While a BPM vendor may be excellent at building tools, they are generally not SME's for applications that might be useful on the platform. This has mean that partners have been doing a lot of the solution design and delivery and generally doing a great job. However, that disconnect has been challenging and providing disjointed solution profiles on the BPM platforms. There are good solutions, average, narrow scope, etc that have been offered via a 'Marketplace' with mixed results. I see this changing in my industry a bit where a vendor is providing a much more compelling solution on a BPM platform and is receiving some encouraging reception.
History has taught me that this has been a disappointing excercise but the promise is there and the rewards could be huge if someone can get past some of the challenges.
Any client COULD use a BPM platform to develop their corporate apps. But they would be mad.
Salesforce has huge team that think about nothing else but building customer success apps (CRM, support, marketing), WorkDay have a huge team that think about nothing else but building HR apps etc etc. And whilst these off the shelf (off the cloud?) applications are not a perfect fit for clients, the compromise is far better than trying to build and maintain this functionality using BPM platform.
However, there is a critical role that BPM platforms can play - "filling the App Gap". The “App Gap (image)”is the huge backlog of apps that the business want built, but are at the bottom of ITs todo list, behind keeping the lights on, upgrading the server infrastructure and 200 other high priority items. Now I am not going to beat up on the CIO and the IT department. I know how hard it is just keeping the lights on and the hackers out. That takes 83% of IT budgets. But there is an unmet need here.
But this App Gap is not for discrete standalone apps. Increasingly it is apps that sit on top of core systems and access and update core data. Therefore the BPM platforms need to be seen by the IT department as a credible addition to the IT infrastructure, not tools for some dangerous mavericks in the business. They should help bridge the IT gap, as I have described in this blog.
Therefore for a BPM platform to effectively fill the App Gap needs to have the following functionality:
- capable of being used by business analysts, not developers - the "Citizen Developer"
- can deploy the apps to multiple devices (web, tablet, mobile) with an elegant UI
- able to leverage data from existing core systems - Salesforce, SAP, Oracle, WorkDay...
- has single sign-on, so integrated into the core user directories
- has a level of compliance or version control.
With this approach BPM platforms are not fighting the major app vendors and the IT department. A battle they will lose. Instead they are working with them.
Great question -- but why? Because if IT is good for anything it's about building and using tools as force-multipliers to get more work done. And that generally means "building applications". So the question is good because it gets to the core of what IT is all about.
What about BPM then? Can BPM be the "preferred tool for app-dev"? In other words the backbone on which all app-dev is conducted?
The answer is "yes", insofar as work is the core of business and BPM is the technology which makes work a first class citizen of your software.
And incrementally BPM technology is getting to the point where it can almost fill this role. It's been a long haul, 10 to 15 years depending on how you track the history of BPM. It turns out that building software to manage graphs in real time is difficult -- to the point that developers just default to Java or .NET w/frameworks.
For BPM to be the starting point also requires the acknowledgement of other technologies which also must be first-class citizens of an app-dev environment. These technologies include especially Data modeling (including perhaps ontology management ultimately), business rules (i.e. with DMN), UX and systems management.
Each of these domains is irreduceable to the others. For example a simple authority escalation pattern for a field service ticket done directly in "BPM only" looks discouragingly complex. Abstract out the business rules of the escalation to a DMN-based server and the escalation process becomes dramatically easier for business people to understand, as well as the escalation rules. But in both cases the developers and analysts are dealing with business concepts directly without the mediation of code. This is the aspirational goal.
Ok, for once assume that BPM = BPMS, then in theory this is of course a very compelling idea. One suite that can support all the processes in the organization.
I've seen it a lot being tried in the early 2000's, but as stated above that was quite dissappointing.
The main reason, at that time, was the amount of time needed to build everything from scratch.
And another time and money consuming task was the integration with places where the data lives.
Last 15 years tools have become much better and easier, so it would be cool of course.
But unfortunatelly I think a lot of organization still think very short term. Process? Who cares about process? I have a problem and I want an application for that. Now!
We all know that buying that application might not even be the solution for solving the problems that cause bad process performance.
Luckily we see more and more 'process aware' solutions. That's of course not real process, but some kind of workflow functionality.
A BPMS should support process management, not software development. But Ok, that's how a lot of companies still think these days.
I've been in solutions for AP invoicing lately. Fancy tools but when I said 'You want to improve your invoice process? Stop buying things', that was the last day of my assignment.
Sorry for being process aware....
BPM suites still require expert knowledge to make them work so the benefit to use it for applications is limited. All BPM suites are used as application development tools and then it is referred to as a process. There are many application development like needs for processes and backend data and transaction integration is key.
In the end it is all about the application ideally driven by business langauge and thats where the BPM application development fails. They still end up to be legacy applications that are hard to change due to too many dependencies and much additional hardcoding to make them work.
For "general application development?" No. That's what languages are for. The above, preceding verbosity and arguments aside, thus has it been for a long time and continue to be so for a good long while.
Sometimes our little echo chamber here is a bit much, but re: this question, ask yourself why all the BPM platforms have APIs, connectors, etc.
Just my tuppence.
I actually fully agree with Max on this one. Let me elaborate a bit:
1. Any toolset around BPMN does not provide for a full programming language so you can't develop fully-fledged apps without getting your little hands into some custom code. BPMN itself is an incomplete standard (maybe explicitly so, but still frustrating) when it comes to full programming logic for the relatively few things in its scope.
2. Most BPMS's usually ignore not only the full BPMN standard (selectively implementing only what seems to be convenient or pragmatic), but actually most of the service orchestration and data logic related to integration to other applications and other things business people want to do. One glaring omission of most tools is rules management. At best they tout integration with a rules engine but most such integrations are a joke. Also most BPMS's have very weak front-ends when it comes to the actual application.
3. Zero-code means huge and imbricated property panels for every single object and endless configuration efforts when things change. Hardly an improvement.At least with code you have an IDE where you can debug stuff properly. Good luck in tracking the wrong checkbox in those property panels.
However, BPMN as a standard has some pretty powerful concepts that make business app development very interestign and fast - things like compensation, escalation, error treatment - these are highly likely business scenarios and it would be stupid not to use these elegant and robust constructs to speed up and bullet-proof your business apps.
Net: it would be dumb to use BPMN for every business app, but it would be even more dumb not to use it as a huge kickstarter for business app development.
This is a much more vast subject than this when you put the rest of the puzzle pieces together: UX/UI, rules, decisions, data etc.
Short answer: absolutely.
Folks, read the question. Should BPM be the "preferred" mechanism for application development? Well, if we're talking about the kind of in-house bespoke development representing the typical "competitor" for corporate BPM efforts, the answer is: Yes. There are a huge variety of applications that can be addressed with BPM (a) more rapidly, and (b) less expensively. Why?
Will BPM every completely replace programming? Certainly not. But if it can replace, say, two-thirds of in-house programming efforts in a given company, it will have made a huge contribution to the market responsiveness and overall efficiency of that organization, resulting in a material competitive advantage.
Short answer: NO
Long answer: Nooooooo !!
:-) Ok, let’s follow a reasoning thread that supports that cruel and unfriendly NO.
One of the pillars about BPM is Agility. I mean: modeling, simulating, adjusting, deploying, measuring and starting again. And adopting BPM is a real challenge: technology (minor), processes (medium) and people (major challenge). It is proven that the BPM team should be much trained, experimented and multi disciplinary. And definitely are not hard-technicians, they need very developed soft skills to interact with business users.
Software Development is more complex every day. Software Engineering is not in discussion since several years ago: to build software we need engineering principles, methodologies and structures. Software should run in several platforms (and several means “Maybe tomorrow there is another one"), be secure, scalable to millions of users, in several languages, complying with hundredths of regulations, and so on. Software developers more technical each day, developing hard skills.
So, does it sound realistic to merge software engineers with BPM consultants, to use a single BPM kit to develop general applications? Well, no. Specialization is where all this story ends.
Do we need to integrate automated process into the business core? Yes.
Do we need to jump over the fence between process and applications? Yes.
Do we need to merge altogether and shake the bowl? No.
In sum: it is radically important to integrate BPM into core operations to generate fully integrated applications. But we need to do this keeping specialized teams doing what they are best at (coding general apps; modeling and automating processes).
Should BPM Be the Preferred Tool for General Application Development? All depends, as usual.
Sure, we need to reduce the gap between “problem” space and “solution” space. This is why BPM (as a trio: discipline, tools and practice/architecture) is the obvious candidate to close this gap. Unfortunately, BPM itself is also the main obstacle so far.
As an enterprise architect, I have to deliver a digital business execution platform on top of which, my client’s unique business processes/cases will be quickly implemented from easy-to-integrate, off-the-shelf, cloud-ready and best-for-fit components. Sure that a BPM-suite provides some key components for such a platform. But “best-for-fit” approach is mandatory because some components must be replaced as the client’s level of maturity is increasing.
Today, I have concluded a blind POC for BPM-suite tools – the four (from originally 14) best-for-fit products were used to implement a simple business process during 6 hours. The score – only one has shown an expected application and another one has shown a good enough application.
Problems with BPM-suite tools are well-known – to become successful as an app development platform, these products have to compete with many other specialised tools (thanks, go-BPM). There are no commonly-agreed reference model, reference architecture, proper set of standards, etc. But there is a lot fight between process, cases, etc. “flavours”. What is a self-killing industry!
Considering that, there is no a strong BPM user community, only BPM-suite vendors can improve the situation.
Please start working together!
I wrote about this almost 5 years ago, but have to side with Pat on this one. Despite what I blogged back then, I agree that for "general" app dev then a BPMS is not the way to go, but for process specific application then yes, selecting a BPMS to do the job is and can be stacked up against an off-the-shelf solution.
Yes and no...
Yes as the discipline required to work out what users need but delivery as the application but technically no. Next generation application delivery allows build without being driven by coding the long overdue 6 GL. This allows v quick build direct from user language in graphical interface and includes all business requirements incl logic rules state UI and of course orchestration of legacy as the people process requires.
Sorry BPMS or suites are not the answer as these front ended adaptive applications need to be both custom builds and ready to support quick change.....in users hands.
We have had 20+ years or Research and working with early adopters. But wow what a challenge as few understand ....or want to understand! But now there are many signs the market needs this next step towards maturity where enterprise / business software becomes a "commodity" and one that business can understand how it works...
Just to be clear such capability really does build anything big, small, simple or complex. The tab "Adaptive" describes the software and not just for case management. It is a "platform" that addresses all technology requirements and supports BPM. However it goes way beyond the current scope of BPMS and as such would not be helpful to call such 6GL "BPM".
No, BPM shouldn’t be the preferred approach, because there may be a better alternative.
For example, it’s common to use a data-centric design approach for building business applications, where you start from a data modelling perspective, rather than a process modelling perspective.
When you start with data modelling, it’s usually fairly easy to discover which data people are using as part of their jobs, which means you can produce a nice satisfying data model diagram. Then you can code it all together into a nice big data management application, with the obvious CRUD style user interface: master-detail views and the like.
In fact, the hardest part of this is that the acronym that ends with IMS (… Information Management System) has probably already been used for something else. I once sat in a really long customer meeting with lots of highly paid people to try to find a different name for the system we’d built because the organisation (a large oil company) already had several other systems called ‘PIMS’, but that’s another story…
The really great thing about data-centric application design is that it’s entirely unnecessary to figure out what business process the resultingInformation Management System might be useful for, or how people are going to use the application, or what end result it might help them achieve. Even better: it’s entirely possible to complete a whole custom software development project to build some software without actually being sure that anyone will use it at all. After all, the idea situation is when there are no users at all, which really keeps software maintenance costs down.
BPM, on the other hand, is a problematic approach to application development, because it raises all sorts of difficult questions about the application you’re developing, such as ‘Why?’ Indeed, the worst thing about BPM as an approach is that you can’t really model a business process without understanding the process in terms of what result the process is supposed to achieve for an actual customer (internal or external). And if you go down that route, you might end up actually having to talk to real customers as part of the application development project. That would be ridiculous!
BPM may be nice for one sub-system, but what about the overall system design; it's architecture, it's application logical DB model? If your scope is but one process, fine, but I'm more concerned with the overall system.
...Not so much BPM applications although, as mentioned, Pega and Salesforce are promoting their toolsets to do just this. However I do feel that the concept of model driven development is easier to understand from a business users perspective. Signing off a process model, data model, screen design or a business rule defined in a decision table is far easier than wading through a 400 page spec or even a 5 page Use Case or even a user story captured on a card. All of these artefacts all suffer from being the written word which still needs to be translated into working code and therefore potentially misinterpreted by the developer or even the analyst who captured it.
More over the faster you get to code or the executable model the faster you can get validaiton of requirements and closer to the intended solution. Working code, which is also testable.
There are already other solutions like Mendix that are adopting the model driven development paradigm and not calling themselves BPM tools. I think this is the way forward, the more developers, business analysts and end users can collaborate overexecutable models, rather than approving docs and designs, the better will be the end product.In many cases this will result in a faster delivery of the end product and one that actually meets the intended business objectives.
Although I have a developer’s past, I do believe that BPM is the right way to go to build business apps.
It clearly provides major benefits to Application Development such as:
Traceability & access rights management
Because BPMS are meant to track all sorts of metrics, application developers will not have to put too much efforts to capture those.
Management can then easily pick the right KPIs for their reports and change their minds later with limited impact.
BPMS are also generally quite flexible in terms of access right management and can even be coupled with external authentication systems such as SSO solutions.
Because BPM involves atomic tasks, BPMS generally benefit from transactions and elaborated error management tools.
This particular aspect is generally quite expensive to develop in a custom application and leads to various degrees of success.
Modularity & maintainability
Using BPMS enforces modular design, reusable components and version management.
Modern BPMS leverage this to allow hot replacement of individual artifacts (forms, connectors...) to provide agility in application maintenance.
Custom applications generally do not offer that level of flexibility and need to be re-deployed causing downtime and increasing the risks of undesired side-effects.
Because BPM relies on processes, most of the logic of the application can be read by non-developers in the form of process diagrams.
Of course the reverse is not true: one cannot explain the high level behavior of a custom applications by showing lines of codes to an end-user.
This visual aspect is also key in the specification phase and helps to speed up the project implementation by allowing early interaction with project stakeholders.
I could go on with this list but to sum up I would say that using the right BPMS alleviates the application developer from certain non-business essential implementation tasks (building the app security, administrations tools...).
All of these are available out of the box in a BPMS while in a custom application, they can be tricky and expensive to put in place.
With a BPMS, application developers can concentrate on mission critical tasks such as the User Experience and delegate the rest to the built-in features.
In the end, it is often a matter of choosing the right tool for the right purpose.
For instance one should avoid the extremes of zero-code or full code solutions. There has to be a trade-off between flexibility and implementation speed.
In any case: do not re-invent the wheel! That is too often part of what developers do when they build custom applications.
Undoubtedly BPM provides a lot of features and functionalites in addition to bridging the gap between the IT & Business stakeholders. Having said that, BPM is not the remedial solution for every business challenge and problem statement. At times using a BPM product stack might be an overkill and costly affair - by not justifying/complementing the key features for which the Product was purchased/acquired.
It is important to do a preliminary fittment assessment - Does BPM fulfill my requirements today and tomorrow? Based on the mapping and scorecard a decision call can be taken.
- If the business requirements involves 5-10% of workflow implementation and mostly an approval process or STP -it will be an overkill to leverage BPM in this case.
- If there a End User Experience defined as a strategy and the BPM workflow UI is a small piece of the entire Enterprise implementations involving multiple technologies - force fitting BPM UI look and feel will be a costly effort intensive affair.
- It is also important to judge it from a futuristic vision perspective - how much can be reaped leveraging the onboarded BPM stack.
Additionally, for General Application Development - as a developer it is important to work in a free ground than living with the boundaries defined by the product. It is also unfair to expect every odd feature to be available in a BPM stack that works on drag-n-drop feature. With new technologies and coding languages mushrooming everyday in the wild.
It is important to leverage them for better/faster implementation and speedy Go To Market solutions.
With the technology landscape and offerings going flat and open everyday - there is no point living in a closed box provided by an Enterprise Product and expecting to be glorified by technology, with the chunks/packets of out of the Box features, hotfixes and upgrades provided through a small opening in the Enterprise Product Box.
To summarize :
- Any application development platform adopted should be in line and complement the requirements targetted in the enterprise.
- It should provide an open platform to build Wrap-and-Renew solutions with the latest trends and technologies.
- Finally, addressing today's small problem with huge platform adoption should not become a maintenance nightmare/bottleneck tomorrow. Assessment is the Key.