BPM vs SOA

Thanks Parveen for bringing up this topic - I love it :-) In my view, it depends how you define both terms. For example, if you understand BPM as a business discipline but SOA as a technology stack, SOA is part of BPM. So what is your definition/understanding of both terms?

That's been coming again and again for some time now (just recently I read this). It seems that the pleasure from this debate alone is bigger than the potential of its outcome :) Still, it's all about paradigm creation. Vendors coin new words depending on their marketing objectives, academics don't have enough time to catch up with the new dynamics and customers for some time buy new paradigms and depending on their maturity and size, influence the paradigm lifecycle one way or another. So one day capability mapping is better than process mapping, SOA is much better than process/application integration and of course nobody is doing data warehouse anymore, it's BI at least.

Ivo, indeed. You can even do a whole PhD about this issue and don't come to a conclusion ;-)

Sebastian, does that mean you were cheating or lazy?   ;-)

But to be serious - IMHO both things are part of the Enterprise Architecture activities in an organization and only looking on one part of an EA will give you just a limited picture of what happens in your organization.

I know it is old-fashioned, but I think that the 3 tiers (process architecture - systems/services/data - technology) is stil the right way to look at this. Even though I understand (and agree with Ivo) that marketing demands to invent the game changing, paradigm-shift, breakthrough inventions sometimes, some basic things still are true and weather the storm.

Roland,

Yes, both things are part of the EA but shouldn't we solve that first? I don't see general convention on the way BPM and EA relate. There seems to be be an agreement that EA has broader scope an is more high level. I don't agree with the latter, EA should be all-level. And working with ARIS for almost 10 years now I have a problem agreeing with the former as well. ARIS method is a full blown EA from the outset when only John Zachman and a few other were using the term EA and even prof. Scheer didn't. While later all other vendors developed in a workflow centric direction, the EA and the "BPM" took separate paths while the all-inclusive ARIS was left somewhere in the middle and had to "catch up" paradigm-wise (not technology wise) re-inventing EA within ARIS method which was done with almost 0 additions and then catch up with "BPM"-flow adding BPEL and BPMN.

Now, SOA and EA. There seems to be a general agreement that SOA is part of EA. However, all SOA I saw in practice is only about web services, application integration and B2B solutions. The general SOA approach exists in slides, papers, manifestos and blogs but when it comes to realization it's another story. No wonder there is almost no SOA in TOGAF9. I really see services as a very important cohesion concept in EA, based on the encapsulation principles: separation of concerns, modularity and loose coupling. The place of services in EA was discussed some time ago in the community but it was actually only a dialogue which proves my point.

And coming to BPM and SOA, tired, see my previous comment.

I see BPM and SOA as separate concepts. BPM is about modeling, implementing and monitoring business processes. One of the many possible ways to implement a business process is through the use of an SOA technology stack. SOA is a technology approach to implementation. It is likely only part of the technology stack required to implement a process these days.

I don't see how you could consider a business process a service. They are different concepts. A function within a process could be implemented as a service but not an entire process. In SOA terms a process would be described by an orchestration, that is a set of connected services.

Both of them would included within EA, assuming you take the broader approach to EA as including both business and IT components.

Rick,

I fully agree with "One of the many possible ways to implement a business process is through the use of an SOA technology stack". But I don't see BPM and SOA as very separate concepts. Actually I have problem seeing any two concepts in business and IT as seperate but in the case of BPM and SOA, or rather process and service, there is a very tight relation. We use process (or any action part of it for that matter) to represent important pattern of behaviour and service - to represent something that's of value to an element which is external to the active structure providing the service and looks at it as a black box. Hence any service is both result of some process and consumed by a process. So, there is some ground to look for relation but as I stated in my previous comments, I doubt there is value in the result of such debates. Or, let's put it this way: whatever your opinion on this is, if it works for you it's right.

Sorry, when I said separate I meant in the context of the discussion of one being "part of" the other. Certainly they are related like process and data are related. Each of the EA domains is separate in that it has it's own set of things that it is focused on and it's own rules and specialists. All of the domains are related in some way to other domains.

BPM must speak only about processes. How the processes are realised in an enterprise should be elaborated by SOA in an easier way than other EAI methodologies till date. BPEL is the glue between BPM and SOA. Both BPM and SOA are not matured enough to be called as standards. so an attempt to distinguish between them is like trying to take a stand on a shaking ground. we must wait and watch what happens in next few years. 

I've worked in the EAI space for a couple of years(around 4 years back) in my 13 year career till date. SOA was a buzz word in the existing exterprises at that time, and we used to come across "SOA enablement" initiatives from vendors like IBM. The notion of services always existed, but SOA has formalized them and with all the well-known advantages. The birth/necessity of any service is always driven by a business need, a value add provided to the business. Business process is a documentation of the business usecases with an intent to automate them. After a long break, i'm planning to hop back to the BPM space(hence my interest in this forum), and i see SOA being mentioned hand-in-glove with it.

The enabler for BPM/SOA is not so much technology, it is the political, structural and economic models that are missing from large scale implementations and on-going TCO. The large organisations I have worked with find it hard to scale out, or up from 'project land'.

BPM/SOA requires an uplift in people/practice/structures to support enterprise wide capabilities far beyond what business projects are prepared to be burdened with for their immediate need.

I am far more optimistic with BPM than with SOA though, as the business benefits are much more tangible. Enterprise wide BPM adoption can be the catalyst for Business and IT reform in support of a 'design for change' architecture that is BPM/SOA.

Yes. "Immediate need" is what people generally keep looking as they can showcase an instant ROI to the management. The SOA initiatives apart from other things, would attemtp to "normalize" the enterprise by bringing out the hidden services, make them reusable thus enhance future maintainability, etc. This is more like an future investment and may not show immediate end results functional/financial. Hence it will more often get difficult to find a champion(from the management) supporting the cause.

Yes, SOA way is more expensive than the traditional way within the first project and for many projects to come but is potentially with a better ROI in the long run. So with so many SOA failures around it takes some guts to go SOA way especially when the whole thing is culturally and technologically immature.

If it is about long run, it has strategic flavor. So is it mission for EA to be champion supporting the cause in form of BPM/SOA governance?

Hello Aris-ites,

I am a new kid on the block. The confusion above appealed me and here's my two cents' worth . I believe the SOA is the technology/protocol that provides a layer of control underneath BPM.  So SOA is more of the design/implementation detail whereas BPM is not a technology but a method to run a business.

BPM does not require SOA but not vice-versa. BPM and SOA though overlap are different concepts - BPM can apply to a process that has no IT involved at all and SOA can still be applied to a web service with no "well recognised" business processes. The two technologies appear to be redundant - au contraire they supplement each other. SOA greatly simplifies the BPM implementation, and BPM helps in such ways as during SOA org transformation that has many stakeholders. For example business processes drive the requirements and capabilities?

Also, on a different note, Web 2.0 too is usually related to SOA and to BPM. The target crowd of BPM is "Business and mission", of SOA is the (IT) architects and of Web 2.0 is the end users. Personally, I see BPM and SOA as separate entities with some overlap.

Hi,

My view is that BPM is all about defining and perhaps automating the processes that revolve around predictable and repetitive transactional tasks. 

SOA is quite different. We are dealing with rather different arts - those of project management and change management. 

In the BPM model, the processes are at the heart of everything that happens. Information is used to support these processes.

The SOA model requires a rather different approach. In this scenario, the processes are determined by the information that is available. Everything is driven by information. There may be broad processes that are defined - such as creating and executing a project plan or searching for a solution to a problem. What you actually do is determined by the data rather than any pre-defined processes.