We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Is BPMS Just the New Name For Application Development?

Vote 0 Votes
Found this at Mark McGregor's blog, where he writes: If you look at some of the key players in the BPM market today you see names like Progress, Software AG, Oracle and IBM, all of whom come from an application development background.

So is BPMS just a new name for application development?

16 Replies

| Add a Reply
  • Not really. The BPM Suite is increasingly seen as part of the CIO's portfolio of automation capabilities. Different BPMS vendors meet different automation needs. So, in any big corporate landscape, a BPMS is likely to be part of a heterogeneous systems mix, sitting alongside one or more ERP platforms, as well as competing BPMS platforms probably.

    This gradual meld of the BPMS into the wider automation environment raises an interesting question about whether we don't need a new term for BPM? Automation is a very limited aspect of performance improvement: we need a term that also includes, for instance, governance and change management around end-to-end processes.

    further thoughts this on my blog: http://bit.ly/agaLNJ

  • I think there's a growing sense that as BPMS becomes more technically aligned and with the advent of more solution providers coming on the scene with products designed to allow the business to create apps out the box (OutSystems is a good example of this) then I can understand the view that BPMS is becoming some sort of pseudo-application development environment.

    But is this necessarily a bad thing? (bad…Business Application Development…BAD…)

    If the power is given firmly in the hands of the business user to become adept at creating and deploying business applications using a process modeling environment, and that the solution is sufficiently simple enough to use so that IT involvement is minimized then BAD is good in my view.

  • If you look at the design environments of many integration-centric BPMS, they rely on Eclipse, which is an application development environment. On the other hand, many vendors are masking this environment by putting a "plug & play" type design environment on top that allows users to use prefab connectors and application functionality in their process models.

    This trend is good in two ways:

    a) BPMS are becoming integrated as a mainstream tool in the application development process as traditional developers encounter process functionality in their tried-and-true IDEs and we are seeing less of the "look I can program a process" type of the past (anyone remember BPEL-J?).

    b) The distinction between developing process-aware applications (in Eclipse) and configuring these applications (in a web-based environment) is beginning to clear up the roles required in the deployment of a process-centric solution.

    I just wish the BPM vendor marketing speak of "No programming required" would be replaced by the more truthful "Some initial programming may be required". In addition, most BPMS vendors still assume that their solution sits on top of the application hierarchy, i.e. there are no other BPMSs around they need to interface with (or expose themselves to). That's a question of market maturity - for example, no database vendor assumes that all enterprise data will reside in their solution (as nice as that would be). Over time the BPMS vendors have to realize that their tools are part of an overall application infrastructure that may incorporate more than one process-centric solution.

    Will we see BPMS in all application areas? I doubt it, as there are transactional, real-time, and batch-oriented systems where the one-instance-at-a-time paradigm of process solutions may not work. But where these requirements don't apply (in the majority of application areas), BPMS will become another tool in the arsenal of application developers.

  • My experience as a consultant implementing BPM solutions was that most of the effort cames from the customer's requirements for an application that looked meaningful to their users, worked with their use cases and enforced their data entry rules. In those projects, this required a significant level of software development around the core BPM 'configuration', despite the ultimate flexibility of the tool being used.

    A huge effort has gone into the development of killer process modeling tools and the prettiest analytics dashboards by BPMS vendors. It feels like the common ways that users with different roles want to use their applications (I say application, because users don't see 'BPM' as something they use) is often overlooked in the design capabilities of the BPMS. You can do whatever you need to in order to meet the requirements, but at some point you'll need to write significant chunks of code.

    At the same time, the tools with more options that aim to avoid the need to write code can also get so incredibly complex, since it takes significant training to work out how to get all the bits to work together and configured correctly. And as a reminder to the marketing guys, HTML and Javascript is still code. It still needs to work and be maintained.

    I like Theo's comments on BAD. My approach preferred approach for a process improvement tool is to incorporate the most common use cases into building blocks, rather than implementing every possible feature. This I believe can help business analysts put together meaningful solutions faster, with less IT involvement, and no software development.

    Phil Ayres

  • I agree with my colleague Alex Neihaus, who also addressed this question, so I will quote his post:

    "Yes…and the best way to get there is to minimize the disruption to application development. In other words, BPMSs need to look and feel like previous-generation tools, all the while doing the right thing architecturally and automatically."

  • If you only look the developer's vision it is on the right, but what's the problema of this?
    BPMS it's the system for implement the methodology

  • It certainly replaces a lot of application development that would have been done if BPMS was not available.

  • One big advantage of making business processes executable is that they can then leverage the middleware infrastructure to provide additional benefits to the business.

    I am talking about the capability of capturing and monitoring various low-level events triggered during the execution of the process. These events can then be aggregated into higher-level events that have direct meaning to the business (e.g. KPIs) and can be leveraged for generating business alerts, doing BI analysis, etc. (This is what is called Business Activity Monitoring or BAM).

    The feedback obtained this way can be used to gain better visibility over the business process and to incrementally improve the process itself.

  • user-pic

    I did not read SOA in this thread. Any reason why not?
    (see http://www.infoq.com/news/2008/05/soa-or-bpm)

  • I have read the responses to this post with interest, as I have been reflecting on this question for a little while as a result of a recent customer engagement.

    I think that BPMS is coming into its own as an application development environment; however, I believe that this is perilous. When one considers the model driven nature of BPMS it is important to realize that at times we model for business understanding, other times we model for execution. As much as we would like these models to be the same, for good reason they are often different.

    There is a push underway that is driving business process models away from end-to-end process approaches, toward collections of process fragments strung together by various events. When event-driven modeling occurs as a result of making the process more agile and responsive in the face of environmental change, it is a good thing. When it occurs as an artifact of a model-view-controller approach to UI design it is a bad thing. In other words, as long as the process models continue to reflect business architecture, BPMS will continue to serve its intended purpose. If our models begin to express too much application architecture, we will have lost the battle and BPMS will simply become the latest development fad and the ability to align business with IT will suffer.

  • It is tempting for middleware vendors to turn BPMS into a simple development platform to help IT crank out business applications faster. This is the path that Oracle and TIBCO took with their BPM acquisitions of BEA/Fuego and Staffware respectively. Last year, Forrester surveyed and interviewed process professionals and found that BPM projects taking a developer-centric approach to BPM - without process improvement as the key driver - failed to yield significant ROI and value for organizations.

    Some vendors continue to view BPMS as an application development suite. However, leading vendors are expanding their view of BPMS to address all aspects of the process improvement lifecycle - process discovery, collaborative design, shared development, and self-service provisioning (i.e., allowing end users to configure and provision their own user experiences and process analytics).

    For example, IBM's Websphere team introduced a new component to their BPM Suite - Business Compass (repackaged and revamped Business Modeler offering) - which allows business analysts and business users to play a much greater role in building process-driven solutions. I particularly like the Business Compass tool because IBM embedded the process improvement methodology into the environment to help organizations establish a process culture and shift to process thinking. This is a big leap for IBM and we expect other vendors will follow suit.

    So, in a perverse way, the answer to this question is: Yes, BPMS is the new term for application development. However, we must first agree that "application development" is moving away from being solely driven by IT and developers and must now also include business stakeholders, business users, and business analysts. With Web 2.0 technologies, BPM SaaS, and social capabilities BPM suites are expanding to encompass all aspects of the process improvement lifecycle - and in a much more collaborative way.

    Our prediction is that BPMS vendors will double down on "shared development models" for process improvement - bringing IT and the business even closer together in building dynamic business solutions.

  • I think that BPMS (BPM as software) is an enabler for disruptive changes on how IT deliver tools (currently applications) to the business. Each enterprise has a historical set of “solid? applications and each of those applications dilutes and mixes several business artefacts: processes, services, events, data structures, documents, rules, roles, activities, audit trails, KPIs. BPMS, by enabling explicit and executable processes, is a step forward to externalise (later virtualise and “send? to clouds) ALL those artefacts. Of course, with the help of many other technologies, e.g. ECM for documents, BRM for rules, MDM for data, etc.

    This considerably increases flexibility – improving of processes will be assembling of better compositions from better artefacts; use of DSLs will simplify handling of artefacts, owners of business artefacts will be able to change them directly, etc. Because in many cases, processes are such compositions – this is the reason of the importance of BPMS.

    Should we invent a name for it? Business Artefacts Development? Business Artefacts Provisioning? I think, that more important is to come up with a commonly agreed reference model and reference architectures to help everyone to move forward faster.


  • Who cares what it's called so long as it gets the job done?

    I prefer to use 'business automation' as a generic term that covers both categories. People use software to automate work and processes so that they can achieve more with less effort. Whether they do it through application development or more indirectly via a BPMS, the aim is the same - and they're probably fed up with how difficult and time-consuming it is to achieve through either method.

  • The simple answer is "no." BPMS is much more specific than the broad umbrella of application development. It's about automating everyday tasks in the workplace and helping people to collaborate more efficiently. Not all application development is geared towards workflow improvement, as BPMS is. Sometimes applications are developed to perform tasks in an isolated environment, which is definitely has its place and purpose, but it's quite different than BPMS.

  • user-pic

    I think it's unfortunate, but also reality that BPMS is being treated (at least by some companies) as the new software development.

    One of the problems I've seen is business(es) applying typical software development management to BPMS projects. Simply put, business has bought into the (sometimes justified, sometimes not justified) hype around BPMS ROI, has purchased the software, and has treated BPMS projects like app dev - little-to-no process vision/discovery/analysis, little-to-no change management, some (but dreadfully lacking) linkage between specific solution and business goals, to name a few issues.

Add a Reply

Recently Commented On

Monthly Archives