Should your architecture focus on SOA or BPM?

The way I see it, BPM is something that an organization embraces in order to execute its everyday business tasks, involving both people and computer systems. Every organization has business processes, of course. However, an organization has to make an explicit business decision in order to make those business processes more formal (perhaps through paper forms) or more automated (perhaps through email & attached documents or a BPM software package).

I don't view that as an architecture decision.

On the flip side, if you're building out a software solution and you need the resources from different software systems (ie, not everything is contained within your JVM), that requirement might dictate an SOA architecture.

I wouldn't look at my architecture as BPM-focused unless BPM was part of my requirements for the software that I'm building. In other words, I would focus my architecture on BPM if and only if BPM was part of my requirements.

Cheers,
David

Flux - Java Job Scheduler. File Transfer. Workflow.

(sorry for the double posting -- trying to format correctly this time :)



The way I see it, BPM is something that an organization embraces in order to execute its everyday business tasks, involving both people and computer systems. Every organization has business processes, of course. However, an organization has to make an explicit business decision in order to make those business processes more formal (perhaps through paper forms) or more automated (perhaps through email & attached documents or a BPM software package).



I don't view that as an architecture decision.



On the flip side, if you're building out a software solution and you need the resources from different software systems (ie, not everything is contained within your JVM), that requirement might dictate an SOA architecture.



I wouldn't look at my architecture as BPM-focused unless BPM was part of my requirements for the software that I'm building. In other words, I would focus my architecture on BPM if and only if BPM was part of my requirements.



Cheers,
David



Flux - Java Job Scheduler. File Transfer. Workflow.

I guess it depends on what part of BPM you are talking about and using. Some BPM systems are more for tactical processes and very developer focused. (like JBPM)
Others have a snazzy gui and are able to be used by BAs (Business Analysts).

I think trying to lump the whole BPM world into a single definition and then pretend the current one is wrong is a bit silly. I assume the implication is that this is BPM from the SOA/enterprise-wide perspective only. But even assuming this...

First:
>Byron's point was that BPM has moved beyond being part of the integration layer, where the IT perspective put it, and onto the top of the stack.
Which implies that the "IT perspective put it" there because they were hiding it from business or some such? Mostly it was a good idea and many business teams are only good at generating paper and/or unwilling to change entrenched processes.


And then goes on to say:
>Seeley also pointed out how the role of business analysts has been changed by the movement toward SOA.

These are related. Some organisation simply don't have BA skillset to match this shift. therefore wont. Some don't want to.

In summary: Horses for courses.
I agree with your post that it is a business decision and not an architectural one in the context of this article. Not in the developer-centric context though. This is very much ONLY an architectural one.
But don't get me wrong! Overall though, I think this trend is very good one. You can write anything on a piece of paper. Formalising it in some sort of BPM-ready process would be a good exercise at many of the companies I have worked at, SOA or otherwise! :)
Thanks for the summary articles. Will be reading with great interest.

(Should have previewed also! Too used to other forums!)

I guess it depends on what part of BPM you are talking about and using. Some BPM systems are more for tactical processes and very developer focused. (like JBPM) Others have a snazzy gui and are able to be used by BAs (Business Analysts).

I think trying to lump the whole BPM world into a single definition and then pretend the current one is wrong is a bit silly. I assume the implication is that this is BPM from the SOA/enterprise-wide perspective only. But even assuming this...

First:
>Byron's point was that BPM has moved beyond being part of the integration layer, where the IT perspective put it, and onto the top of the stack. Which implies that the "IT perspective put it" there because they were hiding it from business or some such? Mostly it was a good idea and many business teams are only good at generating paper and/or unwilling to change entrenched processes.

And then goes on to say:

>Seeley also pointed out how the role of business analysts has been changed by the movement toward SOA. These are related. Some organisation simply don't have BA skillset to match this shift. therefore wont. Some don't want to.


In summary: Horses for courses.

I agree with your post that it is a business decision and not an architectural one in the context of this article. Not in the developer-centric context though. This is very much ONLY an architectural one. But don't get me wrong!


Overall though, I think this trend is very good one. You can write anything on a piece of paper. Formalising it in some sort of BPM-ready process would be a good exercise at many of the companies I have worked at, SOA or otherwise! :) Thanks for the summary articles. Will be reading with great interest.

One problem with BPM as it is currently done is that it is linked to process engines which take a step by step approach to what process is.


This isn't really what good BPR (Business Process Re-engineering) has done it has looked (as the Neil's say) at the structure and the goals of the organisation. The structure represents the boundaries and the goals (or outcomes) the capabilities that those structures must deliver.


What this means is that the reality is that SOA as a Business concept works very well at these high levels and then the choice is down to what is the right way to implement different areas of the business. This is doubly important now that organisations are moving away from static value chains and towards dynamic value networks, processes (in the BPM sense) really struggle in this context so the goal of Business SOA is to provide the framework within which choices can be made between services and outcomes that are best implemented using processes and those that are best implemented using other approaches (EDA, GDA, BDI,etc, etc)


The final part is that there is a myth that business process is the most important thing in business. For certain elements, especially back-office and manufacturing lines, it certainly is as these elements can be streamlines and automated but for large parts of the consumer facing and differentiating parts of a business its actually about more goal based solutions.


The challenge therefore is to have an approach (Business SOA) that enables a simple construct in which the various different approaches can work together.

I'd have to agree with the Neils too. I think that often SOA and BPM are discussed from a tooling perspective, and then the question as to on which to focus makes some kind of sense.



Once we look at it as architecture, it becomes clear that we need multiple views to arrive at a coherent and cohesive solution.



I've written this up in my blog post:



7 Simple Questions for Service Selection.

I view this article as possibly adding to the confusion around "BPM."

To simply answer the question in the title, architecture should focus on the BUSINESS; then BPM; and then SOA.

When some people hear BPM, they immediately think of a business process management system (BPMS), application, or technology.

BPM is Business Process Management -- not BPMS.

In itself, BPM (and any supporting technology) must be focused on the Business, and this critical point can not be taken lightly or assumed that people know it.

Clarification of the term/acronym, BPM, would help to position the article, and the role for architecture and SOA – clearly to support BPM.

In my 20+ years in IT and business consulting, many problems come from the fact that someone is looking to technology before they even know the business.

I think the title itself is quite misleading by implying that SOA and BPM are exclusive architectural concepts. To get full value from your Service inventory, you need process.



In fact, I would go so far as to say that Process Driven Architecture is catching on because experienced SOA practitioners are deploying smart, better design Services with greater isolation & reusability. In the recent past, many of Process Driven design's core advantages were lost due to the underlying components being far too coupled & overwrought to be orchestrated effectively.



Today, it's a lot easier to realize value because customers, tools, design & experience have contributed to mature Service backbones. In a nutshell, Process backbones energize Services and leverage an enterprise's inventory in the most intuitive manner possible.



A nice idea for an article in the future would be to evaluate a few customer implementations from a user/vendor/IT perspective and see some of the successes achieved with Developer-centric vs. Analyst-centric tools. I think the results would be interesting.



Cheers,



Zubin Wadia


CTO


www.imagework.com


"Business Acceleration through Process Automation."

Every business entity uses some form of BPM. SOA evolved from all of this. We cannot live without each other. Both should be considered and adjusted in architectural decisions.