<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Decoupling ECM features revisited</title>
	<atom:link href="http://apoorv.info/2007/01/12/decoupling-ecm-features-revisited/feed/" rel="self" type="application/rss+xml" />
	<link>http://apoorv.info/2007/01/12/decoupling-ecm-features-revisited/</link>
	<description>Random Thoughts</description>
	<lastBuildDate>Mon, 05 Dec 2011 13:29:30 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Srinath</title>
		<link>http://apoorv.info/2007/01/12/decoupling-ecm-features-revisited/#comment-4324</link>
		<dc:creator><![CDATA[Srinath]]></dc:creator>
		<pubDate>Tue, 27 Mar 2007 21:41:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.apoorv.info/index.php/2007/01/12/decoupling-ecm-features-revisited/#comment-4324</guid>
		<description><![CDATA[The notion that Apoorv alluded to and John expanded on with regards to the correlation of BPM and ECM rings very true - these product sets do need to be componentized and support loose coupling based on open standards so as to allow customers to easily assemble a solution infrastructure that combines these different product sets to solve business problems.

In reality, automating and managing business processes is mostly a enterprise integration problem involving people, systems &amp; services, and goes beyond just BPM and ECM systems to also include ERP systems, Mainframes, custom apps, external data feeds, email systems etc.]]></description>
		<content:encoded><![CDATA[<p>The notion that Apoorv alluded to and John expanded on with regards to the correlation of BPM and ECM rings very true &#8211; these product sets do need to be componentized and support loose coupling based on open standards so as to allow customers to easily assemble a solution infrastructure that combines these different product sets to solve business problems.</p>
<p>In reality, automating and managing business processes is mostly a enterprise integration problem involving people, systems &amp; services, and goes beyond just BPM and ECM systems to also include ERP systems, Mainframes, custom apps, external data feeds, email systems etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Newton</title>
		<link>http://apoorv.info/2007/01/12/decoupling-ecm-features-revisited/#comment-4321</link>
		<dc:creator><![CDATA[John Newton]]></dc:creator>
		<pubDate>Thu, 08 Feb 2007 12:36:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.apoorv.info/index.php/2007/01/12/decoupling-ecm-features-revisited/#comment-4321</guid>
		<description><![CDATA[Howard Shao, the other co-founder of Documentum, and I recently had a disagreement about this. We had an on-going discussion during the 90s as to whether we should just concentrate on content management and partner on workflow or do both. The sales force was pulling us in both directions.

With Alfresco, we had the choice and chose to embed jBPM, but keep the interface open to other engines. Standards like BPEL make it possible to do this more easily. Content management is neither above nor below workflow - they are orthogonal dimensions that intersect frequently. When workflow strays beyond content management to intersect with CRM, ERP or communication, then it is clear that you need a different set of expertise.

We are taking the same approach with search. Rather than just make the search engine pluggable, we are really making search pluggable. Using the opensearch.org interface we can federate, not just other Alfresco repositories, but anything that supports opensearch, including internet search.

Services around search, content control, content capture, presentation, etc. should be componentized and built around low-friction, low-impedance interfaces allow component providers to follow their core competencies. As more vendors start to adopt REST interfaces and mash-ups start to become a more common occurence in the enterprise, this evolution we become more natural and inevitable.]]></description>
		<content:encoded><![CDATA[<p>Howard Shao, the other co-founder of Documentum, and I recently had a disagreement about this. We had an on-going discussion during the 90s as to whether we should just concentrate on content management and partner on workflow or do both. The sales force was pulling us in both directions.</p>
<p>With Alfresco, we had the choice and chose to embed jBPM, but keep the interface open to other engines. Standards like BPEL make it possible to do this more easily. Content management is neither above nor below workflow &#8211; they are orthogonal dimensions that intersect frequently. When workflow strays beyond content management to intersect with CRM, ERP or communication, then it is clear that you need a different set of expertise.</p>
<p>We are taking the same approach with search. Rather than just make the search engine pluggable, we are really making search pluggable. Using the opensearch.org interface we can federate, not just other Alfresco repositories, but anything that supports opensearch, including internet search.</p>
<p>Services around search, content control, content capture, presentation, etc. should be componentized and built around low-friction, low-impedance interfaces allow component providers to follow their core competencies. As more vendors start to adopt REST interfaces and mash-ups start to become a more common occurence in the enterprise, this evolution we become more natural and inevitable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Apoorv</title>
		<link>http://apoorv.info/2007/01/12/decoupling-ecm-features-revisited/#comment-4323</link>
		<dc:creator><![CDATA[Apoorv]]></dc:creator>
		<pubDate>Fri, 19 Jan 2007 04:54:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.apoorv.info/index.php/2007/01/12/decoupling-ecm-features-revisited/#comment-4323</guid>
		<description><![CDATA[Kashyap,
Thanks for stopping by.
You are right but then CMS vendors would say that modelling is not their key functionaility.

However, i believe many vendors have started including more visual tools. Interwoven&#039;s TeamSite has one and so do Documentum and FileNet.

BR,
Apoorv]]></description>
		<content:encoded><![CDATA[<p>Kashyap,<br />
Thanks for stopping by.<br />
You are right but then CMS vendors would say that modelling is not their key functionaility.</p>
<p>However, i believe many vendors have started including more visual tools. Interwoven&#8217;s TeamSite has one and so do Documentum and FileNet.</p>
<p>BR,<br />
Apoorv</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kashyap</title>
		<link>http://apoorv.info/2007/01/12/decoupling-ecm-features-revisited/#comment-4322</link>
		<dc:creator><![CDATA[Kashyap]]></dc:creator>
		<pubDate>Fri, 19 Jan 2007 04:33:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.apoorv.info/index.php/2007/01/12/decoupling-ecm-features-revisited/#comment-4322</guid>
		<description><![CDATA[One difference I&#039;ve noticed is that BPM products usually provide a visual modeler for process design while it is not so common with CMS products - do you think there is a need for CMS products to provide advanced modeling tools for workflows, process design etc?]]></description>
		<content:encoded><![CDATA[<p>One difference I&#8217;ve noticed is that BPM products usually provide a visual modeler for process design while it is not so common with CMS products &#8211; do you think there is a need for CMS products to provide advanced modeling tools for workflows, process design etc?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

