Welcome!

Microservices Expo Authors: AppDynamics Blog, PagerDuty Blog, Robert Reeves, Automic Blog, JP Morgenthal

Blog Feed Post

Why Workflow and BPM Suck

The verities and the balderdash the impact of the cloud

I originally wrote this paper back in 2005 as a bit of a rant against the positioning of Workflow and BPM. I was reminded of it the other day and took another look only to discover that things still haven’t changed that much. So I’ve decided to revamp it a bit to encompass cloudy type things and what the impact of social media etc has had in the ensuing years. So for your amusement or edification here’s a revised version.

Many of us that were involved in the field of Workflow Automation and Business Process Management (BPM) a few years ago (and some still are I’m sure) argued long and hard about where the two technologies overlapped, where they were different, which mathematical models should be used, which standards were applicable to which part of the technology stack and all that associated puff.

Well these arguments and discussions are well and truly over more or less forgotten; the demarcation lines were well defined and drawn; the road ahead became clear.

The fact that Business Process Management has its roots in Workflow technology is well known – many of today’s leading products are, in fact, evolutions of the original forms processing packages. So there is no longer a need to debate, what is now, a moot point.

But what has happened is that BPM also changed. Rather than being an extension of workflow concepts BPM was seen as systems-to-systems technology exclusively used in the deployment of concepts such as SOA solutions. I’m over simplifying things I know, but it seemed as though BPM was destined to become an IT Technology solution as opposed to the business process solution it was meant to be. Somewhere along the way, one of the key elements in a business process – a person – dropped off the agenda. The fact that the majority of business processes (some 85% according to some very old Forrester research) involve carbon based resources was overlooked – think BPEL for a moment – doesn’t the attempt to develop that particular standard tell you something about the general direction of BPM? But be warned, even today, many vendors will tell you that their BPM products support Human interaction, but what they are talking about will be simple work item handling and form filling – this is a long way from the collaboration and interaction management we will talk about below.

The problem stems from the fact that most Workflow products were flawed and as a result, the problem in the gene pool rippled through to the evolved BPM species. So what was wrong with workflow? It’s quite simple when you think about it; most workflow products assumed that work moved from one resource to another. One user entered the loan details, another approved it. But business doesn’t work like that.

This flawed thinking is probably the main reason why workflow was never quite the success most pundits thought it would be; the solutions were just not flexible enough, since the majority of processes are unsuited to this way of working. Paradoxically, it is the exact reason why BPM is so suited to the world of SOA and systems to systems processes. A rigid approach to systems processes is essential, where people are concerned; the name of the game is flexibility.

Why do we need the flexibility?

Let’s take a simple analogy so that the concept is more easily understood.

Supposing you were playing golf; using the BPM approach would be like hitting a hole in one every time you tee off. Impressive – 18 shots, and a round finished in 25 minutes.

But as we all know, the reality is somewhat different (well my golf is different) – there’s a lot that happens between teeing off and finishing a hole. Ideally about four shots (think nodes in a process) – but you have to deal with the unexpected even though you know the unexpected is very likely; sand traps, water hazards, lost balls, free drops, collaboration with fellow players, unexpected consultation with the referee – and so it goes on. Then there are 17 more holes to do – the result is an intricate and complex process with 18 targets but about 72 operations.

As mentioned earlier, we have to deal with the unexpected. This is not just about using a set of tools to deal with every anticipated business outcome or rule; we are talking about the management of true interaction that takes place between individuals and groups which cannot be predicted or encapsulated beforehand. This is because Business Processes exist at 2 levels – the predictable (the systems) and the un-predictable (the people).

The predictable aspects of the process are easily and well catered for by BPMS solutions – which is why the term Business Process Management is a misnomer since the perceived technology only addresses the integration aspects – with the close coupling with SOA (SOA needs BPM, the converse is not true) there still iis an argument for renaming BPM to Services Process Management (SPM).

Proposals such as BPEL4People didn’t fix the problem either, all that managed to achieve is replicating the shortcomings of Workflow. Anyone who has tried to put together a business case for buying SOA/BPM will know the entire proposition will be a non-starter.

Understanding the business processes exist at 2 levels (the Silicon and the Carbon) takes us a long way towards understanding how we solve this problem. The key point is to recognize that the unpredictable actions of the carbon components are not ad-hoc processes, nor are they exception handling (ask anyone with a six sigma background about exceptions and you’ll understand very quickly what I mean). This is all about the unstructured interactions between people – in particular knowledge workers.  These unstructured and unpredictable interactions can, and do, take place all the time – and it’s only going to get worse! The advent of social networking, SaaS etc. etc.,  are already having, and will continue to have, a profound effect on the way we manage and do business.

