Move with the flow

Don't mix models and realization?

2008-11-12T09:16:00.003+01:00

Active Endpoints has long experience from process execution environments. In this post, Michael Rowley gives his response to the BPEL vs. BPMN debate. Michael is questioning the relationship between models and its realization. He makes a note about the tiny little details you need to add to your model for making it executable saying - "... and they can’t be fuzzy or imprecise" about the ability to express them in BPMN.

Model-driven design is a hot topic, not just in the BPM space but in all software development domains. Business people have been invited to the round tables when discussing software design, thanks to the modeling approach. Certainly there will be initiatives taking the model too far, but in a couple of years there will probably be a balance between model and realization and we could hopefully work together with a seamless model-to-realization process ;).

Zip-top bags, monkeys, and BPM

2008-11-08T11:57:00.002+01:00

I attended and talked at a BPM conference last week, arranged by IDS Scheer in Stockholm. One of the keynote speakers was a guy talking about human behavior and how to step out of the box.

He talked about how we act in front of airport security, when asked to put liquid and gels in a plastic bag, even though we know that bag will not be safe when the bomb goes off. This story relates to all the brainless people and ass-kissers we are put up to cope with during the work hours.

The best story was the one about the monkeys and the bananas. It went like this ...

Start with a cage containing five monkeys.

Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with cold water.

After a while, another monkey makes an attempt with the same result - all the other monkeys are sprayed with cold water. Pretty soon, when another monkey tries to climb the stairs, the other monkeys will try to prevent it.

Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack him.

After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.

Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth. Every time the newest monkey takes to the stairs, he is attacked.

Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey.

After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that's the way it's always been done round here.

And that, my friends, is how company policies are made.

So how does the monkey story relate to BPM?

Don't beat up the guy trying to improve your business processes with the clear goal of rationalizing you and your collegues?

Platform Evolution and 'Dublin'

2008-10-11T10:19:00.006+01:00

Mapped a couple of vendors on to a general platform evolution time line. Process column refers to process execution capabilities, not BPM.

A few weeks ago Microsoft announced 'Dublin', a distributed host for WF/WCF based applications. 'Dublin' is an integrated environment within Windows Server, just like Internet Information Services, COM+, and Windows Sharepoint Services. BizTalk will now be positioned as Microsoft's answer to IBM's, Oracle's and BEA's integration suites. 'Dublin' takes a step up on the platform evolution and aligns to products like WebSphere Process Server, leveraging Workflow Foundation.

The only remaining question now would be - what will be the real product name?

BPM tries to appease process workers

2008-04-25T08:41:00.003+01:00

I recently watched a free BPM seminar with Forrester's Connie Moore where the result from an online survey was presented. The question was "What do you see as the primary benefit of BPM efforts?"

24% said Increased productivity for process workers
18% said The ability to provide real-time visibility into key processes
15% said The ability to change processes quickly and easily
13% said The ability to model business processes
12% said Consistent process execution across business units or geographics
12% said Optimization of processes
4% said Decreased reliance on IT for supporting and changing processes
1% said The ability to test work for compliance and remediate problems

I can agree that 2-8 are relevant to BPM, but increasing productivity for process workers I would say has nothing directly to do with BPM. There is an indirect link between BPM and productivity though. BPM should definitively be a driver for IT investments to increase productivity, like ECM, BI, Enterprise Search, Collaboration, Messaging, etc.

I think this result is just a way to appease the process workers who fear BPM. Name one capability of a BPMS that will increase the productivity directly of a process worker.

Prepare for multitenancy

2007-09-28T11:58:00.001+01:00

I quote from Wikipedia:

"Multitenancy refers to the architectural principle, where a single instance of the software runs on a software-as-a-service (SaaS) vendor's servers, serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration so that each client organization works with a customized virtual application instance."

A normal situation today would be a company cutting out a functional unit within in the organization to make it autonomous and reusable for new customers (Pict 1). This is the way companies do controlled out-sourcing. Another out-sourcing scenario would be to cut off the function and replace it with something total new on the market.

Picture 1: Cut-off-and-reuse scenario.

In the cut-off-and-reuse scenario the new company will most often be required to work with multiple customers. As wikipedia describes it, you can do it in several ways from a system perspective.

