We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Do You Think BPM and SOA Are Going to Merge? If So, How Soon?

Vote 0 Votes
This comes from a Joe McKendrick blog: "There has always been a huge cultural divide between the business folks, who felt that they own BPM, versus the IT folks, who own the architecture or the technology architecture, which would be SOA."  So do you think BPM and SOA are going to merge, and if so, how soon?

13 Replies

| Add a Reply
  • In short, my answer is YES. However, this will happen (in a matter of next 3-5 years) in the form that IT does not anticipate (this is my guess).

    SOA is getting out of IT into Business right in front of us, these days. This will take a couple of years. Currently, Business understand their processes (not BPML or BPM as IT sees it) in the form of Value Chains. The strong movement in Business, however, is toward Value Networks that, according to Steve Jones, is the conceptual twin to business SOA (vs. technical SOA). When fans of Value Networks take over the old school of Value Chains, the time for saying Business SOA comes.

  • This question further exemplifies the misunderstanding over what BPM and SOA are. BPM is a practice focused optimizing your business processes based on your business mission. In this way, you might optimize around cost, speed, etc. SOA is about rationalization of the application portfolio through service-orientation as a metaphor that incorporates services, composites and orchestration. These efforts are distinct and focused on very different aspects of the business and should never be considered as things that could merge. Moreover, I believe there is further confusion that a service is a process, which is one root cause for misunderstanding. A service, in it's purest sense, is business function, not a business process.

  • I think this merge is already in process, especially when you look within US government and to our peers in Europe, who are approaching "BPMSOA" in a more pragmatic way than some technology-driven IT shops are in North America. I would say within the next 2 years you will see a majority of BPM/SOA implementations with blurred lines at most enterprise IT shops.

    BPM is a natural entry point for SOA, and since SOA should be driven by business needs, you will only see this become more prevalent. BPM gets business to think about their processes in more digestible, "service-oriented" componentized terms, and that makes SOA the natural architectural model to get there. You will also see that the most successful SOA implementations in terms of delivered value are tied to BPM, and so this merge will be budgeted.

  • Not only will they, but this is already happening. Part of the value of SoaML is that it links to the business process as activity diagrams and BPMN-2 is incorporating SOA concepts.

    Both BPM and SOA have a business and technology aspect and these, likewise, are complementary. Enterprise SOA looks at the responsibilities and requirements of entities in the context of the supply chain (or value chain). Enterprise processes looks at the activities the organization uses to meet its responsibilities (some of which are services). Processes use services and services use processes, both use information.

    We need to stop looking at these valuable architectural viewpoints as stovepipes and recognize that process, services, information, resources, rights and rules are all viewpoints of the same enterprise and/or the same system. These viewpoints only reach their full potential when integrated into a coherent enterprise architecture.

  • Yes, the merger is in progress. You will see BPM products offering more than just forms design and development capabilities. If you recall, the objective of BPM suites not long ago was to replicate the paper experience. BPM products are good at transforming paper-based forms into electronic forms. Now organizations want to move not just their paper-intensive approval processes to the web but also their entire desktop applications. These apps are often laden with sophisticated process rules. By combining BPM with SOA-development tools organizations will be able to build WEB 2.0, Rich Internet Applications (RIA's) that extend sophisticated, multitransactional processes right to the Web. Cool stuff right around the corner.

  • I agree with JP that BPM and SOA are two different things. However, I think one of the biggest reasons for SOA failures is the lack of focus on business driven initiatives in favor of technology driven initiatives. I have been saying for a few years now that without BPM, your SOA is SOL! In other words, without improving business processes and showing the business real value, SOA will be just a another IT thing that nobody outside of IT cares about and supports.

  • I agree with JP & Mike. BPM helps you to understand business process better than ever before, on the other hand SOA is more about making sure business process achive the results using IT services based on SOA methodology. In the near future more enterprises will combine BPM and SOA development efforts together. This won't be a merger it will be like strategic partnership to be successful.

  • I believe that BPM and SOA are distinct and should remain so; however, where unification needs to occur is from the perspective of methodology and governance. Both BPM and SOA have their own collections of standards, specifications, principles, patterns and practices. They co-exist as two sides of the same coin – BPM is the 'business-oriented' side and SOA is the 'technology-oriented'. We (industry) have succeeded, once again, in exacerbating the divide between business and IT by not focusing on the coin itself; instead becoming enamored with its individual faces. The question in my mind is what do we call the coin? Umbrella terms like Service-Oriented Computing or Business Execution Framework might serve this purpose. The point is that we need a means to view a business as a holistic entity, neither BPM nor SOA provide a complete or independent viewpoint or solution. The appropriate question is when are practitioners going to broadly recognize that BPM and SOA are inextricably linked and both contribute to the classic problem of how IT can enable and facilitate business success. Incidentally, I think that a dose of EDA needs to be added to the BPM and SOA mix – as this provides the pathway toward more agile business execution.

  • user-pic

    I'm with JP on this

    Asking is BPM going to merge with SOA is like asking "are cars going to merge with engines" - BPM is about linking business processes and events with desired business outcomes - SOA is an approach that you might use to build a BPM solution (So BPM is the car SOA is the engine).

  • The value of SOA is seen when a series of services can be assembled or orchestrated to map to an existing business process, or create a new business process. However, this requires BPM proficiency, versus SOA skills. Those involved in building, specifying, and maintaining SOA-enabled services need to work collaboratively with BPM teams to make this happen.

  • I agree with a number of other commenters: this question underscores a fundamental lack of understanding about BPM and SOA.

    BPM is a discipline for supporting process improvements. Business Process Management Suites (BPMS’s) are tools for supporting BPM efforts. SOA is an architecture style that supports services.

    BPMS’s may or may not have a foundation of SOA, depending on the focus of the problems that are being addressed. If the focus is on processes that involve interactions between people, applications, back-end systems and business partners, then SOA is always present since the BPMS’s that support this type of activity have embedded SOA features baked in.

    That may not be the case for BPMS’s that are designed to support processes that involve mostly human activity. While these tools are able to provide limited support for SOA (in the form of creating and consuming services), they normally lack the more robust SOA features (an embedded ESB, registry and service repository).

    This situation will likely continue for some time. Bottom line, BPM and SOA may coexist…it all depends.

  • I think everyone seems to agree that there's a strong connection between the two, and the consensus seems to be that something very significant is happening. I can see where JP is coming from with respect to the separation of concerns and the potential hazards of looking at them as merged.

    I propose that a good way of looking at it may be that BPM and SOA are getting married. Clearly when two people get married, they dont "merge" and that there is a danger in thinking of them as one person. In order for the marriage to be successful each person needs to be even more completely themselves than before.

    But given that this conversation was in part triggered by the "marriage" of Software AG to IDS Scheer, I would have to comment by saying that this is a love marriage, not just a marriage of convenience. SOA may need BPM's funding in order to get the program kickstarted--but without a reusable set of components, achieving agility and continuous improvement in BPM is not attainable.

    To say that BPM is about "business" and SOA is about "technology" is missing the point in a major way. Both of course are approaches rather than products as we have all said many times. But there's cost cutting involved in both BPM through business process optimization and SOA through IT process optimization, and there's revenue opportunities for both as well. They are both about the business and both can benefit from well applied technology.

    If BPM and SOA got married, we might go so far as to say that they "adopted" MDM along the way.

    My 2 cents,

  • A merge is not necessary a union or equals (even marriage is not some times).

    Different things like "service, in it's purest sense, is business function" and a business process can be merged via a notion of realisation. That is, a business function (JP,I hope you agree that it is not the same thing as an "application portfolio" unless it is a portfolio of business applications) may be realised as a business process, which, in turn, organises other business functions into the ordered execution. There is not difference between a process and a service orchestration, both of them may be business categories as well as technical.

    Who, finally, includes whom may be found if we look at the top of the business structure: at the C-level there are services that are articulates as a Value Networks, i.e. the characteristics of the enterprise that distinguish it from the others in the market and explain how the enterprise 'makes money'. The business processes the enterprise uses to reach its goal is just a particular implementation of its top functional services, and this implementation may be changed at any moment (via BPM) without changing the top functional services.

Add a Reply

Recently Commented On

Monthly Archives