SOA has more traction these days than BPM does. SOA tools are more mature, but they are also wildly technical. If you want to model a process in an EAI or ESB tool, don’t expect to share that model with the business. BPMN is a visual language invented by people who like flowcharts.
Clue #1: the business hates flow charts.
There is value in connecting BPM to SOA, but it is entirely possible to do one without the other. BPM can be performed for reasons that have nothing to do with IT automation. You can focus on improving the processes in the assembly of a manufactured product, or make the manual steps in a paper-based order processing system efficient. However, to truly unleash the power of BPM, you need to get past the biggest hurdle to it’s effectiveness: the expensive IT project.
Many Business Process Re-engineering efforts die on the vine because the first step is to create a model for a new business process, and the second step is to change the IT applications that support the existing process. Step 2 becomes expensive and time consuming. The business looks at the return on investment for fixing the process, and the annual cost of making the change to IT, and is unlikely to see any real value in making the change at all.
Connecting BPM to SOA makes BPM work. We can deliver a process change FAR less expensively if it means creating a new composite than if a process change was to drive an altogether new IT system. SOA without the justification of business change is a chaotic and expensive animal that should be killed. In many companies, it has been killed as an expensive waste of time.
The only value we can get out of SOA, in the long run, is if we make the business more agile by removing the obstacle of expensive IT development. We don’t need pure SOA. We need BPM+SOA.
Unfortunately, most EAI-based tools are written the other way around. We (tool vendors) expect our customers to build the services first, and then attach them to business processes in a great big flow chart. Head’s up. Doesn’t really work that way. In that model, the process diagram is the last thing you build. It needs to be first. Without the diagram first, you can “describe” the conceptual services you need, and even build the base infrastructure, but you cannot build the enterprise services without starting from the business process and working toward the service. Seamlessly.
In this paradigm, BPMN is a problem. EAI tools support BPMN as a flow chart (see clue #1 above).
If we will see the BPM+SOA concept take off, it won’t be because we decided to teach a million businessmen to read BPMN flow chart diagrams. BPM+SOA will take off when we learn to develop SOA models from the business process diagramming standard that business already uses: the swimlane diagram.
Let me repeat for clarity: we should attach SOA to the Swimlane Diagram, not business process to the BPMN flowchart.
There are already tools on the market that take this approach and many more are appearing. This is the direction that many software vendors, including my own, have been slow to understand.
Cracking this nut will require that we start where the business is, enable a higher level of immediate quality and consumability where the business is, and THEN tie in IT where the services are. Starting where the business is requires a new tool. Building the services will use the existing tools. We are half way there…
… but only half way there.
—-
Update for clarity: Yes, I know that BPMN allows you to model a swim-lane diagram. Swimlanes are a problem in the EAI space, however, because we didn’t put people into the process from the start. In many tools that started from the EAI space, the swimlane is the afterthought and human collaboration semantics are not well managed. This includes things like worklist, notification, team assignment, handoff, ad-hoc routing, and other elements that are typical of workflow tools that do not show up in EAI tools.
PingBack from http://www.userinexperience.com/2007/08/06/links-for-2007-08-06/
PingBack from http://www.userinexperience.com/2007/08/06/links-for-2007-08-06/
PingBack from http://www.userinexperience.com/2007/08/06/links-for-2007-08-06/
Great blog. Something didn’t seem right when I read the statement "develop SOA models from the business process diagramming standard that business already uses: the swimlane diagram." so I thought I’d ask for clarification…are you suggesting in the statement that SOA should be derived from business process swimlanes?
The reason I’m asking is because I’ve witnessed architects urging business leads to define their busines processes using a BPM tools which the architects then essentially compile the process definitions, which included swimlanes models, into web services. This approach produced a bunch of redundant, siloed software services that didn’t deliver the benefits of SOA; system flexibility, data quality, reusability and ultimately reduced agility to the business.
The approach lacked steps such as commonality variability analysis, data modeling and basic object-oriented techniques to design the software service to automate the business proces but not be coupled to the business process definition itself.
I don’t think that you are suggesting that BPMN-to-SOA is the right approach but I thought I’d ask just in case becuase it wasn’t clear to me in the blog.
@Gabriel,
Great question!
In a capitalistic market, which comes first: the product or the customer?
It is a valid question. We say things like "customer first" but we all know that the moment we provide a product to the customer, it is wrong and needs to be fixed. In software development, we do lots of things like to avoid this, including many of the aspects of agile development that allow for tight feedback cycles.
At the end of the day, the "right" service is defined by the customer. If it meets their needs and is well designed, it is right… for one application.
You correctly point something out: that doesn’t make it right for the enterprise.
So, how do you perform anything like "agile" development if one of your customers… if your most important customer… is literally "everyone"?
Answer: you have people on the ‘customer team’ that are guided by principles that all accept as ‘enterprise focused’ and all of the requirements are vetted through this person. He or she affects little or none of the user interface, but really ends up driving most of the service interface requirements.
But the rest of the users are in the business process. When you define the business process, using BPMN (or the up-and-coming BPMN 2.0 notation that will have a direct XML representation), you are defining the USER INTERFACE requirements.
Another layer of design altogether happens under that layer. The composition layer. That is where we discover if our services really are reusable.
The point I’m trying to make is that the success of SOA will hinge entirely on how easy it is to bind the services to the process. That ‘ease of use’ requirement is impossible to completely capture until you are present, in the moment, composing the application.
That is where you will discover if you can do the right thing.
So, to seperate practice from people, I’d say we need the practice of developing high level process flows, and tying mock services to them in a composition process. Those services act as ‘soft requirements’ for the real services. They are completely wrong (just like wireframe diagrams are completely wrong) but extraordinarily useful to the developers building the services…
The folks building the services are incented (hopefully) to care about the enterprise. The line of business manager who told you his workflow… he is not incented, and likely not qualified, to think about designing the actual enterprise services.
Customer ->
Product idea ->
Product design ->
Customer ->
improved product …
Does that clarify what I am attempting to say?
— N
Yes. Thanks Nick. I just want to clarify that we need strong architects that have solid system design skills that can automate business processes defined by the business. This isn’t different.
The thing that’s different to me in your blog that you underscore is that the business can use BPM tools with the latest innovations and leverage swimlane process design to assert presentation-layer software services designed specifically for the nuances of human-to-system workflow and not assume the nuances of system-to-system workflow/orchestration. GREAT POINT.
Regardless, leave the actual software service design decisions to qualified Solution Architects.
@Gabriel,
I completely agree. The design of the actual software services cannot be done without qualified Solution Architects.
Probably in multiple iterations…
Hopefully with competition…
Someday, off the shelf…
— Nick