Skip to Content

Business process experts should stick to simply documenting processes and leave execution to IT…

Sorry for the provocative title; it was a cheap, transparent attempt to get your attention. If you’ve read this far, I’ll assume it worked. Just for the record, this statement represents the diametric opposite of how the NW BPM team and I feel.


We on the NW BPM team believe that the only way to design executable process optimally is for IT and business to collaborate in a deep, meaningful way. To some vendors in the market, this means that the business uses one model to describe an abstract business process that then gets transformed into a technical model that can be refined into something executable. We find the inevitable loss in translation associated with this approach to be simply too high a price to pay.


The truth is that the business often still specifies its intent using word processing documents, presentations and spreadsheets with no tie whatsoever to a “real” model. My opinion is that the business analyst is one of the most underestimated personas in the software industry. I believe strongly that with the right model and tooling, the business will someday design executable business processes.


Does this mean that IT is a discipline of the past? Absolutely not!


We’re betting on our ability to abstract executable concepts so that the business can compose executable processes. That means that IT will continue to generate artifacts like services but will then be able to expose these to business analysts in a via business-consumable abstraction. Other composite process artifacts, like UIs and workflows, could be created by business analysts and refined by development as necessary. Deployment of processes, itself a process, would be subjected to the appropriate governanace, both business and technical.


We believe this approach will allow the business to concentrate on the business and IT to concentrate on what they do best: delivering technical artifacts and managing the IT landscape.

You must be Logged on to comment or reply to a post.
  • While I am a fan of the idea of abstraction, this is also one of the most difficult things to do consistently in a project.

    Most often, if I ask a business user to describe his work to me – he will say something like”customer calls, then I go to the xyz website and create blah blah, then system gives me three options to choose…”. It takes a lot of time and effort to abstract the actual process from it. This is due in large part to the fact that when people move on in their career, their substitutes are only taught the mechanics of how something works (as opposed to the thought process behind it). After couple of transitions, all original knowledge is lost.

    The other difficulty is that it is hard to quantify the benefit of changing the mentality to an executable business process, from the curent state. Even with existing methodologies, it takes a lot of effort to push some one away from unstructured spreadsheets to an ERP system. My belief is that change management expertise is probably going to be a real hot skill in SAP soon.

    • Vija,

      it is my experience as well: business is quite happy to be on the abstract business level, and they react not very well to having to figure out all the data element formatting and exception handling cases you need to observe when building executable processes.

      In fact I think it is good when you have a manager, a process specialist and a programmer. Having a manager or process specialist have to deal with all the technical stuff is just a waste of everybodys time.

      To that extend I think the title is not too wrong.

      I know modelling experts who can talk to business and I know lots of business to have actually a peer in IT.


      • Hey Bernd,
        I know it’s becoming a trite analogy at this point, but I think of the business analyst experience I describe as being akin to the spreadsheet. Before this software category was defined, it was unthinkable that a non-technician would be able to create complex budget and forecasting models on their own. I’ve seen functional people, particularly in big accounting firms, create spreadsheets that inspired awe (and fear!) in me.

        It’s interesting to think about the “abstraction” spreadsheets offer relative to traditional programming paradigms; they’re so intuitive and commonplace today we forget that it really is a type of abstraction.

        • oh those spreadsheets ! I agree – they are brilliant abstractions in a “point in time”. However, since it is usually focussed on an individual’s point of view – it is not very adaptable to change, and is not designed with scalability in mind.

          A good example I have seen repeatedly is forecasting. It starts with a great spreadsheet, and then people keep changing the parameters and formulae often. A year later, it becomes impossible to trace back.

    • Thanks for your input Vijay. I think we need to crisply define the personas involved in managing a process throughout its life cycle. In my post, I’m referring to a business analyst who would work with the type of end- or operational user I believe you describe. In an upcoming post, I’ll talk about our view on personas and propose a “straw man” definition of a business analyst for the community to refine or even redefine!
  • Can business analysts create executable business processes in future? Why not?

    I suppose it takes a very very open mind, appropriate tools and training to make this happen.

    However, the question is – should they be creating executable processes and what is their extent of involvement?

    Are we talking about business analysts being able to design technical solutions all the way through programming?

    • I don’t believe that BAs will program. However, they should be able to use higher level abstractions to compose existing assets into custom solutions. If they need programming, they’ll engage with IT, but based on a common model.

      I believe that with the right abstraction and the right composable assets, business people will create executable processes. Some vendors claim that business folks are doing this today (they have BPM-like offerings that don’t require IT {they claim}).

  • Based on my experience, I believe not enough work is done with respect to business modelling, re-engineering and BPM.

    The separation of IT and business modelling whilst in partnership should remain in different skill base and execution.