About Us Secure Tabs Our Investments News Investor Info Blog

Archive for June, 2007

ACAP Conference

Friday, June 29th, 2007

I attended the first annual ACAP conference this week (ACAP stands for Automated Binary Access Protocol, their website is http://www.the-acap.org/). They are defining a standard mechanism that will allow publishers to communicate permissions information about content that can be automatically recognized and interpreted by any automated process that would like to use the content.

Currently the only mechanism available to publishers is the Robots Exclusion Protocol (REP, some people just call it robots.txt, the file placed in the root directory of a website that defines which files should or shouldn’t be visited by crawlers). There is also the Robots META tag which allows HTML authors to indicate to visiting robots if a specific document may be indexed, or used to harvest more links.

These mechanisms don’t give publishers very much control over how their content is used and they would like much finer grained control - both at the content level (not just files) and on the usage level (how the content can be used). A while back Yahoo announced a “robots-nocontent” tag that allows marking certain sections as unrelated to the main content of the page, and should therefor be ignored by search engines. It is an interesting addition to REP, but really doesn’t do much to take into account publishers concerns - since it is focused on control over indexing, not delivery (e.g. caching, summarization), and hasn’t been picked up by other search engines.

So what happened at the conference? Attendance was good, lots of people from various publishers - heavily European, but not exclusively. Google, Yahoo and MSN sent representatives, but it was clear that this was a conference led by publishers. There was a certain amount of “Google\Yahoo\MSN” bashing going on, mostly because they haven’t been willing to sign up as members of ACAP.

It is clear that the current lack of control that publishers have over their content on the Internet is a problem and it is preventing them from putting more of their content online (books, periodicals etc). It is also clear that the two groups (search-engines and publishers) have very different mind-sets about what is important. Publishers want to control all aspects of delivery and use of their content, since they make money from that content. They worry that aggregators give away the baby with the bathwater, and by creating their own summaries and caching pages search engines are lowering the value of the actual content. Search engines want access to as much content as possible, index it, summarize it and make things as easy to find as possible on the web. They make money from people accessing this aggregated information.

Then of course there is the whole issue of copyright - the publishers whole business model is based on the fact that owners of content have a proscribed set of rights that allow them to have control over their content, its delivery and usage. Search engines believe that copyright is a bit antiquated, and that by allowing people to find content, they are doing the publishers a service. I think that they are both right - but they come from such different worlds and mind-sets they have troubling understanding each other, or addressing each other concerns. They need to understand that they are in a symbiotic relationship and need to figure out how to work together.

It seems to me that they may be worried about “yesterday’s” technology - with the advent of tools for extracting parts of a page, ad-enabled syndication and mashups - the issues will become even thornier, and any solution will need to take those emerging capabilities into account too. ACAP could become very influential as forum for creators of these technologies and publishers to sit down, understand each other and work out solutions to the issues. If ACAP can make that happen - then they will have real influence over how content is delivered on the web.

The Long Road towards Integration – Part 2

Thursday, June 28th, 2007

This is for the Israeli side of the merger. First understand that even if the company acquiring you has done this before – it was probably by a different group of people. It may have even been in a different country. Cut them some slack – they probably mean well, but they are learning too. Don’t assume that they can tell you what to do (or that they know), they are looking as much for input from you as you are from them.

Make sure you know how things are decided in the company, and how to influence decisions. Delegate roles and responsibilities among yourselves so that you can have different routes of communication back to HQ. Go visit them at HQ and be on the lookout to see who has real influence and power. Assume that things will be hard in the beginning, but there are real benefits to being part of a larger American corporation - budgets are larger, career opportunities are greater and you can make a big difference. Find some advocates for you at HQ, or send some.

The Long Road towards Integration – Part 1

Saturday, June 2nd, 2007

Given my background, and technology orientation, I bet you thought I was going to be writing about EAI. Well I am not, I’ll be writing about of integration of a startup into a larger company after an acquisition. Since M&A is a standard exit for Israeli start-ups I though this would be of interest.

Fist of all – let me make it clear integration after an acquisition, even when handled perfectly, is hard (and it is never handled perfectly). Second, Israelis aren’t Americans (which I think is relevant since most Israeli companies are acquired by American companies). Third, distance does make a difference. Having gotten that off my chest let me start with some rules for the acquirer:

The trouble starts with the whole mechanism of the deal – everyone is focused on closing the deal – no one is thinking about what happens the day after. This leads me to rule 1 - make sure that someone is thinking about the day after. There should be one person from each side, but at least one senior person on the acquiring side. Give that person both responsibility and power. Make sure they have clout in your organization, know how to get things done – and have exceptional people skills. Actually people skills are the most important attribute.

Rule 2, 3, 4 – Communicate. Communicate. Communicate. You can never communicate enough. Israel is far away, and has a unique culture. Because of the distance you can’t have impromptu meetings in the hallway, lunchroom or at the coffee machine. You need to keep people informed, and if the Brits and American are two people divided by a common language – just imagine when there is no common language. Yes, most Israeli’s speak American – but they don’t always understand the nuances of american english – especially in a corporate environment. Constant communication is the only way to keep a misunderstanding from festering into a full-blown crisis.

Rule 5 – Pretend you are a doctor and have taken the Hippocratic oath – first do no harm. Don’t change anything until you have learned the landscape of the new company. I know successful US executives have a penchant for action – but this is a case where early action can be disastrous. Understand that it will probably take a year until the company is more or less integrated. Maybe I should have put this rule first.

Rule 6 – Get help. Try to find someone that has some experience in these types of mergers and get them to help. It will keep you from having to learn only from your own mistakes.

Rule 7 – visit early, visit often. Make sure that the new company gets to know you and your team. Make sure that you get to know them.

Rule 8 – remember that the company acquired is diffeent than your own, with their own unique culture. That is probably one of the reasons you acquired them – figure how to work within that culture without breaking things too badly.

Rules 9, 10 – Make sure you remember why you did the transaction. Sometimes in the grind of the day-to-day and with executives switching in and out of roles – the actual strategic reasons for the acquisition are lost. Make sure you keep that knowledge alive, and use it to help with the day-to-day decisions.

Strategic vs. Viral in Enterprise Software

Friday, June 1st, 2007

I have been thinking lately about the meaning of strategic software in the enterprise. I have had a number of conversations about interesting, useful applications for business, which were usually shrugged of since they aren’t “strategic”. I think the holy-grail of “being strategic” in enterprise software is a mistake, and explains why enterprise software has fallen out favor with VCs. It is impossible (or at least very, very expensive) to become strategic, and it takes a long time. Strategic, at least in these conversations, means inventing some piece of software (infrastructure or solution) that is so central to the needs of the organization that not having it become a critical showstopper. Becoming strategic moves the buying decision to the senior executive level at the customer, rather than through projects or end-users. It requires a skilled sales force and longer sales cycle – but has much, much higher revenue per sale.

The Web (especially 2.0) is different. The adoption mechanism of a software solution is viral – users enticing other users to join in the fun. This seems to be diametrically opposed with the strategic software paradigm – this type of adoption has to be simple enough that end-users can use the software and get value without the need for a centralized decision, IT department or skilled sales force. Since users use applications (and not infrastructure) viral adoption happens at the application, not at the infrastructure, layer (while most strategic software is in the infrastructure, not application layer). Of course apps drive infrastructure, so this type of software adoption in the enterprise will have a profound effect on enterprise infrastructure and architectures (e.g lets see how SOAP vs REST plays out for services). This type of adoption scares the pants off CIOs who crave centralized control and walled gardens.

This is the crux of the Enterprise 2.0 dilemma for software startups – how to get viral rather than strategic adoption in the enterprise. The best way to do this is by creating network effect applications that have value to enterprise users stand-alone (of course initially delivered over the internet as a service). If you have such an application, I’d love to hear about it.