1) Hardware Virtualization (multiple OS-instances on the same hardware running the same application)
2) Application Virtualization (multiple application instances on the same OS running the same application)
3) Access Virtualization (multiple remote desktop users one the same OS/application instance)

These three alternatives are all shortcuts to be able to host multiple clients in the same system. The good side with this is all the operational support you get from infrastructure support like Microsoft Virtual Machine Manager and Citrix. But the bad thing is the lack of reusability and flexibility you get from these solutions.

Going from one client to multiple clients would most often result in a new architectural dimension. This new dimension will not just require more or extended database schemas, but also different UIs, different rules, processes and an open architecture where services can be composed, reused and differentiated for different customers. The fourth alternative calls for multitenancy.

4) Multitenancy (design for multiple users on the same application)

Q: How do you design a system to be prepared for multitenancy?

A: The book is not yet written, but the author who does will be rich and famous. I put my money on Full SOA Applications.

SOA is just an enabler

2007-09-18T18:51:00.000+01:00

Enablers are things that realize the potential of something else. That something use the enabler as a foundation for its own success. An enabler is by it self not worth too much.

Drivers are things that see the potential in other things. A driver can be something that makes use of that other thing, and makes it interesting.

When a driver and an enabler come into a direct relationship, you got a strong pair. Let's take XML and Web Service for example. XML is an enabler for Web Services and Web Services is the biggest driver for XML. XML and Web Services is a strong pair.

Another example is SOA. SOA without Web Services is not an option in this millennium and what would Web Services be without a good organized and managed SOA?

So why are we building an SOA? What drives an SOA? Lot's of things, but the most obvious one is Business Process Management (BPM). BPM is a good driver for SOA where services are used to build up end-to-end process implementations. One could argue if BPM has a value without enabled by a SOA, and I strongly agree. A BPM should be leveraging a SOA.

Building cross-functional process implementations is interesting for a couple reasons like, visibility, agility, etc. But the one with most business value is Performance Management (CPM). CPM will definitely be enabled by BPM since process implementations are fastest way to produce accurate performance values on demand.

ODE graduated from incubation

2007-09-05T20:44:00.000+01:00

I've only been following ODE from using Intalio but now I downloaded the bits to try it out. Together with Eclipse BPEL Editor you can build your orchestrations pretty easy. Not as a nice as ActiveBPEL and ActiveEndpoints's BPEL Designer. I will try out in more depth another time.

Read more here.

Let the bus go

2007-08-25T21:06:00.000+01:00

Any Enterprise Services Bus on the market is capable of doing application integration from native adapters. Some ESBs are built on a service bus topology and some on a hub and spoke. Some are modified EAI products with web services support. Almost everyone can manage routing, transformation, logging, and other mediation services. Some have integrated rules support, but should all those features be managed as one single unit as in this picture?

Let's separate things out into a better logical architecture. First, a EAI product mainly support publish and subscribe funtonallity, which is not part of a true SOA. Let the EAI product do what it's supposed to do (i.e. integrate applications natively) and expose required functions as web services.

Secondly, break out rules, process, and service registry and make them accessable through web services. Expose web services from the master data and use a common mediation layer in between all enterprise services and the consumer layer. This way you will virtualize any application (including your EAI product) and keep all physical services under one umbrella.

Using mediation will get rid of the service bus architecture, which really is a questionable topology. With mediation, agents will not be necessary because the physical service will need no management. The mediation controls all traffic and will be the place for manage versioning, enrichment, etc.

Can we become slaves under the BPMS

2007-07-13T13:15:00.000+01:00

At the beginning there were just common sense. Then we turned our common sense into experiences and after that routines and finally processes. People went from processes to process automation where the process were governed by IT-systems.

These systems were called BPMS which gave the impression of agility in terms of process changeability. They managed processes, measured the efficiency, simulated and improved the processes. Each new lap around the BPM cycle took away a part of the original common sense. We gave it a few laps more and then the processes were finally based on everything except common sense.

Could that be a real scenario with BPMS?

Process Orientation and Separation of Concerns

2007-07-11T22:21:00.000+01:00

Suppose you have the following sequence of a loan process:

After pre-qualification has been made and if the value is greater than $1000, send an approvement task to a loan approver using email.

