Wednesday, August 22, 2007
Lack of understanding of SOA within the ECM community
My significant other believes that folks in the ECM community and their love of REST are getting things twisted and need an altenrative perspective...
She commented on Brian Huff and his posting regarding REST which she believes is the notion of document-centric REST which ignores the fact that an SOA participates in larger transactions where ECM isn't the center of the world but that ECM vendors design their products as such.
She believes that the granularity of ECM and their services are way too fine grained and that they are additional busted when it comes to transaction semantics. The notion of SOA says that one should align coarse-grained services with a business architecture. For example, a business architecture may say that there is a need to have functionality for paying claims which is coarse-grained.
The need to pay a claim from a more technical perspective may involve multiple orchestrations where folks are either interacting with humans using a BPM engine such as jBPM, Intalio, Lombardi Software, Pega or any of the other fine product offerings or it could leverage a BPEL approach such as Oracle's BPEL Manager, FiveSight or equivalent products. The first thing that comes to mind is that ECM is a participant in this type of transaction and should defer/support transactions in a larger context.
Her second thought is that ECM systems that support the notion of sessions would be flawed in this business scenario as it is not the responsibility of an orchestrator to understand the state of an ECM system as services should truly be designed in a stateless way. Many of the ECM vendors have simply used WSDL and/or REST to put a facade over suboptimal designs.
Her third thought is that the notion of retrieving a document really should be thought of as a step in the pay a claim business service and that the exposed ECM contract should support other considerations such as the ability to defer authorization to the higher level process and avoid synchronization semantics as this would litter up higher level processes.
She also believes that ECM vendors haven't spent much time truly thinking about the value proposition of services and are guilty of thinking about WSDL and REST solely from an integration perspective while sleeping on how ECM plays as part of a larger business-driven SOA. Sadly, this topic has been covered to death within magazines and even the blogosphere, yet the world of ECM seems to trail pretty much every other technology horizontal including CRM, BPM, ERP, ESB and so on in terms of embracing modern approaches.
I really hate the fact that my significant other has been busy reading my books and blogs as she has started to find holes in my own thinking. Her conclusion is that products such as Nuxeo and Documentum which expose WSDL may be better positioned in the long run over the camp comprised of Stellent, OpenText and Alfresco that has fell in love with REST because it makes lots of sense if you only see things through the ECM-colored glasses. At least we collectively agree that industry analysts such as Alan Pelz-Sharpe, Karen Hobert, Tom Bryne, John Mancini, Nick Patience and others need to start paying more attention to how SOA and ECM are not only converging from the stories told by vendors but should equally focus on how it should converge...
| | View blog reactionsShe commented on Brian Huff and his posting regarding REST which she believes is the notion of document-centric REST which ignores the fact that an SOA participates in larger transactions where ECM isn't the center of the world but that ECM vendors design their products as such.
She believes that the granularity of ECM and their services are way too fine grained and that they are additional busted when it comes to transaction semantics. The notion of SOA says that one should align coarse-grained services with a business architecture. For example, a business architecture may say that there is a need to have functionality for paying claims which is coarse-grained.
The need to pay a claim from a more technical perspective may involve multiple orchestrations where folks are either interacting with humans using a BPM engine such as jBPM, Intalio, Lombardi Software, Pega or any of the other fine product offerings or it could leverage a BPEL approach such as Oracle's BPEL Manager, FiveSight or equivalent products. The first thing that comes to mind is that ECM is a participant in this type of transaction and should defer/support transactions in a larger context.
Her second thought is that ECM systems that support the notion of sessions would be flawed in this business scenario as it is not the responsibility of an orchestrator to understand the state of an ECM system as services should truly be designed in a stateless way. Many of the ECM vendors have simply used WSDL and/or REST to put a facade over suboptimal designs.
Her third thought is that the notion of retrieving a document really should be thought of as a step in the pay a claim business service and that the exposed ECM contract should support other considerations such as the ability to defer authorization to the higher level process and avoid synchronization semantics as this would litter up higher level processes.
She also believes that ECM vendors haven't spent much time truly thinking about the value proposition of services and are guilty of thinking about WSDL and REST solely from an integration perspective while sleeping on how ECM plays as part of a larger business-driven SOA. Sadly, this topic has been covered to death within magazines and even the blogosphere, yet the world of ECM seems to trail pretty much every other technology horizontal including CRM, BPM, ERP, ESB and so on in terms of embracing modern approaches.
I really hate the fact that my significant other has been busy reading my books and blogs as she has started to find holes in my own thinking. Her conclusion is that products such as Nuxeo and Documentum which expose WSDL may be better positioned in the long run over the camp comprised of Stellent, OpenText and Alfresco that has fell in love with REST because it makes lots of sense if you only see things through the ECM-colored glasses. At least we collectively agree that industry analysts such as Alan Pelz-Sharpe, Karen Hobert, Tom Bryne, John Mancini, Nick Patience and others need to start paying more attention to how SOA and ECM are not only converging from the stories told by vendors but should equally focus on how it should converge...