While SOA was the big name in the buzzword tag cloud, BPM is quickly getting bigger and bigger. As organizations are becoming more aware of the need to tame their processes in order to get the benefits of IT investments, BPM is gaining importance and mindshare inside and outside of IT. Is one more important for your architecture? From BPM as an SOA platform to using BPM as a rationale to pursue SOA, the link between these two concepts has been growing tighter.

We can't talk about IT integrating ERP systems without also considering how that integration will play with the business analysts or LOB who actually need that data or services for their business processes. These two often contradictory elements need to work together as part of a fully integrated solution. When SOA and BPM play well together we have seen enormous benefits. Not only is there alignment between the various roles in IT and the LOB, but the processes are implemented in an optimized way that both camps can successfully manage...

Once a business process model is implemented and automated across the SOA Integration, optimization occurs when runtime feedback is returned to the business analyst via integrated business-activity monitoring. This lets business users see where process improvement needs to occur in real time. Once improvements are identified, the business analyst can update both the models and the business and the development cycle begin anew. True business transformation and optimization are realized through this iterative business-integration cycle.

To see these types of benefits SOA and BPM needs to be integrated in such a way as to give multiple users in the organization common unified tools to share metadata, share governance and management information, and ultimately optimize the interoperability between a business processes and how those processes are translated to the back-end integration.

Quinton Wall, also of BEA, recently spoke about combining BPM with an SOA to maximize business agility. Wall stated that organizations could achieve IT and business alignment by leveraging BPM tools with an SOA: "The trick is to enable the business side to make changes in a governed manner while reducing its reliance on IT." That is, the BPM tools allow the line of business actors to take advantage of services and service composition with less IT involvement.

The BEA advice came from an "SOA-first" perspective that assumed the organization is already service-enabled. Several others took a business process centered view of the marriage between BPM and SOA.

"I start breaking that down into all the processes," Cripps explained, "what we found was that, in an SOA engagement of this magnitude, we spent 55 percent of our time defining the processes. Fifty-five percent, I found that pretty amazing. Twenty percent of our time was in coding. The remaining 25 percent was in testing and implementation."

This is good news for small and medium sized businesses contemplating SOA, Cripps said. Business process identification and modeling can be done within the core team that includes the departmental stakeholders, but the 20 percent of the project that is coding can be outsourced.

In-house, the SOA team members have changed their way of thinking about applications in terms of business processes, Cripps said. "When we went with service orientation, as far as my team members were concerned, it really elevated their knowledge because it took a significant effort to understand the business processes and the business rules through multiple departments that would be involved in a particular transaction," he said.

Seeley also pointed out how the role of business analysts has been changed by the movement toward SOA. Quoting John Michelsen, iTKO, Inc. Chief Scientist, Seeley noted that it is the business analyst's responsibility for requirements as opposed to IT's responsibility to develop the components that is most effected by SOA initiatives.

"I think it might be fair to say that the individual developer writing code is the least affected because he or she is taking requirements and building a component, testing components, and plugging it into a larger system," he said. "That in itself is not that different than it was five years ago. So, ironically, the developer may be the least impacted by SOA."

In both of these cases, Seeley brought out the importance of business process management and analysis in dealing with creating and dealing with SOA.

Dennis Byron noted that BPM now deserves a first-class slot in the software stack. 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. With this business perspective of the software stack, IT can "look at BPM as a 'new development paradigm,' grounded in service-oriented architecture (SOA) methodologies."

In getting to the answer of the question "BPM or SOA?", Neil Macehiter and Neil Ward-Dutton talked about how the two concepts work in a modern organization. Instead of taking the traditional approach of "BPM is a top-down, business-driven initiative, whereas SOA is a bottom-up, technology-driven initiative", Macehiter and Ward-Dutton talked about how "top-down *and* bottom-up perspectives of service-orientation *and* process-orientation can all come together in a more holistic view of business and technology architecture." Following up on these statements Macehiter and Ward-Dutton showed how the process and service concepts unite through outcomes:

Outcomes are desired results. An outcome at the highest level is likely to be something concerned with the core value of the organisation, financial performance, etc. At this level, outcomes might link very straightforwardly to mission statements. At lower levels outcomes are going to be concerned with operational results - for example "product is delivered". Services are commitments to achieve outcomes. Processes are the methods through which outcomes are achieved.

Neil and Neil summed up the BPM/SOA perspective with this: "the truth is that *outcomes* come first, and services and processes are two sides of the same coin in achieving the right results."

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.

(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.

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.

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 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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.