When implementing this process sequence, a couple of questions pops up related to Separation of Concerns (SoC):

- What if the approvement rule changes to "if the value is greater than $1000 and age is less then 21"?
- What if email is not enough for notification mechanism and we want to add SMS messages?
- What if loan approvers need help from other roles?

Putting to much information details into a process implementation will not result in a good SoC. Process implementations should only be modified when the process changes, not when rules or services are. Instead of implementing all details directly into a process engine, try to split your process sequence like this:

The When - "After pre-qualification has been made" goes into the process engine
The If - "if the value is greater than $1000" goes into the rules engine
The What - "send an approvment task" goes into the process engine
The Where - "a loan approver" goes into the mediator
The How - "using email" goes into the mediator

Good design often lead to less visability, and this is no exception. If the process says "using email" or "if the value is greater than $1000" then the implementation should say the same to reach good visability. But visability is not that important compared to using the right model (based on processes, rules, and services) and implementing it with a good SoC.

BPEL4People to OASIS

2007-06-26T16:06:00.000+01:00

The BPEL4People specification has been submitted to OASIS by a number of vendors including IBM, Oracle, SAP AG, Adobe Systems Inc. and Active Endpoints Inc.

BPMN Poster

2007-04-02T11:36:00.000+01:00

Here is a BPMN poster I found at Keith Swanson's.

BPM - Centralized or not?

2007-03-07T23:21:00.000+01:00

I attended a panel discussion at BPM in Action virtual conference today. I took the chance to ask whether the panel think BPM will be implemented in an enterprise centralized fashion (orchestrating enterprise services) or as a part of applications.

Kiran Garimella's avatar Dr. Jeffrey Sterllings answered by saying that the future of BPM will be a centralization of process implementations. Traditionally BPM has focused on a cross-functional process level. That means processes integrating applications within different organisational units (such as marketing, sales, finance, etc). But are those cross-functional processes really the most interesting to manage and measure, or is it the processes within a function/application?

For me it feels like a déjà vu, the whole centralization idea. EJB failed big time when trying to be the one and only point of integration to enterprise data. Will the BPMS fail for the same reasons, trying to be the one and only point of integration to enterprise services.

Vendors like PeopleSoft, SAP and other will not stand still watching their applications being disassembled into small services to be orchestrated in a centralized BPMS. They will probably provide BPM support as part of their own applications. And I'm affraid that every custom build application will host their own process implementation with more or less support for BPM. A call centre application would probably implement its own workflow engine, since the whole idea is to manage and measure the sequential activities. Same goes for a CRM and for a lot of other applications in an enterprise.

It will also be interesting to see if other vendors will follow Microsoft and provide a process engine framework for ISVs. Workflow Foundation supports process management and can be hosted in any .NET application.

How, what, when and why SOA?

2007-02-22T22:25:00.000+01:00

After taking part in a recent discussion on SOA, I would like to say that SOA doesn't answer the questions How, What or even When in terms of use, but do answer the question Why.

How?
There is a misunderstanding that SOA has something to do with how people should implement their services or group them in types of service behaviors. SOA makes no difference between services implementing master-data, processes, use-cases, entities, identities, rules, or legacy adapters nor does it care. To SOA a service is just a service.

What?
SOA doesn't require a specific message-passing technology but Web Services is preferred for obvious reasons.

When?
SOA is not suitable in all situations - but that isn't up to SOA to decide. The answer here is dependent upon the how and the what described above.

Why?
SOA answer the why-question with - to achieve business agility. Not by how services are implemented or with what technology is used, but with service management - the things that happens between the 2 service endpoints during a call. Things like versioning, routing, filtering, virtualization, en/decryption, en/decoding, monitoring, transformation, logging, translation, billing, validation, etc - all packaged in a nice runtime governance tool.

Why patterns?!

2007-02-22T13:42:00.000+01:00

Why can't you find a polymorphic pattern for OOD? Because it's so obvious!

Polymorphism is part of the paradigm and part of the oo-languages. It's not obvious how to use polymorphism, but there are no patterns describing it. Design patterns seems to concern ideas not really aimed for a specific software paradigm. I been thinking why patterns play such an important role today. It's just my believe that where ever there is a pattern, there is a shortcoming in the underlying paradigm/languages to solve a specific problem. I'm joining in criticism of patterns.

