<?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: Redesigning a corporate web environment</title>
	<atom:link href="http://twoseven.co.nz/2009/07/14/redesigning-a-corporate-web-environment/feed/" rel="self" type="application/rss+xml" />
	<link>http://twoseven.co.nz/2009/07/14/redesigning-a-corporate-web-environment/</link>
	<description>...is Dan Willis blogging about web design and development, usability, standards and pretty much anything!</description>
	<lastBuildDate>Sun, 20 May 2012 13:53:42 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4-alpha-20339</generator>
	<item>
		<title>By: Lance</title>
		<link>http://twoseven.co.nz/2009/07/14/redesigning-a-corporate-web-environment/comment-page-1/#comment-37983</link>
		<dc:creator>Lance</dc:creator>
		<pubDate>Tue, 28 Jul 2009 02:10:51 +0000</pubDate>
		<guid isPermaLink="false">http://twoseven.co.nz/?p=169#comment-37983</guid>
		<description>I agree with Harry - the technology is the easy bit, and the corporate culture is the much harder piece for your friend to crack.

My advice to him would be to start small, and get one sweet website or application launched and quickly. You may need to get a small external shop to help you, or carve out a small team within your team.  Don&#039;t tell anyone you are doing it - but just get it done and present the result when all you need to do is hit the deploy button. Then do the next one.

