Is BPM a 4GL? It Boils Down to Your Perspective

Scott Francis
Next Post
Previous Post
Jacob Ukelson writes:
What I think surprised me most is how little BPM is used by most development and IT shops for their own use. Even when a truly structured IT process is being implemented (like deploying an application into production) – the tools are never based on BPM suites.
Interestingly, when I worked at a BPM vendor, we used BPM to run our builds, tests, and other automated processes (with, admittedly, some human-facing steps).  We also built our support site with our BPM suite.  Both decisions were fantastic decisions from the perspective of having everyone eat our own dog food, as well as making experts out of people who might otherwise not become experts. Recently, I was talking with a startup that is into cloud infrastructure.  And they use a BPMS to make their deployments reproducible. Two data points don’t make for a statistically significant sample. A third anecdote sums up what I think Jacob is running into.  A few years ago I stopped by a friend’s startup in San Francisco.  He asked me what brought me to SF – long story short, I told him that my customer was using BPM to do some A/B testing around one of their core processes (a fulfillment process).  His response: “why do they need BPM for that?” and “why don’t they just write the code for that?” Well, the first question – this is the question one always hears – not just with BPM, but with all kinds of new software or productivity tools.  As I like to say “why not just write everything in assembly right?”  After all – the question is are we using the right tool for the job, not whether other tools could theoretically do the job. As to the second question – why don’t they just write code?  This is a pretty typical attitude for people who are really adept at writing code.  First, they don’t see a need to learn a new tool to get their job done – unless that tool is an API or a language. Second, they don’t see why anyone else should, either.  Third, they’re often suspicious of commercial software development tools vs. open source tools.  Fourth, they overestimate how many people of their skill level any given organization has at its disposal, and what else those same folks might be working on that is even more important.  What looks easy or obvious to them, isn’t obvious or easy to someone else. The way I try to boil this down is that the more abstract ideas and organization you have to hold in your own mind, the harder it is to do something.  A BPMS gives you the ability to let go of some of those difficult abstractions (they become models) so that you can hold the same problem and solution in mind with less abstraction – by holding only higher level abstractions in mind. Jacob worries that this might relegate BPM to a small niche, a la 4GL in the past.  It all depends on the definition of niche.  If a multi-billion dollar market is a niche, I won’t complain.  It was a niche when I started out in BPM.  It is a much bigger “niche” now.  

