Defining BPM and State thereof – The Perspectives at Play

[tweetmeme source=”ashish_bhagwat” only_single=false]

I’ve been involved in some “happening” discussions recently on whether we need to define or redefine (or refine the existing definition of) BPM. Theo Priestly brought up few trends to sum up that it’s time to ‘define’ BPM for the new era. Steve Towers asked on Linked In if we can clearly re(define) BPM. The information on BPM on Wiki looks insufficient to cover various perspectives that prompt the community to keep coming back to the questions on definition of BPM, or relevance of the current definitions to the present context. We have had many attempts in past to define BPM and the terminology, but questions keep coming up. And we also have the trends on blurring of boundaries in BPM ecosystem that I blogged about earlier.

My general opinion on this is that it’s really not so important to put another definition on BPM (I mean at least in terms of semantics). We have seen hundreds of definitions on BPM by now and most cover the objective part pretty much in coherence with each other. Debates start when we enter the approach zone, i.e. the How part. In fact, I have not found any direct correlation between tagging an initiative as BPM with the success of the initiative against what would be common BPM objectives (noted through a post earlier).

In order to understand where these views and discussions are stemming from, it’s important to understand the various perspectives that are at play in the BPM domain. Every perspective brings with it certain expectations and since we have people from all perspectives trying to address the same question, the seemingly conflicting views (where in reality they may all be saying the same thing) amplify the questions further, just because there’re questions doing the rounds.

Business Strategy Perspective

Because we have the qualifier “Process” in the term, BPM is normally associated with Process Performance. However, a Business Process Performance is directly linked with the way the organization conducts business. The Strategy, and the next level dimensions on business capability directly stem from Processes and People. In pure Business Process Excellence terms, consultants find it difficult to dissociate BPM initiatives from the business strategy. This is especially true for larger initiatives on BPM. And many a discussion around the Outside-In v/s Inside-Out debate originates from this perspective.

Business Operations and Process Improvement Perspective

Business Operations are the most directly impacted area from application of BPM in the business process sense. From this perspective, the end-to-end BPM lifecycle is Envisioning/Defining the Processes – Executing the Processes – Monitoring the Processes – Analyzing and Optimizing the Processes. At the Business Operations level, however, there are various methodologies which have been used for decades on Process improvements. It can be said and has been debated as well, that one may be practicing BPM when managing processes in some of the traditional ways and with little help from the contemporary tools. The point is not whether I endorse the view or BPM community in general does, or not, the view remains.

Technology Perspective

