<?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/"
		>
<channel>
	<title>Comments on: Why It’s Time to Embrace a New Collaboration Model</title>
	<atom:link href="http://blogs.cisco.com/collaboration/why-its-time-to-embrace-a-new-collaboration-model/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.cisco.com/collaboration/why-its-time-to-embrace-a-new-collaboration-model/</link>
	<description></description>
	<lastBuildDate>Wed, 19 Jun 2013 07:30:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: John Gaudin</title>
		<link>http://blogs.cisco.com/collaboration/why-its-time-to-embrace-a-new-collaboration-model/#comment-607159</link>
		<dc:creator>John Gaudin</dc:creator>
		<pubDate>Thu, 28 Jun 2012 00:01:10 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.cisco.com/?p=72639#comment-607159</guid>
		<description><![CDATA[Thanks, Dan.  Appreciate the response and completely agree.

I really like the concept of the universal post and am considering use cases for it.  I think the transition to a universal post for existing users could be straightforward if the client applications are developed with minimal change to what&#039;s used today.  IMO the popularity of e-mail stems from its ubiquity and speed of use.  I can access e-mail through a variety of clients and devices which usually POP the messages locally.  Changing that workflow and requiring a user to access posts for reading and authoring in other ways, may prove challenging unless the benefits of the universal post is realized.

I look forward to learning more on the universal post.]]></description>
		<content:encoded><![CDATA[<p>Thanks, Dan.  Appreciate the response and completely agree.</p>
<p>I really like the concept of the universal post and am considering use cases for it.  I think the transition to a universal post for existing users could be straightforward if the client applications are developed with minimal change to what&#8217;s used today.  IMO the popularity of e-mail stems from its ubiquity and speed of use.  I can access e-mail through a variety of clients and devices which usually POP the messages locally.  Changing that workflow and requiring a user to access posts for reading and authoring in other ways, may prove challenging unless the benefits of the universal post is realized.</p>
<p>I look forward to learning more on the universal post.
<p class="comment-like"><img class="comment-like-btn" title="Vote" onclick="cl_like_this('http://blogs.cisco.com/wp-admin/admin-ajax.php',607159)" src="http://blogs.cisco.com/wp-content/plugins/comments-likes/images/like.png" />&nbsp;&nbsp;&nbsp;<span id="comment-like-cnt-607159">0</span> likes</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel W. Rasmus</title>
		<link>http://blogs.cisco.com/collaboration/why-its-time-to-embrace-a-new-collaboration-model/#comment-607082</link>
		<dc:creator>Daniel W. Rasmus</dc:creator>
		<pubDate>Wed, 27 Jun 2012 18:37:28 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.cisco.com/?p=72639#comment-607082</guid>
		<description><![CDATA[John,
Thank you for the thoughtful response. Here are my responses.

In terms of document security, I have proposed for several years now the idea of component-level security. Portions of a document, could, for instance, have lower-level access controls assigned to them that would manifest in the interpretation of the content. In the case you mention, automatic redaction would take place at the time the content was interpreted. The implementation of this, the underlying encryption models and other aspects were outside of the scope of this paper, but I think they are important and something the industry needs to address. If we move access control down to content we can spend less time worrying about network architecture and more time worrying about content, which then pushes responsibility to content owners. That of course, may offer its own challenges.

I like the idea of a sub-post, and perhaps should have included in the specification. The idea is address a bit in object transformation, but I did not specify a hierarchy, which would need to be included for sub-posts to work.  Next version of the document will make this more explicit.

Delete: I am not big on delete. I am a former Chief Knowledge Officer, so I have seen many times that something is deleted and later needed. Deletion forces a value judgment on an object, sometimes by people who don&#039;t understand its value or potential value. I would rather archive for retrieval. Data storage is cheap. If storage becomes untenable, old, unreferenced objects could be moved to even less expensive storage, but they need to remain in the index. I was involved in a project once to build some power supplies for the US Air Force from 20-year old designs that had been &quot;deleted&quot; by engineering. They ended up building the new units from Polaroid pictures of the old ones. That lesson stuck.

Media agnostic: I agree. I mention that all too briefly in the Rich Attachments heading. Keeping an eye on page count forces a certain terseness.

Workflows: the topic of, as I call it, structured collaboration, was not included here for space reasons. It is a valid point. Collaborative, or ad hoc, workflows are mentioned. The universal post should be a first-class object that can be routed by business rules, but it could, if we take the idea of universal to its extreme, be an executable object with business rules governing its internal behavior, just its metadata.

When I say &quot;post e-mail world&quot; I mean just what you imply. And it may be a bit much for people, but we don&#039;t innovate and transform through slow transitions. As an analyst, part of my role in the industry is to invoke new perspectives and provoke thought. If I just said: here&#039;s another idea that will run alongside e-mail, people would not read it, perhaps, as diligently, and it would, in fact, miss the point, which is e-mail is a very poor way of working. If Microsoft makes Outlook into a Universal Post front-end and people adopt that, great. I&#039;m not out after Outlook clients, I&#039;m trying to solve the issues of e-mail-based collaboration.

Federation: I think we will see more business partner B2B directory federation in the future. This paper was written from the enterprise perspective, so it makes certain assumptions (or perhaps more clearly, doesn&#039;t worry) about organizational agreements about identity. The design here suggests that people are represented by an identity with rich metadata about the identities owner. If that metadata includes federated identity, that does not violate the design.

Again, thank you for the thoughtful response. This is the kind of dialog that is needed to drive forward. I did not intend this paper to be the ultimate design, but a thought provoking entry point to even deeper dialog. It is, after all, a paper about collaboration.]]></description>
		<content:encoded><![CDATA[<p>John,<br />
Thank you for the thoughtful response. Here are my responses.</p>
<p>In terms of document security, I have proposed for several years now the idea of component-level security. Portions of a document, could, for instance, have lower-level access controls assigned to them that would manifest in the interpretation of the content. In the case you mention, automatic redaction would take place at the time the content was interpreted. The implementation of this, the underlying encryption models and other aspects were outside of the scope of this paper, but I think they are important and something the industry needs to address. If we move access control down to content we can spend less time worrying about network architecture and more time worrying about content, which then pushes responsibility to content owners. That of course, may offer its own challenges.</p>
<p>I like the idea of a sub-post, and perhaps should have included in the specification. The idea is address a bit in object transformation, but I did not specify a hierarchy, which would need to be included for sub-posts to work.  Next version of the document will make this more explicit.</p>
<p>Delete: I am not big on delete. I am a former Chief Knowledge Officer, so I have seen many times that something is deleted and later needed. Deletion forces a value judgment on an object, sometimes by people who don&#8217;t understand its value or potential value. I would rather archive for retrieval. Data storage is cheap. If storage becomes untenable, old, unreferenced objects could be moved to even less expensive storage, but they need to remain in the index. I was involved in a project once to build some power supplies for the US Air Force from 20-year old designs that had been &#8220;deleted&#8221; by engineering. They ended up building the new units from Polaroid pictures of the old ones. That lesson stuck.</p>
<p>Media agnostic: I agree. I mention that all too briefly in the Rich Attachments heading. Keeping an eye on page count forces a certain terseness.</p>
<p>Workflows: the topic of, as I call it, structured collaboration, was not included here for space reasons. It is a valid point. Collaborative, or ad hoc, workflows are mentioned. The universal post should be a first-class object that can be routed by business rules, but it could, if we take the idea of universal to its extreme, be an executable object with business rules governing its internal behavior, just its metadata.</p>
<p>When I say &#8220;post e-mail world&#8221; I mean just what you imply. And it may be a bit much for people, but we don&#8217;t innovate and transform through slow transitions. As an analyst, part of my role in the industry is to invoke new perspectives and provoke thought. If I just said: here&#8217;s another idea that will run alongside e-mail, people would not read it, perhaps, as diligently, and it would, in fact, miss the point, which is e-mail is a very poor way of working. If Microsoft makes Outlook into a Universal Post front-end and people adopt that, great. I&#8217;m not out after Outlook clients, I&#8217;m trying to solve the issues of e-mail-based collaboration.</p>
<p>Federation: I think we will see more business partner B2B directory federation in the future. This paper was written from the enterprise perspective, so it makes certain assumptions (or perhaps more clearly, doesn&#8217;t worry) about organizational agreements about identity. The design here suggests that people are represented by an identity with rich metadata about the identities owner. If that metadata includes federated identity, that does not violate the design.</p>
<p>Again, thank you for the thoughtful response. This is the kind of dialog that is needed to drive forward. I did not intend this paper to be the ultimate design, but a thought provoking entry point to even deeper dialog. It is, after all, a paper about collaboration.
<p class="comment-like"><img class="comment-like-btn" title="Vote" onclick="cl_like_this('http://blogs.cisco.com/wp-admin/admin-ajax.php',607082)" src="http://blogs.cisco.com/wp-content/plugins/comments-likes/images/like.png" />&nbsp;&nbsp;&nbsp;<span id="comment-like-cnt-607082">0</span> likes</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Gaudin</title>
		<link>http://blogs.cisco.com/collaboration/why-its-time-to-embrace-a-new-collaboration-model/#comment-606506</link>
		<dc:creator>John Gaudin</dc:creator>
		<pubDate>Mon, 25 Jun 2012 19:36:50 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.cisco.com/?p=72639#comment-606506</guid>
		<description><![CDATA[Really enjoyed the read on the universal post.  I do have a few thoughts to share for comment.

Let&#039;s say you have a large document and are using external resources.  Portions of the document may require NDA or be corporate sensitive.  Sharing the full post would violate corporate or Government policy by exposing sensitive information to external audiences.  Today this is done by manually breaking apart a section, sending it out, then manually stitching the updates back together to a single document.  I see two ways of addressing this use case:
- Redact: perhaps the simplest is to select the section that&#039;s viewable/editable by the external vendor and redact the rest of the document, or select portions to be redacted and leave the rest.  Changes to the non-redacted sections would still update in real-time, while the rest of the document could not be viewed unless the user had proper permissions.  I imagine there would be other reasons to redact portions of a post for view only as well.
- Sub-post: a selected section of the &quot;root post&quot; would essentially be carved out and made into a sub-post that would have the same capability of policy/permissions assigned to it.  A little bit more tricky because you&#039;d then have to &quot;stitch&quot; the sub-posts together to make the final post, which may go beyond the intent of the &quot;Edit&quot; capability.
 
Is &quot;delete&quot; part of edit?  When you consider the amount of &quot;corporate&quot; communications among employees that may be nothing more then when/where to meet for lunch or happy hour, these &quot;posts&quot; are not relevant to the business and should be deleted (perhaps still stored for compliancy purposes) and at a minimum removed from search and graph functions.

I also feel a post should be media agnostic.  I should be able to take a voicemail append comments in text, audio or video then send it to my &quot;post repository&quot; to be shared with others who can then also add comments in any media type.

I think a universal post must have the capability to be integrated into a workflow that follows business rules.  The rules would differ based on the intent of the post.  If the post is to group-source a document for publication there&#039;s the adding and editing of content, perhaps graphics, approval, final review, and publication.  On the other hand a universal post could become a form such as a SOW and PO that would need to be shared with a vendor, approved, up the chain, converted to a AP record, mapped or appended with a PO, signed, paid, etc.  This may be something that would be addressed through APIs and not a core requirement of the post itself?

I wonder if the &quot;post e-mail&quot; world is a bit much for most people.  I would argue that e-mail won&#039;t go away, but it will transform to something else.  What if I can still use my e-mail client to open, edit, and &quot;send&quot; a post that then notifies you of changes?  You may choose to access the &quot;post repository&quot; using an e-mail client, webpage, tablet, phone (assuming transcribing exists), smartphone, or specialized application.  When you say &quot;post e-mail&quot; I wonder if people immediately think their Outlook, Yahoo or corporate accounts and clients would disappear.

Is federation a requirement for the universal post?  We see people using multiple addresses today.  In many cases, they&#039;re manually bridging across addresses via e-mail or file share, etc. and once a post leaves the system the integrity of the post is compromised.

A great paper and definitely food for thought.  Wanted to share some initial questions that came to mind when reading.]]></description>
		<content:encoded><![CDATA[<p>Really enjoyed the read on the universal post.  I do have a few thoughts to share for comment.</p>
<p>Let&#8217;s say you have a large document and are using external resources.  Portions of the document may require NDA or be corporate sensitive.  Sharing the full post would violate corporate or Government policy by exposing sensitive information to external audiences.  Today this is done by manually breaking apart a section, sending it out, then manually stitching the updates back together to a single document.  I see two ways of addressing this use case:<br />
- Redact: perhaps the simplest is to select the section that&#8217;s viewable/editable by the external vendor and redact the rest of the document, or select portions to be redacted and leave the rest.  Changes to the non-redacted sections would still update in real-time, while the rest of the document could not be viewed unless the user had proper permissions.  I imagine there would be other reasons to redact portions of a post for view only as well.<br />
- Sub-post: a selected section of the &#8220;root post&#8221; would essentially be carved out and made into a sub-post that would have the same capability of policy/permissions assigned to it.  A little bit more tricky because you&#8217;d then have to &#8220;stitch&#8221; the sub-posts together to make the final post, which may go beyond the intent of the &#8220;Edit&#8221; capability.</p>
<p>Is &#8220;delete&#8221; part of edit?  When you consider the amount of &#8220;corporate&#8221; communications among employees that may be nothing more then when/where to meet for lunch or happy hour, these &#8220;posts&#8221; are not relevant to the business and should be deleted (perhaps still stored for compliancy purposes) and at a minimum removed from search and graph functions.</p>
<p>I also feel a post should be media agnostic.  I should be able to take a voicemail append comments in text, audio or video then send it to my &#8220;post repository&#8221; to be shared with others who can then also add comments in any media type.</p>
<p>I think a universal post must have the capability to be integrated into a workflow that follows business rules.  The rules would differ based on the intent of the post.  If the post is to group-source a document for publication there&#8217;s the adding and editing of content, perhaps graphics, approval, final review, and publication.  On the other hand a universal post could become a form such as a SOW and PO that would need to be shared with a vendor, approved, up the chain, converted to a AP record, mapped or appended with a PO, signed, paid, etc.  This may be something that would be addressed through APIs and not a core requirement of the post itself?</p>
<p>I wonder if the &#8220;post e-mail&#8221; world is a bit much for most people.  I would argue that e-mail won&#8217;t go away, but it will transform to something else.  What if I can still use my e-mail client to open, edit, and &#8220;send&#8221; a post that then notifies you of changes?  You may choose to access the &#8220;post repository&#8221; using an e-mail client, webpage, tablet, phone (assuming transcribing exists), smartphone, or specialized application.  When you say &#8220;post e-mail&#8221; I wonder if people immediately think their Outlook, Yahoo or corporate accounts and clients would disappear.</p>
<p>Is federation a requirement for the universal post?  We see people using multiple addresses today.  In many cases, they&#8217;re manually bridging across addresses via e-mail or file share, etc. and once a post leaves the system the integrity of the post is compromised.</p>
<p>A great paper and definitely food for thought.  Wanted to share some initial questions that came to mind when reading.
<p class="comment-like"><img class="comment-like-btn" title="Vote" onclick="cl_like_this('http://blogs.cisco.com/wp-admin/admin-ajax.php',606506)" src="http://blogs.cisco.com/wp-content/plugins/comments-likes/images/like.png" />&nbsp;&nbsp;&nbsp;<span id="comment-like-cnt-606506">0</span> likes</p>
]]></content:encoded>
	</item>
</channel>
</rss>
