<?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: Who is going to build new public services?</title>
	<atom:link href="http://publicstrategist.com/2010/02/who-is-going-to-build-new-public-services/feed/" rel="self" type="application/rss+xml" />
	<link>http://publicstrategist.com/2010/02/who-is-going-to-build-new-public-services/</link>
	<description>Working to make government work better</description>
	<lastBuildDate>Fri, 17 Feb 2012 13:35:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Peter Jordan</title>
		<link>http://publicstrategist.com/2010/02/who-is-going-to-build-new-public-services/comment-page-1/#comment-2223</link>
		<dc:creator>Peter Jordan</dc:creator>
		<pubDate>Sun, 21 Mar 2010 21:34:22 +0000</pubDate>
		<guid isPermaLink="false">http://publicstrategist.com/?p=1132#comment-2223</guid>
		<description>A very useful synthesis of the challenges ahead in using public data and semantic technologies to deliver robust and critical systems for government - managing the &#039;enterprise data of government&#039;.

Isn&#039;t it about moving from (or at least balancing) enterprise design with flexible progression and demonstrating the value of allowing more powerful aggregations of data?

Some steps forward:
- persistent and uniform URIs
- capture provenance
- focus first on de facto local standards to do what you need to do
- Should build trust and encourage reuse</description>
		<content:encoded><![CDATA[<p>A very useful synthesis of the challenges ahead in using public data and semantic technologies to deliver robust and critical systems for government &#8211; managing the &#8216;enterprise data of government&#8217;.</p>
<p>Isn&#8217;t it about moving from (or at least balancing) enterprise design with flexible progression and demonstrating the value of allowing more powerful aggregations of data?</p>
<p>Some steps forward:<br />
- persistent and uniform URIs<br />
- capture provenance<br />
- focus first on de facto local standards to do what you need to do<br />
- Should build trust and encourage reuse</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steph Gray</title>
		<link>http://publicstrategist.com/2010/02/who-is-going-to-build-new-public-services/comment-page-1/#comment-2218</link>
		<dc:creator>Steph Gray</dc:creator>
		<pubDate>Sun, 21 Mar 2010 20:49:35 +0000</pubDate>
		<guid isPermaLink="false">http://publicstrategist.com/?p=1132#comment-2218</guid>
		<description>Some great thoughts there - and reading between the lines of your conclusion, perhaps you have some optimism for the future?

I&#039;m not so sure, based on what we&#039;ve seen so far. There is an enormous gulf still - and for the foreseeable future - between the creative ideas and talent on the outside for front-end innovation using open data and APIs, and the reality of service delivery programme management, procurement and technical vision on the inside. 

Brian&#039;s conclusion - that the same people building services now will continue to do so, using the newly open data, strikes me as only half likely: what if the same people just keep building in the usual ways, and ignore the RDFa and CSVs being unearthed? After all, what incentives are there for them or the people commissioning them to do anything else? The incentives the other way are still relatively strong (system security, prima facie efficiency, data integrity etc)

I&#039;m interested in at least a couple of angles to this:

- how can the procurement of transactional public services online be managed in ways which bake in support for outside innovation and potentially, for outside delivery lock, stock and barrel? Can we make APIs, permissive licences, modular technology choices, open source consideration etc mandatory? And can we procure things in ways which the denizens of Rewired State can help to deliver? I&#039;m conscious there&#039;s a risk of celebrating their talent, passion and ideas at hack days but not doing anything much which would translate that into meaningful change in how services get delivered online.

- who owns these transactions, in terms of small-p politics? This one is perhaps the most crucial of all - if accountability and delivery are spread across multiple teams, organisations and platforms, we&#039;re surely destined to fail to deliver programmes with the necessary customer focus and efficient project management methodologies. Can we be more radical than previous attempts have been to establish &#039;customer champions&#039; in government that have real teeth? Of course, I&#039;m not saying that distributed, decentralised teams can&#039;t work - just look at most open source projects - but that in delivering transactional services, people need to acknowledge shared ownership where it exists and have some process for governing it.</description>
		<content:encoded><![CDATA[<p>Some great thoughts there &#8211; and reading between the lines of your conclusion, perhaps you have some optimism for the future?</p>
<p>I&#8217;m not so sure, based on what we&#8217;ve seen so far. There is an enormous gulf still &#8211; and for the foreseeable future &#8211; between the creative ideas and talent on the outside for front-end innovation using open data and APIs, and the reality of service delivery programme management, procurement and technical vision on the inside. </p>
<p>Brian&#8217;s conclusion &#8211; that the same people building services now will continue to do so, using the newly open data, strikes me as only half likely: what if the same people just keep building in the usual ways, and ignore the RDFa and CSVs being unearthed? After all, what incentives are there for them or the people commissioning them to do anything else? The incentives the other way are still relatively strong (system security, prima facie efficiency, data integrity etc)</p>
<p>I&#8217;m interested in at least a couple of angles to this:</p>
<p>- how can the procurement of transactional public services online be managed in ways which bake in support for outside innovation and potentially, for outside delivery lock, stock and barrel? Can we make APIs, permissive licences, modular technology choices, open source consideration etc mandatory? And can we procure things in ways which the denizens of Rewired State can help to deliver? I&#8217;m conscious there&#8217;s a risk of celebrating their talent, passion and ideas at hack days but not doing anything much which would translate that into meaningful change in how services get delivered online.</p>
<p>- who owns these transactions, in terms of small-p politics? This one is perhaps the most crucial of all &#8211; if accountability and delivery are spread across multiple teams, organisations and platforms, we&#8217;re surely destined to fail to deliver programmes with the necessary customer focus and efficient project management methodologies. Can we be more radical than previous attempts have been to establish &#8216;customer champions&#8217; in government that have real teeth? Of course, I&#8217;m not saying that distributed, decentralised teams can&#8217;t work &#8211; just look at most open source projects &#8211; but that in delivering transactional services, people need to acknowledge shared ownership where it exists and have some process for governing it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Carney</title>
		<link>http://publicstrategist.com/2010/02/who-is-going-to-build-new-public-services/comment-page-1/#comment-1879</link>
		<dc:creator>Paul Carney</dc:creator>
		<pubDate>Fri, 26 Feb 2010 14:54:15 +0000</pubDate>
		<guid isPermaLink="false">http://publicstrategist.com/?p=1132#comment-1879</guid>
		<description>Great comments on how to manage the floodgate of information. I strongly believe that when you combine social networking with an easy way to manipulate the data in one place, we will see groups of individuals emerge from all areas who will become the ones that people follow.

Experts are not necessarily the ones who look for new insight from this data. But people who have borderline interests in a topic will find other related information and create new data sets of real information. That is why our work on the Appeta platform is going to change the way we look at data and who gets to play with it.</description>
		<content:encoded><![CDATA[<p>Great comments on how to manage the floodgate of information. I strongly believe that when you combine social networking with an easy way to manipulate the data in one place, we will see groups of individuals emerge from all areas who will become the ones that people follow.</p>
<p>Experts are not necessarily the ones who look for new insight from this data. But people who have borderline interests in a topic will find other related information and create new data sets of real information. That is why our work on the Appeta platform is going to change the way we look at data and who gets to play with it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Four short links: 26 February 2010 &#171; Murder Manual</title>
		<link>http://publicstrategist.com/2010/02/who-is-going-to-build-new-public-services/comment-page-1/#comment-1875</link>
		<dc:creator>Four short links: 26 February 2010 &#171; Murder Manual</dc:creator>
		<pubDate>Fri, 26 Feb 2010 11:27:39 +0000</pubDate>
		<guid isPermaLink="false">http://publicstrategist.com/?p=1132#comment-1875</guid>
		<description>[...] Who Is Going To Build The New Public Services? &#8212; a thoughtful exploration of the possibilities and challenges of third parties building public software systems. There&#8217;s a lot of talk of &#8220;just put up the data and we&#8217;ll build the apps&#8221; but I think this is a more substantial consideration of which apps can be built by whom. [...]</description>
		<content:encoded><![CDATA[<p>[...] Who Is Going To Build The New Public Services? &#8212; a thoughtful exploration of the possibilities and challenges of third parties building public software systems. There&#8217;s a lot of talk of &#8220;just put up the data and we&#8217;ll build the apps&#8221; but I think this is a more substantial consideration of which apps can be built by whom. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

