Hawaii Needs a Cabinet Level CTO & Google Apps

Comment

Comment by Cliff Frost on February 13, 2010 at 1:37pm

Um, before rushing out to sign petitions, it might be worth asking folks involved what efforts they've made in the outsourcing direction. I don't know much, if anything, about what the state has been doing, or DOE, but I'm intimately familiar with what UH is doing. I work at UH, and have responsibility for email, and we certainly aren't ignoring the issue. I personally think it likely that UH will end up using gmail and google apps (and I support this direction), but the decision is non-trivial and requires a lot of consultation and care.

I can believe there are some IT folks who have knee-jerk reactions against anything that might threaten their comfy life, but I haven't met very many of them. My experience is that most of us take our responsibilities seriously, and are keenly aware of the financial component of that responsibility.

My major concern for years about gmail for universities has been about privacy and protection of intellectual property (closely related concerns with email and apps). Until very recently (like within a month), google absolutely insisted on three things:

1) Google will follow the law of any country it does business in; (duh),
2) Google will not guarantee that customer data repositories will remain in the United States;
3) Google will not disclose which countries the email data does reside in.

So if the legal authorities in some random country wanted to spy on the activity of a UH student or faculty member they could potentially do it--legally!--without anyone at UH knowing. That activity could be political dissent, or research activity, or whatever. Does anyone think those are trivial concerns?

If you look at the city of LA's contract with Google, it does indeed require the email data store be housed in the US, but not Google App data. I don't know what terms DC got.

Until the recent spat between Google and China, the UH and other universities were getting stonewalled by Google on those contract terms. In the last couple of weeks Google is being more open to our concerns.

However, if any of you have followed the recent controversy about Google's new "Buzz" product and its introduction, you may understand why reasonable people might not trust Google's commitment to protecting its users' privacy. The way Google rolled out Buzz shocked the heck out of me and makes me seriously worry about entrusting the company with anything remotely sensitive. (If you don't know, Google set up Buzz on gmail users as an "opt-out" service and made it very hard to actually opt out. Buzz exposes your email contacts to other of your email contacts, a privacy violation so severe Google had to know what they were doing and did it anyway. Here's a link that you can follow for more info if you want:

http://techcrunch.com/2010/02/12/google-buzz-privacy/

I'm happy to discuss this gmail/outsource topic at length. I've been a techie in higher ed IT for almost 30 years, and managing IT for around 15. I've out-sourced, in-sourced, and everything in between. It's fun work for sure.

Maybe a live Tech Hui gathering would be appropriate. There might be people from the state and DOE who would be willing to discuss the issues. I'd be happy to participate.

Comment by Joel M. Leo on February 13, 2010 at 12:25pm

There's an interesting (and lengthy) discussion of Yale's switch to google mail/apps over at slashdot: http://news.slashdot.org/article.pl?sid=10/02/13/0556252

Here are a few links on Yale's news site describing the switchover and some of the concerns

http://www.yaledailynews.com/news/university-news/2010/02/09/google...
http://www.yaledailynews.com/opinion/guest-columns/2010/02/11/csar-...

Comment by JW Guillaume on February 13, 2010 at 10:36am

Seth Ladd: Let me know what petition to sign or who to call. Basically... now what?

I hope this idea leaks out not only to the State of Hawaii DOE but to the students themselves. They can then learn what is being done, what could be done, and pros and cons of each side. If these ideas have merit, who better to serve as advocates to improve our IT services in our DOE. If nothing comes of it they will at least have a lot better understanding of how our tax dollars are spent and how technology is constantly transforming.

Comment by Mika Leuck on February 13, 2010 at 8:24am

Hi Amy - When you use Google Apps for a domain the domain administrator can enforce use of SSL by going to Manage this Domain > Domain Settings > Automatically enforce Secure Socket Layer (SSL) connections when your users access Gmail, Calendar, Docs, and Sites.

If you are on a domain with this setting and your mobile device's calendar app doesn't work with SSL you can use the mobile web UI.

Comment by Daniel Leuck on February 12, 2010 at 9:33pm

Laurence A. Lee: Until and unless SSL-Encrypted sessions or IP Tunnels are commonplace and mandatory, I often advise against Cloud Computing.

All Google Apps (mail, calendar, etc.) default to https. I suppose a state worker could manually type an http address, although I'm not sure what would compel them to do so. If the state agreed to make the move I'm sure Google would be more than happy to turn off http access for the Hawaii gov domains.

Remember, Los Angeles, a city with almost three times the population of our state, has already addressed all these issues. I'm sure they would be more than happy to share the details of their agreement with Google.

And you know they'd never changed default passwords, nor default SSIDs from LINKSYS or NETGEAR, so the encryption hash is available in pre-computed Rainbow Tables.

I agree, but that is an issue of password policy enforcement that is completely orthogonal to the question of SaaS vs. on-site hosting of email and calendaring services. Their current in-house systems are equally susceptible to such problems. That is why we need a state CTO to set the necessary policies and establish the systems and processes required to enforce those policies.

Furthermore, you're sorely restricted by Bandwidth capacity. Why store Terabytes' worth of OLTP data in a Cloud Repository, unless you've also got the foresight to drop your OLAP Cube or Search Appliance right next to it?

We are talking about email, calendaring and some aspects of document management. OLTP can stay local until bandwidth improves to the point where the discussion becomes academic. It doesn't need to be all or nothing.