Cutting slices from a blob

2007-02-17T17:11:00.000+01:00

I liked the way Mats Helander described service-orientation. To understand the good thing about SOA you really need to see it from the business perspective. From a 10000' view, IT really looks like a big blob. On a 1000' view, you can discern smaller blobs which are applications (aka black boxes or silos). The SOA will help breaking up the applications in small services that can be composed into new services based on policies. The selection for how the services will be used in a composition is up to the heart of the SOA - the mediation layer. The mediation layer (such as WCF or Synapse) will make sure that the policies are applied correctly.

Some people claims that service composition (orchestration) is part of the SOA paradigm. I would rather give credit to BPM for techniques related to service composition.

A Business-Oriented Architecture

2007-02-12T18:22:00.000+01:00

While some people keep fighting for their knowledge domain, the world change around them. I'm talking about program languages, design tools and runtime engines, still using object-orientation as a model for implementing a business critical system. Since the early 90th object-oriented architectures have been the main technology platform for building solutions for business. What we got with us from those years is that technology driven view point of software development is bad. Whether an object-centric perspective helped the programmers understand the business or not isn't relevant. What we do know is that noone else understood the object model. Lot of initiatives have tried to bridge between the business and the OO model. Most of them have just made it worse, with really high cost as a result for software development.

No, there's a need for a new, better model for designing software. Something that the business can relate to, something that everyone can relate to. Processes and services are keys to this new model. We have all heard all the great stuff we can do with SOA and BPM, but what are the differences and can they play together?

A process-oriented architecture (POA) fits a company that's frequently changing and improving their business processes. This architecture supports a process improvement life cycle where bottle necks and bad design are found and adjusted using analyzis tools. A POA is a platform using a transparent model for business processes that aligns the business with IT very well.

A service-oriented architecture (SOA) on the other hand suites a company reorganizing their business structure frequently (such as out-sourcing, mergers and acquisitions, internal reorginization, etc). The main goal with a SOA is to control the services based on policies. These policies are defined in the service management framework. A SOA gives the agility in a business where services easily can be controlled from using service governance. A SOA will provide the virtual service mediation layer between the service consumer and the service producer where loosely coupling is crucial.

Normally a company would agree that both transparency and agility is important for their business. The only way to achieve this is by taking the road from OOA to a business-oriented architecture (BOA). This is a platform where the best from BPM and SOA is combined. People from the BPM community call this platform BPM 2.0, while some call it SOA 2.0. I think something neutral as BOA is more diplomatic.

The next question would be to ask which way is more natural to go from OOA to BOA, the red or the blue road. I would say the red because SOA is the foundation for a successfull POA.

Good Webinar on SAP Netweaver

2006-11-29T11:10:00.000+01:00

Check out this webinar on SAP Netweaver and listen to Amberpoint about their service management tools.

Microsoft readings in SOA/BPM space

2006-10-26T09:18:00.000+01:00

Here is a number of papers from Microsoft, relating to service-orientation.

BPEL & Humans

2006-10-12T12:37:00.000+01:00

BPEL is said to be designed for orchestration of web services. Some say BPEL is competent and suitable for business process implementations, but not for human workflows. I've also read that BPEL lacks in the way it orchestrates human interaction with business processes. I think one should separate those two scenarios from each other since they will have different impact on the critisism.

First, BPEL cannot describe a human workflow and I don't agree. A business process contains a flow with several descions on the way forward. A human workflow is the same where the flow is central, except that humans makes the descisions them self (in their head based on facts in that very moment). A business process will make a descision based on predefined rules. Where a BPEL process goes to a Rules Engine to make descision for a business process, a human workflow asks a human. The human is responding through web services.

Secondly, BPEL cannot communicate with humans. BPEL use partner links for inter communication, where a partner link is pointing out a web service endpoint. Yes, it's an endpoint and not a human, but behind the endpoint there can be a human. Some say humans are resource when someone asks for a role. The same thing can be said about web services. A web service interface is a role, where the running instance is the resource. Allocation of resources is handled by resource management tools in the same way as SOA tools handles service management.

I'm sorry, I can't see why humans are different when it comes to processes and services.

