Data security vs agility and cost

Third party social media tools really are a two-edged sword. On the one hand, they allow you to get up and running almost instantaneously for little or no money, but on the other hand you have no data security or guarantee of uptime.

I’m reminded of this dichotomy by the recent closure of a number of music blogs by Google’s Blogger service. Despite the fact that these blogs were all operating legitimately and within the law, Google removed their content from Blogger without either a warning or an opportunity to back up. This appears to be bad behaviour from Google, but they are not alone. Yahoo! has a track record of closing down Cinderella services without much of a by-your-leave, resulting in confused and unhappy users whose data has been lost forever. And, of course, there was the catastrophic server meltdown at Ma.gnolia, a Delicious.com rival, which resulted in their entire bookmark repository being lost.

Whether it’s a company targeting a few users, closing down underachieving services, or suffering massive data loss, there is just no guarantee that the information you put online is still going to be there in the morning.

So does this mean that corporate information should never be entrusted to third party sites? Not at all. Firstly, it’s not always possible to run your own internal version of a third party tool, and often it’s not even desirable. You could never replicate the networked nature of a third party social network, for example.

Sometimes you can install software, such as WordPress, on your own servers, but if your IT department is maxed out or uncooperative, you may be forced on to WordPress.com instead. There could be a significant cost to the business if you have to wait months for your own installation to be set up and for your project to get started, in which case the hosted option becomes the most viable option.

The answer? Your social media tools should, where possible, be regularly backed up just as with your own servers. Recovery of your social media presence should be at the top of your disaster recovery plan, if only because if something serious happens to your company or any of your other data, your blog could be a key communications channel. (This is also a good reason not to host your own blog on the same servers as your main website, by the way! If everything else goes down, you need to have some way to communicate with the outside world.)

The power of ecosystems

It used to be that I judged a new social tool, service or application purely on intrinsic qualities such as functionality, usability, design or utility. In an increasingly competitive social media landscape, where even niches are getting crowded, what is it that makes one tool stand out above the others?

Ecosystem. Plain and simple. What kind of API does the tool provide? How vibrant is the developer community? What other tools and services are building up around it?

Twitter, for example, has a really vibrant ecosystem, full of tools that allow you to post pictures, track compressed links, analyse statistics, manage your accounts, send Tweets longer than 140 characters. The ecosystem is so vibrant that a service devoted just to cataloguing it has sprung up: OneForty.com.

Wordpress is another tool with a fabulous ecosystem, not just in terms of plug-ins and themes, but also in terms of developers. I’ve never had a problem finding WP developers to help me out when I need a hand wrangling the finer points of WP admin.

The Delicious ecosystem, on the other hand, appears to be moribund. The Firefox add-on that I used to rely on, Delicious Complete, is now defunct (does not function in FF3) and I can’t find an alternative that allows me to manage multiple accounts. There are a handful of dedicated add-ons for Firefox, but beyond that the wider developer community is either invisible or just doesn’t exist. New tools, like Instapaper, that could tie in with Delicious don’t. That’s a real shame because Delicious is one of my favourite tools, but it simply isn’t that easy to embed it in my working processes.

I know that there may be some very good reasons why some tools have better ecosystems than others, but as I’m not a developer and have never looked at the barriers to entry for working with these different tools, I can’t speak to that side of the debate.

But ecosystem is very important to users not just in deciding which tools to use, but whether to be loyal. The cost of switching from Twitter or WordPress to a competitor is quite high. It’s not just a matter of swapping one service for another, but of having to start again with the community, whether that’s moving your own social network over or finding new people to worth with on the new platform. The cost of moving from Delicious, however, would be relatively low. If someone offered a better service with better tools and even a small ecosystem that showed promise, I wouldn’t hesitate to migrate my data.

Is tendering right for social software projects?

One of the most important stages in building a relationship with a new client is, in my opinion, requirements gathering. Partly this happens even before a deal is struck, because consultants need to know top level requirements before they can put together a proposal.

Once work begins there’s usually a more formal and detailed requirements gathering phase during which one learns about the client as much through observation as direct questioning. This period of learning is crucial. To do the job well, one must understand how one’s client thinks, how they work, what they are expecting, what they know, not to mention figuring out what the client thinks they want and what they actually need.

This is at odds with the common procurement procedure of having multiple companies/consultants tendering to fulfil an already detailed brief. I came across one of these briefs just the other day and it was a stark reminder of how the tender process fails horribly when the client doesn’t understand what it is they are asking for.

The tender in question was very detailed: seven pages of background, contract objectives and deliverables, specifications, timetables and milestones, selection criteria and more. But whilst it’s great to see that they’d put so much thought into it, their basic premise was so deeply flawed that I can only imagine two types of people who would tender for the job as described: a naïf with no real understanding of social media, or someone with flexible ethics.

The tender process is setting the project up to fail. A responsible consultant would respond to the tender with a counterproposal, suggesting alternative avenues of exploration that would be more fruitful and constructive. I fear, however, that once a project is at tender stage, so much work has gone into it and so many colours nailed to its mast that it becomes politically difficult to turn the ship around.

The sad thing is, when the project fails it will be social media that is blamed, not the project’s central concept. And had the organisation in question spent a little bit of money up front working with someone who knows their onions, they could have saved a lot of money in the long run. Penny wise, pound foolish.