IMHO, Google Apps/Docs just isn't feature-rich enough to cut it yet. Why throw the State into GoogleMail/Docs/Apps, only to find that they'd eventually grow to add, say, BaseCamp in half a year?

They could just as easily use a Google App integrated project management solution such as ManyMoon. If they want to use other apps that aren't integrated thats fine. The sky won't fall. That is no different than what they do today at a higher cost with lower reliability.

Cloud Computing is no panacea -- not yet, anyway. The problem with many Cloud-Computing SaaS Providers is they focus on the pretty Web 2.0 Front-Ends, and the integration APIs are secondary.

I'm not saying its a panacea. I am saying its much better than what we currently have, and it will save us a lot of money. Over two million businesses and a city with three times the population of our state reached the same conclusion. There is really no reason for us to start from scratch in evaluating the same things they have explored in excruciating detail. The proof is in the pudding. Larger organizations are using it and it works. Organizations in our own state use it and it works. If it works for Punahou, why not the DoE?

Clouds are great for standalone SaaS applications and toys, but there either needs to be a lot more emphasis on rich backend APIs so small SaaS verticals can complement each other.

Google Apps provides a rich API that is used by a rapidly expanding base of hundreds of third party solution providers. LA and the District of Columbia didn't think it was a toy. Neither should we.

Comment by Laurence A. Lee on February 12, 2010 at 6:51pm

Until and unless SSL-Encrypted sessions or IP Tunnels are commonplace and mandatory, I often advise against Cloud Computing.

Do you *really* want a State Employee to pull up a Google Document containing your personal information, knowing that it's going across the wire in Plain-Text a la HTTP? That's just wayyyy too easy for a Script Kiddie to jack into a Hub or Switch on the hard line; or (more likely) use a WiFi Sniffer because someone just *HAD* to have wireless access for their Laptop or iPhone, and Corporate (State) IT won't do that for them. And you know they'd never changed default passwords, nor default SSIDs from LINKSYS or NETGEAR, so the encryption hash is available in pre-computed Rainbow Tables.

Furthermore, you're sorely restricted by Bandwidth capacity. Why store Terabytes' worth of OLTP data in a Cloud Repository, unless you've also got the foresight to drop your OLAP Cube or Search Appliance right next to it? 'No sense have an in-house Cognos Server, for example, if it's going to end up drawing large volumes of data through a tiny WAN-connection straw.

Lots of shops I consult with *LOVE* the End-User friendliness of Cognos Reporting; and there are very few SaaS-friendly options that can match it.

SQL Data-Intensive Business Intelligence reports, and Workflow Management Systems, reign supreme in large organizations. IMHO, Google Apps/Docs just isn't feature-rich enough to cut it yet. Why throw the State into GoogleMail/Docs/Apps, only to find that they'd eventually grow to add, say, BaseCamp in half a year? Once that rat's nest is in place, you've got bigger problems trying to keep things synchronized between the two repositories. Say you add a reference to a Google Document in a BaseCamp Project, for example. When that document is updated, how is BaseCamp to be notified of the change, and how are the BaseCamp Project Members to be notified?

Cloud Computing is no panacea -- not yet, anyway. The problem with many Cloud-Computing SaaS Providers is they focus on the pretty Web 2.0 Front-Ends, and the integration APIs are secondary.

Clouds are great for standalone SaaS applications and toys, but there either needs to be a lot more emphasis on rich backend APIs so small SaaS verticals can complement each other, or a small SaaS provider needs to step up and buy the others out to make an integrated Suite -- much like how Microsoft and Corel did 20 years ago to create the first Office Suites.

Comment by Daniel Leuck on February 12, 2010 at 3:47pm

Hi Joel - To your points below:

1. Privacy. This is easily rectified with a legal agreement similar to the one they signed with Los Angeles. Even if you don't buy their "Don't be evil" mantra they are a $170B company and they don't want to be sued.
2. Availability. See the chart above. They have better availability than all the on-premise options. Also, as Seth mentioned, you can use Gears or Chrome offline.
3. Security. If you've ever visited a Google data center you know that nothing in our state compares to their physical, network or application level security.

Comment by Seth Ladd on February 12, 2010 at 3:21pm

Working offline is not an issue... Google Docs supports offline access via Gears or Chrome. And frankly, I trust Google's security as much or more as anyone's. Everyone/thing is fallible, but they are trying as hard or harder than anyone I know. Certainly, transparency will help here.

Remember... the move to cloud computing is inevitable. The economics will force this. We've been through this sort of transition before. When electricity first came onto the machine, most industrial factories had their own power plant!! This is just like how most major organizations have their own IT department.

Think of how absurd it would be if the State of Hawaii ran their own power grid. Now, in 10 years, it will be absurd when an organizations runs its own servers.

Comment by Wendi Kamiya on February 12, 2010 at 3:09pm

David, Dan - thanks. The discussion was enjoyable, and I always hope useful, even if just a little.

The issue of security was brought up and discussed at AITP, and it is one that I think each organization needs to determine what the risk tolerance is, along with the honest assessment of their current security situation.

Comment by Daniel Leuck on February 12, 2010 at 2:46pm

Ken - Exactly. Seth - I just wrote a few tech-savvy legislators about it. A petition is also a good idea. We'll get one started shortly.

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page