Inspired by a big screen set up in the Google reception area over in Victoria, here's a fly-by view of the Global office network for which my team and I provide services.

Google Earth does continue to become a more and more amazing product...

Load up the KMZ file into Earth, and select the folder, and click play....

Yesterday I wrote an article about how bandwidth requirements are getting ever greater. Today, for the first time, I ran over my monthly blog bandwidth allowance.

So that's over 100Mb of data transferred this month, all of it text (the images are hosted on Picasa). Of course, in this day and age, almost all of that will be machine-generated traffic, probably the bulk part the elaborate world of nonsense that is "Search Engine Optimisation". But for those of you who are real, flesh and blood people, thanks for reading!

This may sound like the bleedin' obvious to you, but in planning that we have begun to look at refreshing core network infrastructure at work, it is notable that the world seems to be heading for fatter, low-latency data, and that that proves a substantial challenge for corporate network design.

In the old days, the world was a combination of files of a relatively small size, and relatively low latency real time connections required for the delivery of usually client-server applications. These days, the challenges are far greater. We have, thanks to Moore's law, the ability to generate vast files that the edges of the network just can't handle (it's not uncommon for our creative staff to produce files in excess of 1Gbyte, which their opto-core processor workstations can do with relative ease). We are also seeing more moves towards real-time or streamed collaborative tools (from WebEx through to Wave) that require fair to middling data bandwidth, but with low latency on the network to make them coherent. And then there is the explosion of network traffic that is video.

This is a real headache for managing IT in a corporate environment. When connections to the outside world are still measured in tens of megabits, other than for the largest of organisations, shipping really big stuff slowly, or medium-big stuff much more quickly, is a big challenge. Even more so when the domestic broadband providers have a marketing war of words about how many megabits they can provide to us for £9.99 a month. For the end consumer in a business setting, why the corporate network can't support all of these applications that seem to run fine in the domestic environment is a technical complexity that makes little sense.

Now there's a article title to strike tedium into the hearts of good men...

...anyway, have been looking at refreshing the company's IT policy, especially in light of all the cloud stuff that is going on, and was pointed to Out-Law.com by a chap called Jon on the quite remarkable Aardvark service.

The material on the Out-Law site looks really good - comprehensive yet intelligible.

Reviewing it also has made me make a couple of tweaks to this site... In case of any doubt, these are all my views and may only co-incidentally reflect the views of employers past and present. And I've now popped a creative commons licence on it as well, if you were ever wanting to use my ramblings in any way...

A face in an article in the Observer business section got me thinking about how long this cloud stuff has been around.

Dan Wagner, Web 1.0 pioneer, founder of a successful fashion blogging empire, and the man behind ecommerce engine Venda. (Oh. And possessor of one of the worst bleached hairstyles I have ever seen in business. Thankfully, by the look of the Observer's portrait, now grown out).

Back in the post-dot-com-bubble-burst days of the early noughties, BBC Worldwide had a very expensive set of 'web properties' under the brand Beeb.com. It had been set up in the late 90s, with a flood of joint venture capital and lofty ambitions. However, it fell by the wayside as probably the only clear commercial victim of the BBC's public service web activities (another story for another day).

What was left when the decision was made to wind Beeb.com up were two content websites (Radio Times and Top Gear both successful enough to exist to this day), a dial-up ISP service (Beeb.net, a white-labelled ISP service whose days were numbered with the rise of broadband), and the bbcshop.com.

The JV to set up Beeb.com had been with a technology company, and as a net result part of the bbcshop legacy had been a lot of bespoke code, written expensively in Java, to provide so-so functionality. To the management team now running the commercial service, it became quickly apparent that this was a huge disadvantage to actually making any money, and alternative approaches were investigated.

The technology was the least of the venture's problems. With the rapid expansion (and associated buying power) of Amazon and other online businesses, it was nigh on impossible to provide products to end consumers at a price that was anywhere near competitive. This will remain with me as a salient reminder that just because you make it, doesn't mean that you can sell it efficiently to end consumers. BBC Worldwide was mostly a B2B operation, and scaling down to supply to the individual was problematic to say the least.

However, on the technology side, there appeared to be an answer- Dan Wagner's company Venda. I am not entirely sure what my views on the service were at the time (as you'll have read, my only clear recollection is of his terrible haircut), but I am fairly certain that at first I would have been pretty resistant. Here was a multi-tenanted, software as a service offering. Because of the former JV relationship, we were used to having complete control over everything. Where 'everything' was an increasing rotten set of code that simply didn't offer what end consumers wanted from an online shopping experience, and anything we wanted changing was expensive and slow.

The Venda model worked because there are comparatively few companies that need to provide differentiating technology to allow people to shop online. Nowadays, as well as the BBC, Venda provides the back end to dozens of major brands.

Interestingly, at the time all of the above was being implemented, another part of the sales organisation at Worldwide had done a deal with Amazon, to set up a BBC shop within the Amazon walls. The supply of technology was only part of the challange for the self-owned shop, and the Amazon deal neatly sidestepped all of the physical logistic, supply chain and customer service headaches that were also in evidence (something it appears is today causing issues for Google).

I'd love to know the comparative profitability for the two services to the BBC, but would bet heavily that the Amazon approach was both proportionately and cumulatively the better approach. When making suggestions about how technology should be provided to an organisation, maybe the first question should be "should we even be doing this activity ourselves"?

This morning saw about 450 people across the globe at Imagination Go Google. The project, which has been running since the beginning of September, has been a truly cross-business affair, involving a team of people spread from Sydney through to Los Angeles.

At the outset, the objectives were lofty. Accessible information distributed globally between team members which enables us to do the right things, at the right time, in the right place. The project has always been more than "just a new email system".

Our starting point was of a set of tools that had been designed for a different sort of company - a far less global organisation, operating primarily from one office. Today, Imagination has an office network that comprises 14 sites in nine countries and seven time zones. Open source email based around IMAP servers and the Thunderbird email client, Oracle Calendar for diary services, no consistent service for managing contacts, no instant messaging, and a hotch-potch of BlackBerry BIS and BES to allow limited access to some of the tools. All of this in an environment where about one-third of the user base are using MacOS, many people are regularly travelling away from the office, and where new offices spring up on a regular basis.

First step was to identify a primary project sponsor - in the end, the European Operations Director. Having the project led by a "business" person rather than an IT person was critical to successful adoption of a new platform. The second step was to pull together a cross-business team of people who would be able to make decisions on behalf of the company. That team involved people at all levels, from most of the offices, is a very global group. Use of tools to help facilitate the team (Webex, and Shareflow) was crucial to allow them to form, norm and perform.

The only technology stipulation that I made in my role in the team was that whatever service we went with had to be delivered as a pure, software-as-a-service proposition. The geographic, 24/7 of the company now is such that it just doesn't make sense to try to run core services in house. The project team pulled together the core business requirements for a new collaboration platform, and Microsoft, IBM Lotus and Google were invited to respond to a request for proposals. IBM are playing catch up, and unfortunately just didn't have a SaaS proposition that made sense for our operation.

The choice between Microsoft and Google may well have been closer if we didn't have such a reliance of MacOS. Apple still have market dominance in the creative industries, and Microsoft still tends to develop first for Windows, and then second for other platforms. It will be interesting to see if Steve Ballmer's recent commitments to the Cloud will see Microsoft starting to develop more even-handedly for multiple platforms.

However, the choice made to move to Google wasn't one made by default. It was the unanimous verdict of the project team that Google offered the best platform for our business. It is clear that the product set was developed with the Internet at the core, and felt to be the only product that really exploited the fact that it was delivered in a multi-tenanted environment. The pricing, whilst extremely attractive to the Group FD, was not a major influence in the decision making.

Once the decision was made, planning could begin. Unlike most of the projects that I have worked on in the past, the technology element of this was relatively light. No servers to build, no software to install, no integration of any great note. The main concerns were about migration of data into the new platform, and with IMAP and iCal standard to cover most of that, a relatively straightforward planning phase was completed.

Without fewer technology elements to worry about, the project has been able to focus on business change. Quite a lot of that business change, it has to be said, has been to help people come to terms with two features of Google Mail: conversation threading and message labelling. Both of these features are very different to what people have been used to in Thunderbird (or Outlook-like products). Both of these features also challenge people who spend hours each day fastidiously filing email into confronting a possible reality - that they are wasting their time. With extensive and fast search functionality, and reliable automatic labelling based on rules, the days of filing email may be numbered.

However, that last paragraph is from somebody who has never really seen the point of filing email, and I know that for the filers in our organisation, the labelling in Google is impacting quite fundamentally on their day-to-day working habits.

In planning for migration, a few assumptions were made early on. First of all, that everyone would need to migrate into the new diary system on the same day. Co-existence with Oracle Calendar wouldn't work, and one of the biggest bugbears of our former calendar product was that meeting invitations received from clients and suppliers using Outlook/Exchange or Notes/Domino sat stupidly in the Thunderbird inbox, whilst Oracle Calendar remained blind to them. The second assumption was that everyone's entire email history would need to be transferred into the new environment. That amounted to around 1TByte of data as a result of the previous platform having no individual user space quotas in a high-file-size industry. Finally, we decided to limit what was released to users from day one to email, calendar, chat and contacts management, leaving Google Docs and Google Sites to a second phase.

We adopted a phased pilot approach to deployment. The first group of users (the project team plus members of the Imagination IT team) migrated over to Google for everything bar calendar in December. They, intentionally, were given no training (although most had been exposed to the Google platform in one way or another earlier in the project). The results confirmed that we needed to think long and hard about the way in which we trained people.

Phase two of the pilot hit in January. This time with support and training, we brought another 50 people onto the product for email; between then and now, we also brought over a number of people who had extremely large mailboxes. The other significant group of users in the second pilot was those who have become "Google Guides" - local points of contact for departments, and trained up not only in the tools, but also in some techniques for how to coach and help others.

By the end of last week, there were over 100 people across the business using Google for email and contacts management. As of this morning, the figure is closer to 150, and we have just over two weeks of bringing in 20-30 people each day to complete the migration. That's hopefully enough to keep the overall disruption to the business to a minimum, but long enough that our support network doesn't get completely overwhelmed.

It will take some months for the new services to bed down. At that point, we'll start to roll out Google Docs and Sites, although at the moment the intention is that those are deployed to help with specific applications, rather than just turning them on for everyone. I've seen too many examples where powerful content management tools like those are deployed without help to structure how they are used, and mis-managed chaos being the net result.

The experience this far has been largely positive. I'm sure that in the coming 6-8 weeks we will see a big increase in support load, tears, tantrums and the odd word of thanks. Being able to focus on implementing the change, rather than implementing the technology however, has been an extremely liberating experience. Having the Google Guides located in and around the business has been remarkable in its effectiveness thus far.

After a tour around the building first thing this morning to see how people were getting on, I stopped off in the restaurant. I bumped into Kevin, a colleague from the fourth floor. "It's remarkable" he commented "People actually seem to be really excited about this Google stuff"...

Another impact of the way in which the delivery of information systems is changing is in the way in which IT departments can control the use of technology within organisations.

The traditional model was that IT departments provided white lists of approved applications. If the IT department said you could use it, then you could. If they said you couldn't, you couldn't unless you could convince them otherwise. This was usually implemented using lock down of operating systems, and systems management platforms.

This slow moving, gatekeeper approach was one of the major drives behind the "No IT Department" marketing that SaaS vendors love so much... IT departments viewed as inhibitors to the business, not as facilitators. No wonder so many of them got sold off...

In a world where an "application" is something that can be delivered in a browser, the white list model is broken. A technical distinction exists between applications that the IT Department say you can have and they have control over (those that need to be installed into the OS), and those that they have no say over that don't require an install.

I've come to the conclusion that the only path IT departments can take is to move to an unfortunately reactive black list model... you can do whatever you want unless we have explicitly told you you can't. It's not the most positive of messages, but it's the only way I can see that I can offer a level of IT governance in a world where I cannot afford to become a bottleneck. It also requires a high level of IT literacy in the organisation.

On the black list of note for me at the moment are Spotify (my favourite app in the world, but a killer on a corporate network), and demo new versions of software used on client work (because it will create file formats that we then have to buy the full version to access in the future). Adobe, bless them, are particularly good at making our lives an upgrade nightmare using the latter stealth marketing techniques.