I fully agree with you.

My judgement is there is indeed a real value in the combination of BPM and SOA, which could solve every organisation’s problem: the business-IT alignment. However, the BPM/SOA convergence is only a vision, rather than an existing solution.

My experience shows that value must be presented to the business professionals. At the end of the day, they and “only they” have power in every organisations. Business folks must aks IT guys, before investing in any IT project: “show me the value”, “show me the money”. In the meantime, using BPM approaches, business managers understand the creation of value (feel added value) by modeling, designing, and reorganizing the processes as a result of market, legal, or customer requirements. However, they do not see value in the new IT buzzword: SOA. As you said, SOA is marketed as a philosophy, it is about agility, architecting, but “Architecting is not Building”.

Conclusion, before moving forward, both camps must seat together and find the interdisciplinary underlying concepts: The process? The service? Business managers must understand how and where processes meet SOA services, and how the orchestration of services will help in the development of applications, and foremost how additional value could be generated.

-Tomasz

Thanks for the feedback, much appreciated.

-Ismael

We just went through a battle of selection of tools in our large COE. It was very clear from this that it was a lot easier to select tools from a BPM point of view, compared to SOA. In fact, as we started selecting a SOA registry, it quickly became a battle between SOA registry and repository. Quickly, we found that some SOA repositories even came from the Assent Management world. My point is that the requirements and tools in this area are still very immature, even at the lowest level of the SOA brick. I don’t even want to bring out non-interoperable messaging standards. Though we fully understand the value of point to point and EDA very well, as we have a large successful EAI infrastructure deployed.

On the other hand, selecting BPM was a lot easier as business quickly knew what is required. Though many vendors have significantly different capabilities, some leading ones came from the BPMN world, and they have done a great job of integrating services (non-standard way), presentation layer, etc. However, their integration is perhaps not as open as Intalio.

After having seen various generations of BAM, I can’t help asking Edwin Khodabakchian why he considers BAM has an important third pattern — I assume he means it in the context of plain vanilla SOA. It makes more sense to consider BAM has having more value when you tie around BPM &s; BRM, compared to a SOA centric process orchestration stack, such as BPEL or EAI based processes. What do others think?

Thank you for these comments. Very insightful.

Good to meet you again by the way!

This is an excellent article that reminds me a lot of the discussions we had together a few years ago. There are too many parts in your article that are so well written that it is impossible to quote them.

If you allow me, I would only want to add few little thoughts.

1. BPM does not only make sense for business people. I like to think of a project in the same way as an “entrepeneur” that establishes a company and whose goal is to realize that project. When creating a company, you need to choose the right people, with the right skills. Not too many, not too few. People that cleverly execute a part of the project. And who need to be located in the right place — you will never hire a cook and place him far from the kitchen, right? The project — any project for that matter — is nothing more than coordinating the different specialists you hired in the location you gave them.

After all, an IT project needs to model something that actually exists, right?

2. In Business terms, each thing you do is a process. A company is organized through processes! Many times, though, companies execute processes that are not formalized. Formalizing them is one of the benefits that automation can bring. With, our without SOA, with or without BPM. But with BPM, we gain the possibility of implementing something that is closer to the reality.

3. Granularity is often a matter of power. What I mean is that the more fine-grained you think about your services, the more power you intrinsically give to the coordinator. And the more coarse-grained your services are, the more there are islands of power that you do not want (or cannot) break. What I want to say is that if you think of a project as a way to map an existing business process in a existing company (or a new one), you cannot abstract away from the actual organization.

4. Sometimes, instead of defining a formal processes where each service in the organization is clearly coordinated, it is easier to give each service the possibility to contribute… In that case, the important thing is to avoid having someone who has the coordination responsibility, and to give more responsibility to the periphery.

I have written before about the need for a software suite for SOA such as those offered by IBM, TIBCO and BEA. I have also written about the need to actually improve business process with SOA through the use of BPM to achieve benefits and ROI.

I could not agree more. Thanks for the nice article!

It’s the business audience focus that I appreciated. A lot of technical folks I speak with sing the praises of SOA in various forms, but if this is going to be something deployed cross-enterprise at larger organizations, it HAS to resonate with the non-technical people (aka, those who write the checks), and BPM goes a long way in spanning that chasm.

Best,

-Jason

I totally agree with you. BPM is only one application for SOA, but it’s the one that will help make SOA more palatable to a business audience, and as such, I consider it as SOA’s killer application.

I liked the way you described the realtionship between BPM and SOA the first time and now even more. Especially this: “deploying SOA in the context of a BPM process will help you package services with the appropriate level of granularity.”

I also liked “the whiteboard situation” you mentioned. A business is full of services exposed internally and externally between organisational units. Putting them into the context of processes will give you BPM on SOA. Like that!

-Jonas