<?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:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
		
	>
<channel>
	<title>Comments on: Google Buzz&#8217;s True Home Is in the Enterprise</title>
	<atom:link href="http://research.gigaom.com/2010/02/google-buzzs-true-home-is-in-the-enterprise/feed/" rel="self" type="application/rss+xml" />
	<link>http://research.gigaom.com/2010/02/google-buzzs-true-home-is-in-the-enterprise/</link>
	<description></description>
	<lastBuildDate>Thu, 05 Mar 2015 18:27:33 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=4.1</generator>
	<item>
		<title>By: Brian S Hall</title>
		<link>http://research.gigaom.com/2010/02/google-buzzs-true-home-is-in-the-enterprise/#comment-737</link>
		<dc:creator><![CDATA[Brian S Hall]]></dc:creator>
		<pubDate>Thu, 11 Feb 2010 02:11:12 +0000</pubDate>
		<guid isPermaLink="false">http://pro.gigaom.com/?p=25186#comment-737</guid>
		<description><![CDATA[Really good analysis. I think very highly of most Google products but Buzz has been a surprising letdown. Not only is the learning curve unnecessarily high (though not terrible), but it violates some cardinal rules, among them: just because I gmail you (and I gmail everybody) doesn&#039;t mean I want to be your friend in any way.

However, ^^^within the enterprise or amongst a select user group/mailing list, it could be powerful, creating a giant ecosystem by creating hundreds of thousands of tiny ecosystems.^^^]]></description>
		<content:encoded><![CDATA[<p>Really good analysis. I think very highly of most Google products but Buzz has been a surprising letdown. Not only is the learning curve unnecessarily high (though not terrible), but it violates some cardinal rules, among them: just because I gmail you (and I gmail everybody) doesn&#8217;t mean I want to be your friend in any way.</p>
<p>However, ^^^within the enterprise or amongst a select user group/mailing list, it could be powerful, creating a giant ecosystem by creating hundreds of thousands of tiny ecosystems.^^^</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mathew</title>
		<link>http://research.gigaom.com/2010/02/google-buzzs-true-home-is-in-the-enterprise/#comment-736</link>
		<dc:creator><![CDATA[Mathew]]></dc:creator>
		<pubDate>Wed, 10 Feb 2010 17:00:27 +0000</pubDate>
		<guid isPermaLink="false">http://pro.gigaom.com/?p=25186#comment-736</guid>
		<description><![CDATA[Thanks for the comment, Rick.  I think a Google behind-the-firewall appliance that offered Google Apps would be a great idea.  One of Google&#039;s weaknesses is that it doesn&#039;t think as much about the corporate market -- or at least doesn&#039;t do as good a job of targeting that market -- as it probably should.]]></description>
		<content:encoded><![CDATA[<p>Thanks for the comment, Rick.  I think a Google behind-the-firewall appliance that offered Google Apps would be a great idea.  One of Google&#8217;s weaknesses is that it doesn&#8217;t think as much about the corporate market &#8212; or at least doesn&#8217;t do as good a job of targeting that market &#8212; as it probably should.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rickbullotta</title>
		<link>http://research.gigaom.com/2010/02/google-buzzs-true-home-is-in-the-enterprise/#comment-735</link>
		<dc:creator><![CDATA[rickbullotta]]></dc:creator>
		<pubDate>Wed, 10 Feb 2010 14:35:25 +0000</pubDate>
		<guid isPermaLink="false">http://pro.gigaom.com/?p=25186#comment-735</guid>
		<description><![CDATA[So I guess that begs the question, what defines a &quot;private collaboration tool&quot; and an &quot;enterprise version&quot;.  No doubt there&#039;s a clear fit for companies who have committed to and are comfortable with an external cloud/hosted solution.  However, there are a number of very legitimate reasons for this functionality to be accessible behind the firewall in a local private cloud.  

To date, Google has not offered any solutions except search (GSA) for deployment behind the firewall.  Personally, I think a Google Apps appliance would a huge seller.  It could still be configured to &quot;self-update&quot; or IT-monitored updates, but would physically live inside the corporate firewall.  At Google IO last year, I probed a number of people on the Google Apps team as to why they don&#039;t offer an appliance, only to be met with blank stares...

FYI, the reasons for a behind-the-firewall solution are many.  

1) Security.  There are a great many situations where people who need access to the applications are not physically connected to the internet or the risk of network compromise is too significant to permit it.  Great examples are those inside many manufacturing plants or power generation facilities.  For security and safety reasons, those networks tend to be isolated from the internet, but there are hundreds of millions of workers who could utilize things like Google Apps, Buzz, etc in these scenarios.

2) SLAs.  Today, the SLA&#039;s of many cloud-based app providers aren&#039;t always adequate, and there are often a lot of &quot;degrees of freedom&quot; in this equation that can lead to inconsistent performance and availability.

3) GRC considerations.  In many environments, such as the pharmaceutical industry, applications need to be validated to meet FDA requirements, and constant and unseen updates to application software are a big no-no in those cases.  Providing IT the ability to have some governance over the change management of the application software is a must.  Additionally, since more and more of these applications are being consumed via APIs as much as via their built-in UI&#039;s, stability of the APIs is also a key consideration so as not to break composite applications/mashups constructed from those services.

Your thoughts?]]></description>
		<content:encoded><![CDATA[<p>So I guess that begs the question, what defines a &#8220;private collaboration tool&#8221; and an &#8220;enterprise version&#8221;.  No doubt there&#8217;s a clear fit for companies who have committed to and are comfortable with an external cloud/hosted solution.  However, there are a number of very legitimate reasons for this functionality to be accessible behind the firewall in a local private cloud.  </p>
<p>To date, Google has not offered any solutions except search (GSA) for deployment behind the firewall.  Personally, I think a Google Apps appliance would a huge seller.  It could still be configured to &#8220;self-update&#8221; or IT-monitored updates, but would physically live inside the corporate firewall.  At Google IO last year, I probed a number of people on the Google Apps team as to why they don&#8217;t offer an appliance, only to be met with blank stares&#8230;</p>
<p>FYI, the reasons for a behind-the-firewall solution are many.  </p>
<p>1) Security.  There are a great many situations where people who need access to the applications are not physically connected to the internet or the risk of network compromise is too significant to permit it.  Great examples are those inside many manufacturing plants or power generation facilities.  For security and safety reasons, those networks tend to be isolated from the internet, but there are hundreds of millions of workers who could utilize things like Google Apps, Buzz, etc in these scenarios.</p>
<p>2) SLAs.  Today, the SLA&#8217;s of many cloud-based app providers aren&#8217;t always adequate, and there are often a lot of &#8220;degrees of freedom&#8221; in this equation that can lead to inconsistent performance and availability.</p>
<p>3) GRC considerations.  In many environments, such as the pharmaceutical industry, applications need to be validated to meet FDA requirements, and constant and unseen updates to application software are a big no-no in those cases.  Providing IT the ability to have some governance over the change management of the application software is a must.  Additionally, since more and more of these applications are being consumed via APIs as much as via their built-in UI&#8217;s, stability of the APIs is also a key consideration so as not to break composite applications/mashups constructed from those services.</p>
<p>Your thoughts?</p>
]]></content:encoded>
	</item>
</channel>
</rss>