Tags:

  • Scott,
      I agree that it is a matter of perspective – you have a BPM bent so you see companies that do use BPM as part of their R&D efforts. My perspective is anecdotal too, but I see quite a few development organizations – and I can tell you I have never seen BPM as part of their toolset – nor was it on the table to even be considered. Even in companies that adopt BPM – it isn’t the pervasive tool for app development – but rather used for specific “process management” initiatives

    For me that begs the question – “When should a BPM be used?” If you ask the vendors (and some analysts) the answer is a short – “for implementing and business process whether structured or unstructured”. So essentially for anything – including R&D and its processes.

    That of course isn’t true in the real world – some development activities lend themselves to BPM, others don’t. It would be good for someone to actually define the boundaries of – somewhere between “never” and “always”. That place is BPM’s niche – you can do a lot of good, and make good money in niche. The problem happens (like with 4G languages) when people try to use the tool outside its niche – then the negative backlash can kill it.

         Jacob

    • The problem with “when should a BPMS be used” is that there are too many variables to give you clean boundaries. It is a bit like saying when should email be used instead of a phone call.  Well, in hindsight it is often obvious but there is a lot of overlap and although the “rule” can be simply stated, the flexibility allowed by human judgment is large. 

      For BPM, I ask a few questions (and drill down from there):
      – is it a business? (ie, the problem statement is about the business)
      – is it valuable? is it costly? does it happen at volume? (all related)
      – is it a process?

      Typically I don’t have to ask questions like “is there a COTS solution for this?” because that question was asked before anyone looked at BPM as an option. 

      Regarding the cloud company I mentioned, FYI – they have no relation whatsoever to BPM.  It was simply a conversation about what they were doing where they volunteered that they were using a BPMS when I explained what BP3 does.  Sadly they weren’t asking for help from us for their BPM efforts ;)

      you wrote: “For me that begs the question – “When should a BPM be used?” If you ask
      the vendors (and some analysts) the answer is a short – “for
      implementing and business process whether structured or unstructured”.
      So essentially for anything – including R&D and its processes.”

      I disagree with that characterization.  Vendors and analysts typically say something to that effect – but that doesn’t mean that “anything” is included.  If someone says “Java is for writing code” – does that mean all software is included?  Well, potentially.  But it doesn’t mean that as a software engineer you wouldn’t pick a different language (say, Ruby) for some situations – even though Java could also solve the same problems… The art of software engineering (and business process management) is often knowing how to select tools that support your efforts.

      • Scott,
           I understand that there can be no exact definition of when to use a BPMS – but I do think there can be a characterization of the type of problems best addressed by a BPMS – and even more importantly – which shouldn’t. I don’t mind that vendors claim that their BPMS can do everything – they are in the business of selling, but it bugs me when analysts do that -since they are supposed to be on the side of customers.

         I like your programming language analogy – there should be something equivalent for BPMS – it doesn’t need to be a tight definition – but at least a shared understanding about when you would and when you wouldn’t use a BPMS. I don’t think that shared understanding exists. It is clear that you and your team have an understanding of BPMS capabilities and limitations – but it seems that is an exception, not the rule.

          I think this ties back into the ACM vs BPM conversation – it is clear that BPMS have severe limitations when managing knowledge work – but you wouldn’t have known that talking to analysts. Only after Keith Swenson put together the ACM workshop and the “Managing the Unpredictable” book did analysts (and vendors) follow. I actually think that the ACM discussions may be BPM’s best hope not to be a niche product,  but I also know that we really don’t understand enough about ACM yet – even though many analysts and vendors would claim that they know the answer.

         

      • Jacob – I was with you all the way to the last paragraph… and then we diverge :)
        It isn’t clear that BPMS have severe limitations for knowledge work.  It is clear that some ACM proponents work for BPMS vendors that have severe limitations in this regard ;)  And I think this biases their opinion of a BPMS. 

        Nor is it clear that ACM/CM is used for knowledge work more often than BPMS in the market. The books and blogs were great, but most of the examples I’ve seen in blogs about ACM have been fantasy – for example pointing out the use of facebook and twitter and the like as “ACM like” as opposed to pointing out a tool that is marketed and sold as ACM natively and the actual problem it is solving, rather than the theoretical problems it could solve.  It is a bit like watching an Apple iPhone commercial – they advertise ACTUAL apps, capabilities, and uses in the ad (but sped up a bit for the sake of timing in the commercial).  Then, you watch the android commercial, or the RIM commercial, and you see all kinds of CGI graphics for things the phone cannot do or hasn’t done in the real world. It is time for ACM discussions to focus on actual solved problems and not on theory, if they’re to compare and contrast with a BPMS in a favorable light.

        The kinds of things that i would carve away from a BPMS go in a different direction – CRM applications, glorified data maintenance applications, etc. 

        (parenthetically, what I find ironic – we use an ACM tool to manage the most mundane work we do at BP3.  not the most interesting knowledge work – but the most mundane repetitive work that isn’t worth the investment in automating.  That’s not a very glorious role for ACM, but it may be where it is headed – the task list for BPMSes…  )

      • Scott,
          I actually like your “task list” analogy – I think smart management of checklists is a core ACM requirement. Other ones are participant control (especially of flow, but not only), feedback and auditability replacing control, goal (vs flow) orientation, document mangement, meeting support,  etc. As I keep saying, for me we’ll know ACM has succeeded when it replaces (or is a standard augmentation of) current tools for knowledge work – email, task lists, documents.

           ACM suffers from same problem as BPMS in that its definition is in the eyes of the beholder, and the arguments take sort of religous fervor about what is, and isn’t ACM. So I didn’t mean ACM is panacea – just that it suddenly sprung up because of a growing uneasiness around the mismatch between knowledge worker needs and BPMS capabilities.

           I think your usage of BPMS and ACM is unusual – and exactly the right thing for a consulting company (eating your own dog food). However, as I have said in my blog – whenever I go to a BPM conference and ask participants whether they use BPMS for their own everyday work – the answer is always an empty set – or as Keith puts it – they all think that BPMS is great for “other people’s knowledge work”.

         

      • Jacob

        The definition of ACM / BPM has gone on, and on, and on, but to me it is quite simple.  

        BPM can automate BPs that operate within a domain that can be specified by traditional rules and other automation techniques.

        ‘Cases’ are required when the BP is so unstructured (or the underlying functions and processes are manual) that a human has to interpret the data coming back and react on an educated but largely ad hoc basis. There may well be bits of the case that can be automated using BPM, so these concepts and solutions are often nested.

        We used to call problems that needed case management as needing ‘carbon-based logic’ vs. BPM that was ‘silicon-based logic’ :-) 

        Best …  Jeff

      • A side-note-  even the definition of “Automation” is flexible. 
        To my software ears, automation means lights-out code running. But
        often when I talk to customers, automation means eliminating manual
        integrations and busy work – but not at all trying to accomplish
        lights-out.  For example, if today work is handed out on stacks of
        paper, “automation” might mean that the work gets routed via software
        (whether or not a person made the decision about where to push the
        work).

        For bp3, BPM is not just about automation.  But we realize that’s how some people look at it.  So we focus less on definition of that term and more on what the customer objectives are (and how to get there). 

        I forget who said this not too long ago but the thought struck with me – that BPM is about eliminating the mundane so that users can focus on the value-adding activities. 

      • I like the Keith quote :)  the only problem is, the same thing is true for ACM – if you ask the same question, you’ll get the same null-set.  Apparently ACM is good for other people’s knowledge work ;)  Of course the other issue is that this is like the shoemaker’s children going barefoot.  When you’re busy making shoes for others you never have time to make shoes for your own kids. 

        But there’s another thing at work.  Several of our customers’ users wouldn’t even say that they use BPM.  They use something that has a name.  Or the execute a process that has a name. But they don’t think of “it” as “BPM”.  Maybe that’s a marketing problem for BPM projects but I’m not too worried about that as long as the projects are adding value.

    • Jacob

      When I was running HSBC’s (the largest bank in the world at the time) Enterprise and IT Architecture strategy and teams we adopted “The Right Tool for the Right Job” mantra for technology selection. It was our flagship slogan!

      In order to put some meat around the marketing, we asked each of the technology domain owners to prepare a set of simple questions that led people to select technology appropriate for the task at hand.  Many times these questions were represented instead as classic 2×2 grids. These were not used to dictate, but to inform the decision makers and received wide acclaim across the company as flexible and easy to understand. “It just has to make common sense” I used to tell my domain owners.

      I think in your specific case of deployment automation, the primary issue is the people making the selection. In most shops, deployment is managed by an Infrastructure team or an Operations team, not by a Development team. Ops and Infra people ‘generally’ buy all their solutions from established vendors (HP, IBM, Oracle, etc) and patch up the holes in the purchased solutions with hand coded scripts. They are not developers in the classic sense, they do not use a SDLC to define their process, and if you asked them to do so they would fail miserably, and pine to ‘just let me get on with my project!’

      My two cents ….  

      Jeff

      • Jeff – thanks for adding your perspective, and I think your approach makes a lot of sense – give decision-makers a tool to inform their decision-making but let them make the tradeoffs. 
        People sometimes groan at seeing another 2×2 chart but for some things it is the right kind of visualization.