OK, so this second post may not have the immediate shock value of a "War is Peace" kind of statement that I had in my first, but it still talks about things that people don't normally acknowledge.
Here's today's Orwellian quote:
"SOA subsumes BPM. SOA subsumes ECM."
First of all, why should this be a shocking statement? Because in many organisations, SOA, BPM and ECM are viewed as different things altogether. SOA is considered to be new-age stuff. It's supposed to be all about SOAP, Web Services, BPEL, ESB and other new-fangled technologies. BPM and ECM, on the other hand, having evolved from earlier workflow and document management products, are seen as more "legacy".
Is BPM (Business Process Management) part of SOA? Many people I talk to make a distinction between "workflow" (by which they mean business processes involving people) and process orchestration (by which they mean the automated invocation of computer-based services). The latter is typically implemented as BPEL-defined processes coordinating SOAP-based Web Services. And while BPM products have begun to support BPEL today, they're still used for only workflow tasks. Even more interestingly, large vendors who sell both BPM and process orchestration tools discourage customer organisations from using BPM tools for the latter task even if they're BPEL-capable.
I'd like to challenge this distinction. And I'm going to do this by going back to SOA's first principles, and not falling into the trap of thinking that SOA means Web Services technology.
The SOA approach requires us to analyse business processes as first-class entities. What is the business function that is being performed? The analyst breaks down the process into logical steps, perhaps rationalises it as well in a BPR kind of exercise, then defines the boundaries between process steps through contracts that define the information flow that occurs across those boundaries.
That's why SOA is often referred to as "Contract-Oriented Architecture".
Take the example of a loan approval process. One of the initial steps is a credit check. The process needs to call upon a "service" that performs this function. It needs to pass this service the necessary identifying data about the applicant so that the service can return a credit rating. At a later stage in the process, especially if the loan application is a borderline case, a loan officer may be required to assess the application and provide an approval/rejection decision.
From a SOA perspective, I would argue that these two examples are no different. In each case, the process involves a step where some data needs to be sent off to some specialised service provider in order to receive a specialised piece of information, which is then used in subsequent steps of the process. If we define the boundaries of the process steps in terms of contracts, there is nothing whatever at the logical level to distinguish one from the other on the basis that the first is automated and the second is manual. They're both identical from an interaction perspective. The first may take mere seconds while the second may take minutes, hours or days, but logically, the interaction model is the same.
This ties back to the earlier point about synchronous being asynchronous and real-time being batch. There is a standard interaction model within SOA. The process interacts with an automated credit check service asynchronously by placing applicant data (a batch of one) in a queue, and picks up credit rating data from another queue when triggered by the arrival of that data. In exactly analogous fashion, the process places application data in a queue (the loan officer's inbox) and picks up the approval/rejection decision from another queue (the loan officer's outbox).
It's a sort of Turing test within SOA. How can a process tell that a particular service step is being performed by a human and not an automated system? The answer is that it can't. In fact, it shouldn't, or else it's no longer SOA, because we violate the contract if we use implied knowledge! In that sense, it's an unfair Turing test, because we're not allowed to use any information outside of the contract to guess at the implementation. Hiding implementation behind contracts is the beauty of SOA, because it allows replacement of manual systems by automated ones, or the outsourcing of certain process steps, without breaking the process itself and impacting business continuity.
So that proves my point. SOA subsumes BPM.
ECM (Enterprise Content Management) seems to be another beast altogether. We're not talking services here. We're talking data. Surely that doesn't have much to do with SOA unless services are built on top of it?
Surprise. If we adopt the REST approach to SOA, we find that what we're doing is perfunctorily dismissing the "service" or "verb" side of the design by employing a uniform, polymorphic CRUDish interface and concentrating mainly on the modelling of the "resources" involved. The distinctive "services" that make up the application from a service consumer's point of view automatically follow from the type of resource and the polymorphic nature of the RESTian verbs. REST is effectively based on a very audacious premise that no matter what your application, you can always model it as a set of resources in such a way that the standard four RESTian verbs will let you perform all the kinds of manipulation that you could possibly hope to perform on them.
I haven't yet seen a convincing repudiation of that approach. The REST approach seems to scale to arbitrary levels of application complexity. It's almost as if service-orientation appears as a byproduct of the organisation of the application domain as a structured collection of "content". An approach to Content Management is therefore a valid approach to SOA! And that proves my second point. SOA subsumes ECM.
I'm sure these views will gradually gain currency, and that bolder organisations will start to bring all of these functions under a common umbrella. But for the near future, I'm afraid we will continue to see a rather fragmented approach to SOA, BPM and ECM.
Here's today's Orwellian quote:
"SOA subsumes BPM. SOA subsumes ECM."
First of all, why should this be a shocking statement? Because in many organisations, SOA, BPM and ECM are viewed as different things altogether. SOA is considered to be new-age stuff. It's supposed to be all about SOAP, Web Services, BPEL, ESB and other new-fangled technologies. BPM and ECM, on the other hand, having evolved from earlier workflow and document management products, are seen as more "legacy".
Is BPM (Business Process Management) part of SOA? Many people I talk to make a distinction between "workflow" (by which they mean business processes involving people) and process orchestration (by which they mean the automated invocation of computer-based services). The latter is typically implemented as BPEL-defined processes coordinating SOAP-based Web Services. And while BPM products have begun to support BPEL today, they're still used for only workflow tasks. Even more interestingly, large vendors who sell both BPM and process orchestration tools discourage customer organisations from using BPM tools for the latter task even if they're BPEL-capable.
I'd like to challenge this distinction. And I'm going to do this by going back to SOA's first principles, and not falling into the trap of thinking that SOA means Web Services technology.
The SOA approach requires us to analyse business processes as first-class entities. What is the business function that is being performed? The analyst breaks down the process into logical steps, perhaps rationalises it as well in a BPR kind of exercise, then defines the boundaries between process steps through contracts that define the information flow that occurs across those boundaries.
That's why SOA is often referred to as "Contract-Oriented Architecture".
Take the example of a loan approval process. One of the initial steps is a credit check. The process needs to call upon a "service" that performs this function. It needs to pass this service the necessary identifying data about the applicant so that the service can return a credit rating. At a later stage in the process, especially if the loan application is a borderline case, a loan officer may be required to assess the application and provide an approval/rejection decision.
From a SOA perspective, I would argue that these two examples are no different. In each case, the process involves a step where some data needs to be sent off to some specialised service provider in order to receive a specialised piece of information, which is then used in subsequent steps of the process. If we define the boundaries of the process steps in terms of contracts, there is nothing whatever at the logical level to distinguish one from the other on the basis that the first is automated and the second is manual. They're both identical from an interaction perspective. The first may take mere seconds while the second may take minutes, hours or days, but logically, the interaction model is the same.
This ties back to the earlier point about synchronous being asynchronous and real-time being batch. There is a standard interaction model within SOA. The process interacts with an automated credit check service asynchronously by placing applicant data (a batch of one) in a queue, and picks up credit rating data from another queue when triggered by the arrival of that data. In exactly analogous fashion, the process places application data in a queue (the loan officer's inbox) and picks up the approval/rejection decision from another queue (the loan officer's outbox).
It's a sort of Turing test within SOA. How can a process tell that a particular service step is being performed by a human and not an automated system? The answer is that it can't. In fact, it shouldn't, or else it's no longer SOA, because we violate the contract if we use implied knowledge! In that sense, it's an unfair Turing test, because we're not allowed to use any information outside of the contract to guess at the implementation. Hiding implementation behind contracts is the beauty of SOA, because it allows replacement of manual systems by automated ones, or the outsourcing of certain process steps, without breaking the process itself and impacting business continuity.
So that proves my point. SOA subsumes BPM.
ECM (Enterprise Content Management) seems to be another beast altogether. We're not talking services here. We're talking data. Surely that doesn't have much to do with SOA unless services are built on top of it?
Surprise. If we adopt the REST approach to SOA, we find that what we're doing is perfunctorily dismissing the "service" or "verb" side of the design by employing a uniform, polymorphic CRUDish interface and concentrating mainly on the modelling of the "resources" involved. The distinctive "services" that make up the application from a service consumer's point of view automatically follow from the type of resource and the polymorphic nature of the RESTian verbs. REST is effectively based on a very audacious premise that no matter what your application, you can always model it as a set of resources in such a way that the standard four RESTian verbs will let you perform all the kinds of manipulation that you could possibly hope to perform on them.
I haven't yet seen a convincing repudiation of that approach. The REST approach seems to scale to arbitrary levels of application complexity. It's almost as if service-orientation appears as a byproduct of the organisation of the application domain as a structured collection of "content". An approach to Content Management is therefore a valid approach to SOA! And that proves my second point. SOA subsumes ECM.
I'm sure these views will gradually gain currency, and that bolder organisations will start to bring all of these functions under a common umbrella. But for the near future, I'm afraid we will continue to see a rather fragmented approach to SOA, BPM and ECM.