Every stage and every aspect of the end-to-end BPM lifecycle on Business Operations side has an associated technology aspect with it. The technology view of BPM covers the lifecycle as Business Process Modeling and Design – Business Process/Systems Integration – Business Process/Workflow Execution/Orchestration – Real-time Process Monitoring and Analytics – Process Simulation, Analysis, and Optimization – Process Performance Reporting. Architects mix and match various available business solutions & packaged applications along with the BPA/BPMS/BAM/SOA and other supporting technologies to address their needs. A lot of BPM may happen at the end-to-end technology level in an organization with the BPA and BPMS tool playing just a part in it. (Some of these supporting technologies are covered in my earlier post on convergence.

Product Vendors Perspective

Next level down from Technology is the mapping with various product vendors offering solutions in one or more or all parts of the cycle. So, this subdivides the BPM landscape further based on BPA, pure-play workflows, Integration-centric BPMS, Human-centric BPMS, Platform vendors, business domain-specialists tools, BAM, and recently we have had a lot of discussion around Case Management and Adaptive process Management too. This is one area where vendors from all areas claim their pieces of the pie. Now, these vendors representing a piece of the pie may go to customers and present themselves as full BPM solution for the customer needs. They may be right in the context of the needs of the customer, but various slices and dices of capability all representing one case for BPM is seemingly impossible. And for every one of these pies, there are multiple tools available, and still coming up. For instance, Theo has a list of 70+ vendors for BPM vendors, and still growing. There’s further complication from the clouded services gaining ground in business solutions – some of them wrapped as Process solutions in cloud. Does that make a BPM vendor in that case? I shared some views on this earlier that raised serious debates on BPM in cloud and established that some degree of BPM in the cloud is already gaining ground.

BPM as a Discipline

This is the methodology and approach view of BPM. From the time BPM came into being, there have been efforts at defining the terminologies, methodologies, best practices, rules of conduct and so on. This is Analysts’ and Practitioners’ field of sharing what works, what doesn’t and also act as the advisory for people wanting to follow BPM principles. This view combined with the supporting technologies set ought to cover all that is required in BPM; obviously there are other views at play that are making this more complicated than it should be (The reason for this post’s existence!)

BPM structures within Organizations (Organizational Perspective)

Most of the perspective above are operating outside the enterprises where BPM is supposed to be taking shape in form of a solution to the problems identifies as the target set for BPM in the context. Within the organization, however, there’s business that gets swayed by the Strategy, Operations and little bit of discipline perspectives, and then there’s IT that is driven by the technologies, product vendors and disciplinary perspective. Purchase decisions for technology are done within the IT. Business initiatives are funded through business plans against those initiatives. Certain purely operationally oriented initiatives are kicked off, and consummated within the business – with IT being the follower if any systems impacting decisions are made in those. In the meanwhile, and all the time, IT focuses on building the platform as per the technologies view that may not directly align with the business priorities all the time. Then, there’re various patterns of how the BPM Competencies can be driven and brought to maturity in the organization. Lot of these situational conflicts are amplified and visible at the industry level with the BPM community also swaying with their counterparts in the respective customer organizations.

Enterprise Architecture (Enterprise BPM) Perspective

Interestingly, there’s a debate on what’s happening with Enterprise Architecture on LinkedIn that continues to be hot and burning topic. There are debates on whether the EA should be associated with IT or not, and some other very relevant questions on EA. In the contexts of organizations (the previous point), I have seen various Enterprise Architecture strategies cover “BPM related areas” very differently. In some organizations EA gets divided under focus areas as Process Architecture, Data Architecture, Applications Architecture, and so on. What’s interesting is that the Process Architectures could be defined within the confines of Business functions with or without the usage of any standard BPA tools. Definition of certain modeling standards start falling somewhere between business and IT, and when you come to implementation of those processes, the IT systems may or may not be using any of the standard BPM tools but still powerful enough in terms of offering the capability in line with BPM. And in some other cases, there may not be a well defined Process Strategy at EA level, the solutions architectures from function to function start piecing together different solutions that end up becoming too conflicting to standardize on one practice or product for BPM at Enterprise Architecture level. The BPM philosophy recommends starting small and increment iteratively, but by the time various such initiatives land Enterprise ship, they’re running in different directions.

BPM Industry Perspective (Maturity Wave and Consolidations)

BPM industry has gone through various stages of consolidation, and there are various views on this consolidation from different analyst firms. For convenience, I will pick up the one from Forrester that defined these waves as “Market Entry”, “Technology Build-out”, and “Business-Technology Shift” in chronological order. With every move in the consolidation, the definitions have expanded in few areas, and restricted in few other. The standards like BPMN, BPEL, XPDL have taken their time to come to mainstream. Gartner has been bringing up terms in the Hype cycle based on the trends that pick up speed & (and dropping those that lose speed) year by year. Terms like BRE, BPMS, and BPA have become mainstream and common, while some others like Business Process Networks are still topical. We’re also seeing the trends on collaboration, Social Networking, Adaptive Process Management that continue to impact the navigation path for BPM. Regardless of whether social is treated as a phenomenon, discipline or technology, the impact definitely continues to make the definition efforts harder.

and some more…

I’m also tempted to bring more perspective, and the top three doing rounds in my head are Innovation, Project Management Discipline, and Software Engineering. But, I think one would get the point now and bringing these additional perspectives in would look too contrived and akin to beating this to death! And also, my fingers and mind can use some rest… 🙂 – But those are interesting ones and need to be covered some time. For now, sharing one from Keith Swenson on BPM and Software Engineering.


There’s no single direct conclusion that can be drawn from the discussion above. Many points made above may actually raise further debates. One conclusion that I *hoped* we could draw was that with so many perspectives at play and with BPM community comprising multiple sub-communities with heterogeneous views, it is darn too difficult to define BPM that covers all the aspects and still satisfies everyone. It could remain a play with semantics while situations on the ground may continue to raise questions whenever different parts of the community swayed by different perspectives come together.

So, I continue drumming my beats that Synergy, wherever possible and relatively easier, should be driving our multiple efforts. When it comes to defining BPM, it will always be in a certain context and when a customer looks for the right definition, the questions that need to be asked are – what’s your business’s objective, and what’s the problem you’re trying to solve. And then, one should just go ahead and fix the problem with short term and long term interest of the Enterprise. BPM, at the end of the day needs to make the business more agile & responsive and business processes more efficient, flexible and manageable.

Agree to everything? Not possible! Bring in the debate…!


, , , , , , , , , , , , , ,

  1. #1 by A. Samarin on April 13, 2010 - 6:27 am

    Also, enterprise roles can be used as different perspectives — see

    1.8.4 Common understanding among everyone involved

    We have observed that improving a BPM system requires a lot of communication with practically everyone within the enterprise, and everyone should be treated as a stakeholder of the BPM system. Each group of stakeholders has different views, different concerns and a different understanding of the BPM system. The different groups of stakeholders are generally the following:
    -top managers
    -enterprise architects
    -business line managers
    -process owners
    -normal users
    -project managers
    -business analysts
    -IT managers
    -IT solutions architects
    -IT developers
    -IT operators

    It is necessary to explain to each group of stakeholders how their concerns will be addressed and how their current working practices will be changed for the better (see also 3.3 and 3.4). (This is a typical duty of the chief architect of the BPM system.) Coherent and clear explanations in the business language are vital for the success of a BPM project. Success is not about saying “Yes” to all requests from the “more important” staff members; it is about building a common understanding and agreement between all stakeholders. This book is intended to help you achieve such success by giving some real examples of communication with the business staff (see chapters 3 and 7).


    • #2 by Ashish Bhagwat on April 13, 2010 - 12:56 pm


      You’ve brought up what I refer to as another predicament, if you will, of BPM within the enterprise. However, it’s not actually as complicated as the long list of stakeholders may make it seem, I have found remaining true to the purpose of the BPM exercise and getting behind the customer problems a very reliable guider to remain on course.

      Thanks for sharing!

      – Ashish

  2. #3 by Doug McDavid on April 13, 2010 - 7:46 pm

    I wonder if there is room in the BPM definitions to cover the human side of the equation? In other words, what do the process executors (process owners?) experience in the totality of process execution? Do they get a vote in BPM as you think of it? Can they provide the insight to improve or reengineer processes? Can BPM methods track the monetary impact of such improvements or (re)engineerings?

    I have recently become a partner of a firm that focuses on the issues I mention. I just wonder if there is a place for those kinds of of thoughts? Perhaps it is my experience supporting BPM enabled by SOA at IBM before I retired, where the focus was on automating and round-tripping management of processes via the tool stack.

    • #4 by Ashish Bhagwat on April 14, 2010 - 1:00 pm


      There’s not just a place in the corner but a whole field reserved for human side of the processes. Or, at the risk of raising some heckles, I can say that workflow management that is core to BPM actually came into existence due to the requirements on the human side of process management. Often Process management may be confused with Process Automation, which is not true.

      Actually thanks to the last statement that you added that your focus was primary on the automated processes or integration-oriented Process, I can understand the background to your question. IBM, TIBCO, Oracle have been “traditionally” focused on the Integration/middleware/platform side of the applications and processes. (They have all been consciously trying to focus on human side with IBM-Lombardi, TIBCO-Staffware, Oracle/BEA(ALBPM-Fuego) acquisitions. Vendors like Appian, Lombardi, Pega, Savvion, G360 are focused more on human-centric BPM with add-on capability on integration.

      Short Answer: Crossover, or fuse in, as soon as possible to the human side of processes!

  3. #5 by Doug McDavid on April 15, 2010 - 4:24 pm

    Thanks for the reply Ashish. I raised the question because I have long been a proponent of the human and social side of business. I mentioned my experience with the BPM enabled by SOA as just one example of where I ran into contention with my IBM colleagues. I think I made enough people uncomfortable (backed up by my position in the IBM Academy of Technology) that the powers that be asked if I would like to take early retirement (with the justification that there was no market for my ideas). Now that I am “on the loose” I have not need to adhere to the Big Blue party line (a constraint that caused me to remove myself as the IBM representative to The Open Group working group on business architecture when it became clear that I was representing my opinions, and not those of IBM. I have tried to neutralize the techno-bias of “architecture” and have brought many threads of thought together (general systems theory, etc.) on a website where I am thinking out loud about these issues ( It does seem that there is some thinking out in the world that is edging this direction, so that is definitely encouraging for me.

  4. #6 by Nick Malik on April 16, 2010 - 2:20 am

    Interesting Article. You do a good job of describing the perspectives that intersect BPM. As an Enterprise Architect, I see BPM from both the “outside-in” and the “inside-out” perspective (although I’m not fond of those particular words). There are some interesting discussions along those lines. In EA circles, we tend to settle on a third option: “Middle-out.”

    In this paradigm, a high level framework of business capabilities is laid out and a model of business concepts and terminology is asserted “from above. Then business processes are modeled, as needed, by various lines of business, and attached to that capability framework. The middle out approach avoides the “Big Design” and “Analysis Paralysis” problems that come with imposing a full process hierarchy, while avoiding the “Overlapping Charters” and “Tower of Babel” problem that comes from disconnected process improvement projects created ad-hoc around the company.

    I wonder if you think the middle-out option would be a valid “third way” for BPM?

    • #7 by Ashish Bhagwat on April 16, 2010 - 5:03 pm

      @Nick, what you mentioned as “Middle Out” approach does make sense, but there’s nothing wrong with the Outside-In, or Incremental-Iterative, and many other approaches as well, at least on paper. It’s a matter of how one executes any of these on the ground, isn’t it? A “Middle-Out”, the one you mention, badly executed could look as dirty – and in fact it’s difficult to get it perfectly right the first time with all the structural and behavioral patterns that are at play – as I mentioned in the Organizational perspective above.

      Well, I don’t personally consider it worthwhile enough to get into these debates as to which approach is the sacrosanct & guaranteed to succeed since in reality, none is 🙂 All a matter of aligning what an enterprise wants to do, with the tools that are available to them, and matching your abilities and intentions in the best possible way with those…

      And @Doug, nice to hear you cross over.. 🙂 welcome aboard!

  5. #8 by Peter Brand on May 2, 2010 - 4:30 pm

    That the ‘perspectivse at play’ are numerous, as they of course are, does not imply that they all should be spread out to be considered, since this will end up in overwhelming complexity.

    It seems, success in overcoming the BPM-induced mismatch of IT and Business requires just the opposite, to identify the one single perspective under which BPM can (und must) be rationalized in order to reveal its uncurable deficiency.

    According to my reasoning and experience, the perspective is TECHNOLOGY TRANSFER,

  6. #9 by Ashish Bhagwat on May 2, 2010 - 4:36 pm


    I agree we need to find a common rationalizing element, and finally it seems almost everything in business could get swept under the BPM carpet in that attempt 🙂

    I don’t agree with “Technology Transfer” – can’t be Technology oriented *only* if you really want to do justice with what BPM means to achieve…

  7. #10 by Peter Brand on May 2, 2010 - 4:38 pm

    Hi Ashsish

    … that the ‘perspectives at play’ are numerous, as they of course are, does not imply that they all should be spread out to be considered, since this will end up in overwhelming complexity.
    – – –
    It seems, success in overcoming the BPM-induced mismatch of IT and Business requires just the opposite, to identify the one single perspective under which BPM can (und must) be rationalized in order to reveal its uncurable deficiency.
    – – –
    According to my reasoning and experience, the perspective is TECHNOLOGY TRANSFER, in particular: WEB-TECHNOLOGY TRANSFER. Within this context not only the methodological error of EAI/BPM/SOA philosophy can readily be seen, but – much more important – an alternative paradigm comes into reach, which I denote as ‘Workstate Management (WSM).
    – – –
    To the effect that I (you?) need no longer strive to define or defend BPM. Just let it go)

    If interested, you may visit (mySite)

    Thanks, Peter

    [soory for hitting the wrong key during typing, making elaps the above frament, unintendedly]

    • #11 by Ashish Bhagwat on May 2, 2010 - 4:50 pm

      Peter, Thanks for adding value to this discussion. Concept of WSM looks interesting, will check out

  8. #12 by Peter Brand on May 2, 2010 - 4:50 pm

    To be pecise, by Web-Technology transfer, I mean a philophy/theory/model about how technology is transferred into non-technology, here business-affairs.

  1. Process for the Enterprise » Blog Archive » Pragmatism vs. The Next New Thing
  2. BPM Quotes of the week « Adam Deane
  3. Quicklectic: Popular Posts and Redux Update « The Eclectic Zone
  4. Don Your Green and Blue Hats, BPM-the-Social-Way is much more! « The Eclectic Zone
  5. The Eclectic Zone Makeover… « The Eclectic Zone

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: