The Eclectic Zone

[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 Salesforce.com 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.

Conclusion

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…!