Meta-applications

2006-09-20T13:42:00.000+01:00

A classic application is like a black box of functionality which can be accessed and used by opaque interfaces. What's happening inside the application is not your business, but it guarantees the job will be done. A classic application is building trust by taking care of your data as long as you don't mess with how it's getting done.

In a service oriented world where services are used and reused as building blocks, the black box is gone. A SOA is transparent and built up of composite services. A SOA consists of meta-applications which consists of services. A meta-application is a set of services using the same policies as a trust boundary. With service governance the trust of meta-applications will be as high as for classic applications, or will it not?

Programmer, take control over your process!

2006-09-18T11:54:00.000+01:00

Think about the code you are writing for a second. Where do you implement the business process? First of all, let's define a business process.

Figure 1: Process flow is like a pipeline controlling access to the business objects over time.

A business process controls the state of a business object over time. Think of a process as a pipeline controlling incoming and outgoing messages, from and to the process flow. Only predetermined access is allowed to change the state of the business objects. This is just like normal code execution. No one except the programmer can control the flow of the execution for a specific program.


puts("Enter your age:");
gets(age);
if (age>30)
 printf("Welcome! Enter your name please:");
else
 printf("Yo! What's your name?:");
gets(name);
printf("Hello, %s", name);

In the code above the flow defines how we are handle the dialog with the outside world in C, just like a pipeline. No one can change this flow after it's deployed. This code is totally in control over the state change of the dialog. Eventhough a modern programmer writes code in this way, the general business application never controls the business objects. Why is that?

System design as it is practiced today, business processes are everywhere and anywhere. They are implemented in the database as triggers/SPs, in windows services, in web applications, in desktop apps and in middleware. The processes is not centric (like the C code) and cannot be controlled and managed in a centralized manner.

The reason for scattered process definitions or no process definition at all is deeply rooted in the programmers mind. He takes control over his execution flow, but doesn't take control and responsibility for the business flow. Instead of taking control over the business flow, the business objects are open for arbitrary access and state modification over time. A programmer's way of thinking is related to not understanding the business' needs, but also in the lack of tools and languages for writing process-centric applications.

Controlling the business process will result in a new way of designing applications. Start now, take control over your processes!

CentraSite™ Community

2006-09-13T08:23:00.000+01:00

"CentraSite Community is your community portal for all things SOA -- research, whitepapers, best practices, news, and opinion from the best and brightest in the SOA community."

WS-BPEL 2.0 Public Draft

2006-09-12T08:59:00.000+01:00

Check out the new specs for WS-BPEL 2.0.

Policy-driven Management

2006-09-11T09:35:00.000+01:00

Looking back in the history of IT, technologies have come an gone like mayflies. Some have stayed longer and some are like cockroaches which we can't get rid off.

The goal for IT remains the same though while the roadmap seems to be rewritten for all new technologies entering the market. Indiviual vendors doesn't have the patiance to be lasting and durable in the market and therefore tries to find the short answer to the roadmap.

With a couple of years behind us, following the adoption of XML, we are now seeing a pattern where standardized technologies enabling each other. Web Service couldn't be realized without XML eventhough Services were a well known term in IT. Same goes for SOA, an architecture for making services managable, reachable and reusable.

BPM (Business Process Managment) might be a successfull design, but based on SOA it will reach new hights and dictate the new way for building software. BSM (Business Service Managment) will leverage on BPM and be the last enabler for the main goal for IT.

The goal for IT will be to fully manage IT with a policy-driven management approach. A situation where the business policies dictate what service will be used for different processes.

It's about People, Business and Software

2006-09-10T20:44:00.000+01:00

Office 2007 and Vista are on the horizon and MS is starting to polish on the vision for the products. With People-Ready Business the new products will get packaged and deployed to the market, but what is the meaning of the announcement?