Find someone in marketing that you trust, get stealthy support from other parts of the organisation - the twitterers, key operations folk and a heavy hitter or two to provide air cover.  Build a groundswell of support for a series of new sites - but most of all make sure he continues to deploy new stuff regularly. Your friend&#039;s customers are no doubt wildly frustrated with his company&#039;s antiquated crap of a website, and they can&#039;t wait to see any sort of change.</description>
		<content:encoded><![CDATA[<p>I agree with Harry &#8211; the technology is the easy bit, and the corporate culture is the much harder piece for your friend to crack.</p>
<p>My advice to him would be to start small, and get one sweet website or application launched and quickly. You may need to get a small external shop to help you, or carve out a small team within your team.  Don&#8217;t tell anyone you are doing it &#8211; but just get it done and present the result when all you need to do is hit the deploy button. Then do the next one.</p>
<p>Find someone in marketing that you trust, get stealthy support from other parts of the organisation &#8211; the twitterers, key operations folk and a heavy hitter or two to provide air cover.  Build a groundswell of support for a series of new sites &#8211; but most of all make sure he continues to deploy new stuff regularly. Your friend&#8217;s customers are no doubt wildly frustrated with his company&#8217;s antiquated crap of a website, and they can&#8217;t wait to see any sort of change.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Harry Fuecks</title>
		<link>http://twoseven.co.nz/2009/07/14/redesigning-a-corporate-web-environment/comment-page-1/#comment-37597</link>
		<dc:creator>Harry Fuecks</dc:creator>
		<pubDate>Fri, 17 Jul 2009 21:38:18 +0000</pubDate>
		<guid isPermaLink="false">http://twoseven.co.nz/?p=169#comment-37597</guid>
		<description>To me the most telling part is here;

&gt; Changing anything significant requires implementation of an expensive one-off SDLC waterfall-type project with a business case, requirements-gathering, PM, BA, dedicated test-resource – the whole box and dice. These projects often under-deliver, with scope being reduced en route to avoid budget and deadline blowout.

...followed by...

&gt; Source repository. (He doesn’t have one at the moment). svn or git? Stable trunk policy?

IMO geeks often tend to see things in terms of implementation detail and all the great things that are possible with technology choices, ignoring facts staring them in the face.

In a corporate culture that doesn&#039;t even get the point of having version control, there&#039;s absolutely no chance of pulling off a project as ambitious as this from the inside. Trying will just lead to frustration and bitterness for your friend - better put that energy into further education, like a part-time Masters or similar.

Only way I could see a project like that having any chance of succeeding would be externally, with some small, specialised agency packing clever project managers.

But may be that&#039;s just me ;)</description>
		<content:encoded><![CDATA[<p>To me the most telling part is here;</p>
<p>&gt; Changing anything significant requires implementation of an expensive one-off SDLC waterfall-type project with a business case, requirements-gathering, PM, BA, dedicated test-resource – the whole box and dice. These projects often under-deliver, with scope being reduced en route to avoid budget and deadline blowout.</p>
<p>&#8230;followed by&#8230;</p>
<p>&gt; Source repository. (He doesn’t have one at the moment). svn or git? Stable trunk policy?</p>
<p>IMO geeks often tend to see things in terms of implementation detail and all the great things that are possible with technology choices, ignoring facts staring them in the face.</p>
<p>In a corporate culture that doesn&#8217;t even get the point of having version control, there&#8217;s absolutely no chance of pulling off a project as ambitious as this from the inside. Trying will just lead to frustration and bitterness for your friend &#8211; better put that energy into further education, like a part-time Masters or similar.</p>
<p>Only way I could see a project like that having any chance of succeeding would be externally, with some small, specialised agency packing clever project managers.</p>
<p>But may be that&#8217;s just me <img src='http://twoseven.co.nz/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Coup</title>
		<link>http://twoseven.co.nz/2009/07/14/redesigning-a-corporate-web-environment/comment-page-1/#comment-37460</link>
		<dc:creator>Rob Coup</dc:creator>
		<pubDate>Wed, 15 Jul 2009 03:22:18 +0000</pubDate>
		<guid isPermaLink="false">http://twoseven.co.nz/?p=169#comment-37460</guid>
		<description>+1 around continuous integration and automating testing and deployment. As your software moves from a monolithic beast into separate distributed components (eg. web services, frontends, CMS, ...) its almost essential to have tools to manage all this. 

Capistrano is a simple deployment tool (and totally works without rails) and cruisecontrol.rb is pretty simple for continuous builds/testing.

CouchDB is awesome for some applications, but I wouldn&#039;t use it just for it&#039;s own sake. You&#039;ll know when your DB schema becomes a nightmare that the time could be right :)

Feel free to get in touch if he wants help with web services or operations-related stuff.</description>
		<content:encoded><![CDATA[<p>+1 around continuous integration and automating testing and deployment. As your software moves from a monolithic beast into separate distributed components (eg. web services, frontends, CMS, &#8230;) its almost essential to have tools to manage all this. </p>
<p>Capistrano is a simple deployment tool (and totally works without rails) and cruisecontrol.rb is pretty simple for continuous builds/testing.</p>
<p>CouchDB is awesome for some applications, but I wouldn&#8217;t use it just for it&#8217;s own sake. You&#8217;ll know when your DB schema becomes a nightmare that the time could be right <img src='http://twoseven.co.nz/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>Feel free to get in touch if he wants help with web services or operations-related stuff.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: microsite</title>
		<link>http://twoseven.co.nz/2009/07/14/redesigning-a-corporate-web-environment/comment-page-1/#comment-37456</link>
		<dc:creator>microsite</dc:creator>
		<pubDate>Wed, 15 Jul 2009 01:18:15 +0000</pubDate>
		<guid isPermaLink="false">http://twoseven.co.nz/?p=169#comment-37456</guid>
		<description>Hi

There is a really good open source tool called &#039;Word Press&#039;

It&#039;s mostly used as a blogging platform, but it can be used as a full blown CMS

Good luck to your friend.</description>
		<content:encoded><![CDATA[<p>Hi</p>
<p>There is a really good open source tool called &#8216;Word Press&#8217;</p>
<p>It&#8217;s mostly used as a blogging platform, but it can be used as a full blown CMS</p>
<p>Good luck to your friend.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Glen Barnes</title>
		<link>http://twoseven.co.nz/2009/07/14/redesigning-a-corporate-web-environment/comment-page-1/#comment-37450</link>
		<dc:creator>Glen Barnes</dc:creator>
		<pubDate>Tue, 14 Jul 2009 22:34:41 +0000</pubDate>
		<guid isPermaLink="false">http://twoseven.co.nz/?p=169#comment-37450</guid>
		<description>Git all the way - It just seems to make sense more than SVN. Also GitHub is a great place to store your repositories if corporate IT is being a little slow in getting things set up for you.

Also look at automated deployment. Deployment shouldn&#039;t be a manual process - It should be a single command for most deployments. You may have DB chanegs, etc. that may require extra steps but most deployments should check out of a Git branch and run any pre and post deployment scripts (I use Capistrano but there are others). If you automate this step you should be able to push changes several times a day if needed.</description>
		<content:encoded><![CDATA[<p>Git all the way &#8211; It just seems to make sense more than SVN. Also GitHub is a great place to store your repositories if corporate IT is being a little slow in getting things set up for you.</p>
<p>Also look at automated deployment. Deployment shouldn&#8217;t be a manual process &#8211; It should be a single command for most deployments. You may have DB chanegs, etc. that may require extra steps but most deployments should check out of a Git branch and run any pre and post deployment scripts (I use Capistrano but there are others). If you automate this step you should be able to push changes several times a day if needed.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

