Declan made a recent comment about the need for a Behind-The-Firewall version of Facebook, perhaps even appliance-based, a sort-of Facebook-in-a-Box. In my reply, I indicated that he echoed my thoughts precisely…. but with one small proviso…. that was the way I thought a few years ago. That I had since changed my mind.
What Declan wants is what any self-respecting CIO wants: control and predictability over the content, its access and even its behaviour. In fact, there’s a growing body of regulation that demands such services from CIOs; so much so that a CIO can actually go to jail in some jurisdictions if some of the content isn’t appropriately cared for. And, as I said, it’s what I would have wanted. So I would have done exactly what Declan asked for, and lived happily ever after.
Now I wonder whether it’s the right thing to do. Let me try and explain why.
Let us assume I have a Behind-The-Firewall version of Facebook, delivered as an appliance. [The appliance bit doesn’t really matter, it isn’t really germane to the discussion.] Let us further assume that many other institutions do exactly the same thing. What have we achieved?
We’ve managed to pave the cowpats. We’ve managed to lay concrete over crap, as it were. What we have done is replicated our traditional e-mail system approaches. Walled gardens carefully designed to keep people out, with some sort of selective process to let people in. Walled gardens that we had to tunnel holes into so as to allow the customers and partners and supply chain in. Walled gardens that started letting in mice through the holes, so that we made an industry out of building bigger and better mousetraps. Spam filters that regularly managed to keep people out and not just mice.
These walled gardens, these islands of information, also led to a pile of other industries, not all of which were necessary. Because we had these islands of information, we had to replicate information about our customers and supply chain in each of the islands. These pesky customers would refuse to deal with just one island, so information about them had to be captured and stored in every island.
Then it got worse, the pesky customers insisted on changing their information, so every island had to change its copy. Another industry was born. And it didn’t work too well.
And because it didn’t work too well, because changes were not synchronised between islands, something else happened. Transactions between islands broke down because of mismatches in the customer information. So we needed another industry, one that reconciled these broken-down transactions.
You see, that’s what happens when we build “vendor-centric” approaches, where we try and visualise customers and partners and supply chain participants as almost-unwelcome invaders into our fortresses and fiefdoms. The model only works when a customer is enslaved by a specific vendor, which is what the extreme version of a lock-in looks like.
Those days are gone. In most markets, customers deal with more than one vendor; there are many models emerging where multi-vendor is the norm rather than the exception. This inversion, from a vendor-centric approach to a customer-centric one, is, as far as I can make out, precisely what drives Vendor Relationship Management.
What’s all this to do with Facebook? Everything. Facebook is really a collection of customers all dressed up with nowhere to go. Since it’s an open multisided platform (OK OK, I hear you, it’s not as open as you want, but humour me just this once) it means that vendors can set up shop, but they can’t lock the customers in. Facebook is about enabling conversation. Connecting islands together by using a complex array of firewalls is tantamount to having firewalls on telephone lines or in coffee shops.
In Facebook, I can make sure I only “talk” to people I want to “talk” to. I can make sure that only the people I choose see the things I choose to show them. So why do I need further protection?
In Facebook, personal information is managed by the person whose information it is. Which seems reasonable. Who else can keep it up to date? Who else is interested in keeping it up to date? Furthermore, the information is only held once and in one place, so there’s no need for synchronisation and replication, there’s no need for transaction breakdown, repair and reconciliation as a result of “static” mismatches.
You’re right, this post is really not about Facebook. And yet it is. I find it a useful example to try and think through some of the things I face, so forgive me for rambling. Incidentally, I don’t expect Facebook to release a BTF version or appliance. It’s not the business they’re in, or indicate their intention to be in. They are not a product company, they’re an open multisided marketplace.
Like this:
Like Loading...