People is an important pillar in an enterprise where (let's say) Business and Software are the other two. Combining the three pillars with readiness (as the measurement for how they are related to the vision) will create 6 different messages. Below are the permutations of People, Business and Software in terms of readiness:

People Ready Business
Business Ready People
Software Ready People
People Ready Software
Software Ready Business
Business Ready Software

After a couple of minutes thinking about them, one thing pops up in my head. What if we got an enterprise with people who are ready for the business. People that are competent to use the software that is created for supporting the business. Software easy to use by the people. A business that can be improved with the right software in use and effectively runned by the right people.

It's a long shot, but isn't that the SOA marketing message we are talking about here?

The first step towards SOA

2006-09-04T15:57:00.000+01:00

Some leading SOA guidelines talks about understanding your business, processes and domains in advance of implementing any supporting tools. Understanding one's business is good but a SOA project probably have no use of that information initially. Starting with the big scope is often why those projects never see the day lights.

SOA implementations does not need to know about implementation details, such of business processes, data services, etc. This type of information is related to projects (such as BPM implementations) enabled by a SOA. The first step would instead be to build the foundation for your SOA (i.e. service governance tools). While many analysts and consultants recommend their clients not to go with a product-first-approach, that is definitely my number one recommendation.

The next step would be to make use of the SOA. The first project would preferably be one that leverage on all good things with SOA, but doesn't interfere with the day-to-day operational work. BPM implementations are the most obvious one in terms of making use of service governance. BPM is a top-down approach that will give you the services needed from a business process perspective. When you have defined your processes, a couple of service will be implemented as a result.

The third step would be to roll out a large scale BPM project and make your applications SOA-ready.

SOA-ready vs. Full-SOA applications

2006-09-04T15:23:00.000+01:00

Applications can be more or less ready for a SOA. A non-SOA application is one without any service endpoint, which almost never exists. Each application would have some form of interface, whether it's a GUI or an API. If you got a no-empty interface, you got services!

Functions can be exposed using a service facade accessable from other applications. An application where you have created web service endpoints on top of the APIs is a SOA-ready application. A SOA-ready app is characterized as a black-box, built for a specific function but extended to support cross-functional services. They got immutable boundaries framing the application functionality, accessing internal datasource and internal transaction scope only. Applications as we know them today are SOA-ready whenever they are extended with a service layer.

The next generation of applications are Full SOA enabled. The functional black-box is gone and replaced with an extensible boundary based on access policies. A Full SOA app can rely on external datasources and transaction scopes, which will make it possible to route data access to an external source. They are orchestrated in terms of how they use other services, which will give the benefits of BPM. A Full SOA app is not an executable, it's a configuration of how services interact with each other.

Is SOA about reusability or agility?

2006-08-30T22:24:00.000+01:00

David Chappell talks about SOA and reusability as if they relate to each other. I can somewhat agree , but from my point of view reuse isn't the main benefit of SOA. I would say agility is the main benefit and the foremost design goal for SOA.

Comparing reusability and agility in terms of which one is the easiest to achive, reusability is by far the harder challenge. Impediments to effective reuse are deeply rooted in human nature. Agility on the other hand is not.

While reusability belongs to object orientation, agility is the goal with service orientation and achieved with loose coupling between services in a SOA. David is mentioning service orchestration as the way of reaching loose coupling, but doesn't that relate to process management? I recently posted a few rows about the aspects of loosely coupling when it comes to service management and process management. I would say that agility can come from either, but a distinction between SOA and BPM need to be discussed.

Design approach

2006-08-25T11:45:00.000+01:00

Some claims that Service Orientation is bottom-up and Process Orientation is top-down. Since a process is encapsulated by a service, this service is higher up in the design then the encapsulated process. But, this service is on the other hand used by another process which puts that process up higher in the hierarchy. But who knows, there might be a service on top of this process as well. So, with mathematical induction one can prove that none is more top-down than the other.

SOA vs BPM

2006-08-17T14:47:00.000+01:00

Are SOA and BPM competing with each other, in aspect of making apps more loosely coupled?

The main idea with SOA is to be in control over the endpoints and the traffic between them, right? Service Management let you reroute the traffic between endpoints depending on content, header, etc. All this Service Management stuff make the parts of a system more loosely coupled to each other and easier to reconstruct on the fly.

BPM has a similar goal of making things more loosely coupled. But the way Process Management handles loose coupling is by making the execution path more managable. In the same way Service Management can modify the traffic flow on the fly, Process Management can modify the flow of messages between subprocesses or other services. That type of managability is related to the flexibility in the implementation of the service, rather than the coupling between them.