Not to beat the dead horse, but during a discussion the other day with a fellow SOA cohort, I came to a realization for the reason SOA & BPM get inextricably tied together in some individual’s thoughts. I’ve written and blogged before on how SOA & BPM have very different goals. SOA is about application rationalization via a service metaphor and BPM is about business process analysis and optimization. The fact that they are discussed in the same breath leads one to believe that they are inherently related, when in fact they are not.
That said, as one performs a top-down analysis of their business as part of a BPM initiative, they are going to discover they need a framework to assist in implementing new business processes that cut across departmental and other organizational boundaries. Clearly, one of the greatest areas for improvement within in an organization is across these organizational boundaries because process improvement tended to be an intra-departmental exercise. When the process needed to cross an organizational boundary, the political, geographic, technological, etc. hurdles led to inefficient crossings.
Historically, SOA and BPM rose in popularity at or around the same time. SOA, led primarily by technological practitioners, responded to the needs of BPM practitioners for a framework to capture and implement newly-designed and efficient cross-organizational business processes with technology. However, for BPM, technology is the least of the problems. Indeed, BPM’s biggest issues are political and geographic in nature. A process that needs to cross continents or rely on participation of a department that is resistant to change pose a far greater problem to process optimization than not having a web service available to invoke.
Still, there is seems to be a natural gravitation toward SOA as providing the necessary framework to capture and implement new cross-organizational business processes. Most likely it is the service façade that allows various business functions to be exposed as technological assets accessible over common Internet protocols. After all, what better way to create a business process that crosses organizational boundaries than tapping directly into the data and systems that support those sub-organizational areas?
However, it’s important to note that SOA should not be viewed as the nail for BPM’s hammer, as is all too popular a notion today. It is not an SOA if you decided to wrap a few legacy systems with web services so that you could easily build out an automated business process. That is just part of your BPMS effort.
This entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes. If as part of the rationalization that SOA provides, there happens to be some services exposed that simplify the implementation of a particular business process, then that would certainly be a slam-dunk. However, SOA and BPM each have their own metrics of success and their own barriers to success. Combining them into one, well, the words “boiling the ocean” comes to mind.
Combining SOA and BPM initiatives into a single program is not necessary – or even possible in many cases. They are driven by different players with varying goals as you pointed out.
However, ‘alignment’ of SOA and BPM initiatives results in considerable benefits to both. Improving process ‘automation’ is a key component of many, if not all, BPM initiatives. In most large organizations, IT’s slow responsiveness is one of the key bottlenecks to automation and changes to automation.
This is where SOA comes in. An aligned portfolio and roadmap of SOA services can make process automation and subsequent changes faster and easier.
A valuable by product of an SOA approach to process automation is that services become standardized ‘viewports’ into what is happening at different stages of a process – perfect for analyzing how a process is performing at different stages and where to make further improvements.
I must agree that BPM and SOA are two very powerful tools that arose in the same timeframe. HOWEVER, I must disagree that they shouldn’t be more closely tied. BPM, as you describe is really understanding and optimizing the business process. This is important and very productive work that most companies seem to put off. By doing appropriate BPM then an organization can better optimize their processes across business units and ensure there is little or no redundancy in the implementation.
SOA is the implementation of the business process into applications and infrastructure. BUT SOA, done right really addresses the business level. SOA implies that the IT should be done to mirror and map the business processes and not as a separate activity. I think this is where many companies have problems.
Historically (back in IT’s stone age) computers were limited on what they could do so applications were done to implement something ‘as well as it could’, meaning lots of compromises. What grew up is that the applications often defined the business processes, because there wasn’t much choice otherwise.
But with modern development languages and techniques, and with tools specifically tied to processes, it’s possible to referse this and have the business process drive the implementation. Enter SOA.
A ‘service’ is not a piece of technology sitting on a server waiting to be called. Think of it as a part of a business process that was identified as having value as a stand along ‘business service’. Implement it and suddently the applications are starting to (just starting to) look like the business process. Yes you need infrastructure, and yes you need utility services, but the meat and potatoes for SOA is the business services. That’s where the real pay back comes from and that’s where the application focus on Business Process comes from.
So yes BPM must be done first, in my experience it works best when the senior IT guys also participate in this work. Then starting with the new business process you put together your Services Oriented Architecture and ultimately this drives implementation. Certainly they are not done together, but there is a direct and vital connection between the two that is reauired to achieve the real business value that both BPM and SOA promise.
Geoffrey,
We’ll have to agree to disagree, but I disagree with your notion of SOA “SOA is the implementation of the business process into applications and infrastructure”. SOA is about business function, not about business process. I believe many others also believe as you do that a service equates to a business process, but that is not the appropriate boundary for a service. If that is your demarcation, then your services will continually be in flux, rather than your services being stable and your business processes agile.
JP
JP,
An excellent article!
I do believe that BPM and SOA initiatives while distinct have sufficient “touch points” that communication and colloboration between the two is critical in the majority of cases.
Good point re (relatively) fixed Services being composed quickly to support flexible and agile Business Processes. So, you should be able to create or refine a business process first and then find appropriate services to support it – either internally or from third parties. Maintaining and managing a library of Services is distinct from managing a set of Business Processes, but the two efforts need to talk back and forth to minimize wasted effort and time to market.
Gagan,
BINGO!
We find that BPM projects without SOA lead to inflexibility, unnecessary costs, and failed projects, while SOA projects without BPM tend to be excessively bottom-up, and hence lead to Services that don’t align with business needs. So while the core BPM and SOA teams have different focuses, they should be part of the same overall architecturally-driven initiative.
We often find the confusion on this point is due to a misunderstanding that SOA is a technical effort, rather than a business transformation effort. Such misunderstandings lead to the “SOA straw man” that gave rise to the “SOA is dead” meme. In other words, we don’t have the time or money for fake-SOA that doesn’t support and incorporate BPM efforts.
Jason,
I have seen many BPM projects succeed without any reference or concept of SOA. In fact, the introduction of SOA has led these initiatives astray due to the reason you noted here; the lack of understanding that SOA is a business effort. To clarify, I’ve never stated that I didn’t believe that BPM could benefit from a well-done SOA, in fact, I specifically called that out as a “slam-dunk” in the blog entry. What I stated is that these initiatives need to be entered into and perceived by the organization as distinct and different efforts that are not reliant on each other in order to be considered successful.
[…] the SOA-BPM alliance is a great thing, right? Actually, at least one informed observer questions whether SOA and BPM were really meant to be together at all. JP Morgenthal cautions that “SOA […]
Perhaps it is the vendors that cause both initiatives to start up at once as they like to sell as much enabling software as they can in one “sale”.
How exactly would a BPM initiative succeed without an effective automation framework?
Maybe you could put massive organisational change management around it to embed the new processes. But you’re pushing water up hill if those processes aren’t automated to offer a course of least resistance to all stakeholders in the business.
So if SOA isn’t the automation framework required for automating BPM, what are the alternatives? (silence deafens)
As to the touch points between those programs: if the SOA people don’t see the BPM people as the number one customer for the SOA what are they building it for?
Tony,
Process optimization can come through many channels, automation being one of them. Changes in communication techniques, organization hierarchy and simple process task ordering can all lead to significant upsides without even engaging IT. SOA proponents need to realize once and for all that technology is least limiting factor to organizational change; in essence, it’s the easy stuff. Like anything technology is a means to an end, not the end itself; it’s no different for SOA. The end result of BPM is process improvement, regardless of how it is achieved.
With regard to your 2nd point about SOA people seeing BPM as their number one customer, I don’t necessarily agree with that point either. The business is SOA’s #1 customer. Some SOA efforts may support a BPM initiative, but it also might just support business partner integration or portfolio rationalization, which results in lower TCO. While the two can share some common goals, venn diagram wise, each stands alone with a small percentage of overlap.
This makes me think of SOA as almost been an SDLC within the Development Lifecycle. Focusing on providing an architecture that delivers the roadway for streamlining your business processes while ensuring the service that should be there to make it easier for customers to make their payments is highly available; robust and reliable.
I believe your statement of:
A process that needs to cross continents or rely on participation of a department that is resistant to change pose a far greater problem to process optimization than not having a web service available to invoke.
Is correct! It is related to process optimization and not process standardization. Having a service available to allow multiple-departments to enhance and optimize their business and operational processes will help ensure departmental heads get on-board. But, this is where some SOA experts claim to have the answers that align with the value of SOA. I believe you hit the nail on the head but stating the two; BPM & SOA are separate. Early statements I made on the IBM and Texas Instruments conference calls back in January of ’07 stated that SOA is a compliment to the business strategy with modular best practice made into standards to fit into demanding business needs. However; I have seen SOA fail in organizations where BPM was done correctly and adopted by its leaders but SOA lacked governance from the top-down.
A question I have; is how has your organization overcome this major obstacle to successfully implement SOA?
Great discussion!
Thank you.
Gonzarelli, I believe you answered your own question; when business leadership gets behind something its chances of success increase exponentially. A major problem with SOA these days is that management says they want it, but they don’t really understand enough about it to really commit the resources necessary to achieve a successful SOA initiative. Hence, it ends up being one of those efforts that someone has responsibility for without the corresponding authority. I believe this is more a cause for SOA failure than the complexity of SOA itself. I’m about to publish a new blog entry soon discussing that SOA may be more of a concept than an approach.
[…] Nevertheless, there is still confusion on this point, among enterprise practitioners who see BPM as a business effort and SOA as technology-centric, among vendors who see them as separate products in separate markets, and even among pundits who see Services as supporting business functions but not business processes. […]
[…] JP Morganthal makes an important post reminding us to Keep Your SOA and BPM Initiatives Separate. Read through the comments and you will see precisely why there is a problem in the community. I have met so many people that think that BPM is just a scripting language for SOA services. These people will argue at length that “BPM is a part of SOA because SOA is useful without BPM, while BPM is useless without SOA” (this is an actual quote from a noted BPM expert who shall remain nameless for this post). JP makes the point very well, but let me put my spin on it: […]
[…] he also references a good article by JP Morganthal which sounds controversial – keeping your SOA and BPM initiatives separate, but which […]
A business process task (BP) and a business service interface (BSI) are certainly two different things. We want to automate business processes where we can. The question really is about: How do we package the automation?
In reading the article and the comments, I see potential sources of confusion.
1. There are different kinds of services in a SOA context.
2. Where do you put the work-flow?
3. A stable business process model identifies “what is produced” while avoiding the details about “how it is produced”. The “what” is very stable over time while the “how” changes as we improve and automate processes.
Different kinds of services:
. Business Service – is the automated proxy (order entry) to a real-life process.
. Technical Service – example: Authentication, Authorization, used in many contexts.
. Data Service – access to data reflecting the corporate short-term and long-term memory.
Where do you put the work-flow?
– We tend to put it into the message flow (e.g. BPEL or in the queues). But this is not a very good representation (model) of the Business Process. We need something better.
– The “what” of a business process is the content of a Business Service API.
– The “how” may have two parts: internal and external work-flows.
– The external work-flow should be modeled in an appropriate tool. The work-flow and the SOA are related in that the SOA supports the work-flow.
– When the service has its own internal work-flow, the “how” should be in an internal work-flow tool and hidden from the client. The client should not need or want to micro-manage the process. They have delegated the task.
Finally, the confusion between SOA and BPM is often due to the sales approach. The sales team gets management attention by first talking about BPM. Then they imply that the BPM is mapped to the SOA. People who have not actually built these kinds of business automations have a naive view about the real nature of the mapping.