Cloud Computing and NYS Government

256px-Cloud_computing_icon.svg_Cheers to Assemblymembers Steve Englebright, Andrew Hevesi and Brian Kavanagh for convening the October 17 roundtable on cloud computing. The event was extremely timely, and very welcome.  It was great to see three important Assembly committee chairman delving into the implications and key issues surrounding cloud computing. In 2013, New York State took the plunge into cloud based services in a big way. Earlier this year, the state adopted Microsoft Office 365, cloud based email and desktop applications, for the entire state workforce. The state also is also using Socrata’s cloud based platform and data hosting for the state’s open data site, data.ny.gov. Additionally, the state senate is using Amazon Cloud and Microsoft’s Azure for applications and data hosting. A variety of other state agencies, including DOH have small cloud initiatives.

The small, invite only, forum at the Assembly’s Manhattan hearing room brought together about a dozen cloud technology vendors, including major firms like Microsoft, IBM,  Amazon and AT&T, and a number of other technology consultants and lobbyists, as well as Reinvent Albany and Common Cause NY.  At future forums we hope to see representatives from the vibrant NYC tech start-up community. Unlike the assembly’s previous technology roundtables, there were no state agencies or representatives from the governor’s office.  They would have added hugely to the discussion.

Despite their absence, participants illuminated many of the key issues surrounding cloud computing and the challenges to government poised by rapid change to technology. Looming over the entire discussion was the consensus that New York’s technology procurement overall, including cloud services,  is badly broken.  Current procurement practices discourage tech start-ups and result in vastly inflated costs, and slow uptake of innovation. One participant summed the procurement system as encouraging “Good procurements and bad business outcomes.” Translation: a tech project may come in on-time and on-budget, but it may also be four times more expensive than it should be, and use the wrong technology. Participants also overwhelmingly agreed that cloud hosting and services are functionally as secure as traditional internally hosted data s

Interesting Roundtable Comments

  • Does cloud computing create a new budgeting challenge because it shifts technology purchasing from capital budgets, which are based on borrowing and don’t impact agency budgets, to immediate operating budgets? In other words, buying Office 365 as an on-demand software service or hosting open data on Socrata, are paid for with operating funds. Whereas, traditionally, the state has purchased hardware on run applications and hosted data on its own servers. So, while the state might save significant amounts using flexible cloud based offerings, it’s operating costs may go up in the short term because those costs are being shifted into the operating budget.
  • Implementing enterprise wide, cloud based email and desktop helps promote faster adoption of cloud apps/ mobile services because it forces adoption of an enterprise wide, employee access management system. In other words, for the first time all state workers have a validated username and PIN to access everything that can be served up online. Big start towards getting control of mobile and Bring Your Own Device.
  • Federal cloud guidelines  for data security and classification are a good place to start. Probably too restrictive for states.
  • Mobile devices are by far the biggest emerging security risk.
  • Because of procurement rules that make purchasing cloud services extremely difficult, local government employees all over the U.S. are engaging in “rogue solutions” like using their own Google Drive or Dropbox to share data with colleagues. This has created a serious security hole.
  • It took one state agency a year to “procure” Github.

Many high profile issues went unaddressed, including: comparative cost of cloud solutions to traditional internal server based systems; internal cloud versus external cloud; benefits of developers of working in cloud environment; impact on state technology workers – especially the operations people keeping state servers going; true total cost of ownership of various models; best practices — very few were mentioned; trends in various segments of cloud based offerings.

 

Legislation Should Release Data, not Produce Maps

The following is re-posted from OpenSourcePlanning.org, and is written by Frank Hebbert of OpenPlans.

* * *

Hey, legislators! Don’t write laws that require maps (especially those that detail how the map information will be aggregated).

Instead, write laws to open up data. The maps will come. Much easier. Shorter, future-proofed laws. 

If you feel strongly about this, go testify. @transalt will be there, and other open data smarties.

This time, the law under discussion is about crash data in NYC, but the same unfortunate approach already made it into law for crime data. Interactive maps are an excellent tool to making complex data public, but requirements for a city agency to produce the map is not the right approach. Why not?

  1. We need tools that answer questions and solve problems, and doing that well requires you to start with those needs, rather than building a generic map.
  2. The track record of government-built maps is not great, maybe because of #1, or the tools they have, or because of internal development practices that don’t involve users, or something else. For example, the SLA liquor license map.
  3. The track record of researchers and technologists and journalists to build data browsing tools is excellent. For example, excellent crime analysisinsightful 311 analysiseverything WNYC doesVizzuality’s output etc.
  4. There are complex tech problems that talented government technologists should work on. Making an interactive map isn’t one of them.
  5. Legislation that is extremely specific seems brittle and prone to letter-of-the-law following later. Especially if a city department decided to be uncooperative in the future. Whereas full disaggregated data is flexible. We already have guidelines for opening up data “right”, no need to re-design this for each different type of data. Getting particular about mapping requirements is the worst sort of over-specifying. For crashes, maybe the aggregation by street segment prevents analysis of intersection safety (for example).