Google launches Google Sites
Google is once again treading on Microsoft toes with the launch of its newest product, Google Sites. The new offering allows users to create and manage their own websites, and is based on the wiki technology the company acquired from JotSpot in October 2006. Google Sites is clearly targeted at the market currently dominated by Microsoft Office SharePoint Server, and the beta-version hosted derivative of SharePoint, Office Live Workspace (which I blogged about
here), while highlighting its own simplicity and low cost - Google Sites is available free to existing Google Apps customers.
Unusually for a new Google product it is not a beta version but a fully released product, no doubt thanks to its history under JotSpot. Most notable is the work that Google has already put into integrating the software with other Google applications - Google Calendar, Google Docs, YouTube and Picasa are all integrated to allow embedding of calendars, documents, videos, etc. into your site.
It is interesting that Google has squarely removed all reference to wikis in its description of Google Sites, at a time when many enterprise software vendors are clamouring to ensure their offerings at least reference Enterprise 2.0 terms such as "wikis" and "blogs". This is the right decision: the Google Sites offering, while far from being a sophisticated site design tool, is much broader than many wiki tools in the market. It will also help Google in its attempt to "cross over" into the enterprise market - despite the success of business-focused products like Google Search Appliance, Google is still very much an Internet brand. While wikis and blogs are very "now", they are far from established in the enterprise, and the terminology can alienate less tech-savvy business users. Google needs to create confidence and trust among the enterprise market, and this branding/marketing decision seems to reflect this.
Clearly Google Sites is not going to displace SharePoint in the short term. But Google continues to challenge the dominance of Microsoft in this space, and yet again it has chosen a services-based approach to achieve this. The debate around whether or not Google will displace Microsoft in office productivity will continue for a long time yet, but in the meantime, Google continues to show perceptive awareness of what it needs to do, as well as the investment capacity and determination to do it.
Labels: collaboration, enterprise 2.0, google, Microsoft
The lore of averages
I was chatting to a friend who's a top-notch Java developer over the weekend: we were shooting the breeze about Groovy, Rails, Spring, Hibernate and various other Things That Get People Excited (let's call them TTGPEs), and discussing how far they were likely to penetrate into your average IT shop. "Why do so many people insist on following the J2EE application model and associated patterns so slavishly," said my friend, "when they're so plainly not the right tool for the job in so many scenarios?"
"The thing that you never get from reading development books," I said - he'd just finished showing me a book on Groovy - "is how difficult it can be for your average IT shop to get on board with a new development technology, when you take commercial considerations into account. You can see from looking at code samples that language A is more compact or give you more productivity than language B. But what you can't see is the bigger picture of costs and risks."
I remembered a post of Steve Jones' I'd seen a couple of months back about
development as a discipline for the masses - and also
this one from Jeff Schneider about the value of SOA governance.
You see, the problem for your average IT shop in taking on TTGPEs is that even when they have been demonstrated to save time and/or money, there are two real barriers to adoption. Both barriers exist primarily because these shops have no option but to see development resources as a commodity.
First, within an average IT shop - think of one within a small utility provider or a local government - the business can't make a case for paying top whack to hire the very best developers. So, they have to shoot for the "mass market" of developers - hopefully capable and dependable, but not likely to be stellar performers. They also don't have a lot of time or money available for recruiting, so they tend to minimise the complexity of interviewing as far as possible - asking for "industry standard", well-recognised skills. Unless they can find TTGPE skills within that "mass market", they're not going to consider bringing those skills into the organisation. J2EE skills are now mass-market skills. Groovy skills aren't (yet).
Second, within such an IT shop, work tends to follow those same "industry standards", because the risk of doing TTGPEs is that if people leave or get sick, and new people have to be brought in, they have to be able to get new resources up-and-running quickly. If new staff have to spend weeks or months trying to re-engineer glamorous but unknown technology before they can continue a project, that's a huge, ugly cost.
Regardless of whether J2EE is increasingly being revealed to be more like a VW crossed with a tractor than a Ferrari, then, the truth is that most people have little choice, for now, but to stick with it and make the best of things.
Labels: 4GL redux, development, governance, industry