Process based technology that understands the needs of people and supports the inherent “spontaneity” of the human mind is the next logical step, and we might be tempted to name this potential paradigm shift “A Business Operations Platform”. [1]

But what makes a BOP different from what’s gone before?

One of the key innovations (and there are many) is the collaborative nature of the platform. At last there is an environment that allows, encourages even, the business world and the technology world to align. Given that the business process is where these two worlds collide then the BOP becomes the place where the two worlds can achieve the most in terms of collaborative development and common understanding. Eliminating decades of misunderstanding. The Business Operations Platform does six main jobs.

It:

  1. Puts existing and new application software under the direct control of business managers.
  2. Facilitates communication between business and IT.
  3. Makes it easier for the business to improve existing processes and create new ones.
  4. Enables the automation of processes across the entire organization, and beyond it.
  5. Gives managers real-time information on the performance of processes.
  6. Allows organizations to take full advantage of new computing services.

Unlike early BPM offerings that were stitched together from fragments of technologies past, a BOP must be built on a standards-based and modern architecture.. With a service oriented architecture (SOA) and full BPM capabilities companies can create a complete business operations environment that can drive innovation, efficiency and agility for their enterprise. It must be Cloud enabled and capable of being deployed as BPMAAS as. It is the BOP that sets “enterprise cloud computing” apart from “consumer cloud Computing”

So why does workflow suck? It sucks because it made the fatal assumption that a business process was simply modelled as “a to b to c” – but business, as we all know, doesn’t quite work like that. BPM succeeds because of the heritage these products is in the workflow world – but BPM sucks as well because it ignores the requirement to include people.

Jon Pyke


[1] Since I wrote this paper Gartner coined the term “Intelligent BPM” but that begs the question as to what went before “Stupid BPM” ? So I’ll use BOP if that is OK with you the reader.

The post Why Workflow and BPM Suck appeared first on Cloud Computing Best Practices.

Read the original blog entry...

More Stories By Cloud Best Practices Network

The Cloud Best Practices Network is an expert community of leading Cloud pioneers. Follow our best practice blogs at http://CloudBestPractices.net

@MicroservicesExpo Stories
In a crowded world of popular computer languages, platforms and ecosystems, Node.js is one of the hottest. According to w3techs.com, Node.js usage has gone up 241 percent in the last year alone. Retailers have taken notice and are implementing it on many levels. I am going to share the basics of Node.js, and discuss why retailers are using it to reduce page load times and improve server efficiency. I’ll talk about similar developments such as Docker and microservices, and look at several compani...
Admittedly, two years ago I was a bulk contributor to the DevOps noise with conversations rooted in the movement around culture, principles, and goals. And while all of these elements of DevOps environments are important, I’ve found that the biggest challenge now is a lack of understanding as to why DevOps is beneficial. It’s getting the wheels going, or just taking the next step. The best way to start on the road to change is to take a look at the companies that have already made great headway ...
In 2006, Martin Fowler posted his now famous essay on Continuous Integration. Looking back, what seemed revolutionary, radical or just plain crazy is now common, pedestrian and "just what you do." I love it. Back then, building and releasing software was a real pain. Integration was something you did at the end, after code complete, and we didn't know how long it would take. Some people may recall how we, as an industry, spent a massive amount of time integrating code from one team with another...
From the conception of Docker containers to the unfolding microservices revolution we see today, here is a brief history of what I like to call 'containerology'. In 2013, we were solidly in the monolithic application era. I had noticed that a growing amount of effort was going into deploying and configuring applications. As applications had grown in complexity and interdependency over the years, the effort to install and configure them was becoming significant. But the road did not end with a ...
I have an article in the recently released “DZone Guide to Building and Deploying Applications on the Cloud” entitled “Fullstack Engineering in the Age of Hybrid Cloud”. In this article I discuss the need and skills of a Fullstack Engineer with relation to troubleshooting and repairing complex, distributed hybrid cloud applications. My recent experiences with troubleshooting issues with my Docker WordPress container only reinforce the details I wrote about in this piece. Without my comprehensive...
As the software delivery industry continues to evolve and mature, the challenge of managing the growing list of the tools and processes becomes more daunting every day. Today, Application Lifecycle Management (ALM) platforms are proving most valuable by providing the governance, management and coordination for every stage of development, deployment and release. Recently, I spoke with Madison Moore at SD Times about the changing market and where ALM is headed.
The goal of any tech business worth its salt is to provide the best product or service to its clients in the most efficient and cost-effective way possible. This is just as true in the development of software products as it is in other product design services. Microservices, an app architecture style that leans mostly on independent, self-contained programs, are quickly becoming the new norm, so to speak. With this change comes a declining reliance on older SOAs like COBRA, a push toward more s...
Small teams are more effective. The general agreement is that anything from 5 to 12 is the 'right' small. But of course small teams will also have 'small' throughput - relatively speaking. So if your demand is X and the throughput of a small team is X/10, you probably need 10 teams to meet that demand. But more teams also mean more effort to coordinate and align their efforts in the same direction. So, the challenge is how to harness the power of small teams and yet orchestrate multiples of them...
Many private cloud projects were built to deliver self-service access to development and test resources. While those clouds delivered faster access to resources, they lacked visibility, control and security needed for production deployments. In their session at 18th Cloud Expo, Steve Anderson, Product Manager at BMC Software, and Rick Lefort, Principal Technical Marketing Consultant at BMC Software, will discuss how a cloud designed for production operations not only helps accelerate developer...
Much of the value of DevOps comes from a (renewed) focus on measurement, sharing, and continuous feedback loops. In increasingly complex DevOps workflows and environments, and especially in larger, regulated, or more crystallized organizations, these core concepts become even more critical. In his session at @DevOpsSummit at 18th Cloud Expo, Andi Mann, Chief Technology Advocate at Splunk, will show how, by focusing on 'metrics that matter,' you can provide objective, transparent, and meaningfu...
SYS-CON Events announced today that Peak 10, Inc., a national IT infrastructure and cloud services provider, will exhibit at SYS-CON's 18th International Cloud Expo®, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. Peak 10 provides reliable, tailored data center and network services, cloud and managed services. Its solutions are designed to scale and adapt to customers’ changing business needs, enabling them to lower costs, improve performance and focus inter...
In the world of DevOps there are ‘known good practices’ – aka ‘patterns’ – and ‘known bad practices’ – aka ‘anti-patterns.' Many of these patterns and anti-patterns have been developed from real world experience, especially by the early adopters of DevOps theory; but many are more feasible in theory than in practice, especially for more recent entrants to the DevOps scene. In this power panel at @DevOpsSummit at 18th Cloud Expo, moderated by DevOps Conference Chair Andi Mann, panelists will dis...
Last week I had the pleasure of speaking on a panel at Sapphire Ventures Next-Gen Tech Stack Forum in San Francisco. Obviously, I was excited to join the discussion, but as a participant the event crystallized not only where the larger software development market is relative to microservices, container technologies (like Docker), continuous integration and deployment; but also provided insight into where DevOps is heading in the coming years.
Wow, if you ever wanted to learn about Rugged DevOps (some call it DevSecOps), sit down for a spell with Shannon Lietz, Ian Allison and Scott Kennedy from Intuit. We discussed a number of important topics including internal war games, culture hacking, gamification of Rugged DevOps and starting as a small team. There are 100 gold nuggets in this conversation for novices and experts alike.
The notion of customer journeys, of course, are central to the digital marketer’s playbook. Clearly, enterprises should focus their digital efforts on such journeys, as they represent customer interactions over time. But making customer journeys the centerpiece of the enterprise architecture, however, leaves more questions than answers. The challenge arises when EAs consider the context of the customer journey in the overall architecture as well as the architectural elements that make up each...
Much of the discussion around cloud DevOps focuses on the speed with which companies need to get new code into production. This focus is important – because in an increasingly digital marketplace, new code enables new value propositions. New code is also often essential for maintaining competitive parity with market innovators. But new code doesn’t just have to deliver the functionality the business requires. It also has to behave well because the behavior of code in the cloud affects performan...
Struggling to keep up with increasing application demand? Learn how Platform as a Service (PaaS) can streamline application development processes and make resource management easy.
If there is anything we have learned by now, is that every business paves their own unique path for releasing software- every pipeline, implementation and practices are a bit different, and DevOps comes in all shapes and sizes. Software delivery practices are often comprised of set of several complementing (or even competing) methodologies – such as leveraging Agile, DevOps and even a mix of ITIL, to create the combination that’s most suitable for your organization and that maximize your busines...
Digital means customer preferences and behavior are driving enterprise technology decisions to be sure, but let’s not forget our employees. After all, when we say customer, we mean customer writ large, including partners, supply chain participants, and yes, those salaried denizens whose daily labor forms the cornerstone of the enterprise. While your customers bask in the warm rays of your digital efforts, are your employees toiling away in the dark recesses of your enterprise, pecking data into...
You deployed your app with the Bluemix PaaS and it's gaining some serious traction, so it's time to make some tweaks. Did you design your application in a way that it can scale in the cloud? Were you even thinking about the cloud when you built the app? If not, chances are your app is going to break. Check out this webcast to learn various techniques for designing applications that will scale successfully in Bluemix, for the confidence you need to take your apps to the next level and beyond.