About Us Our Team Our Investments News Investor Info Blog

Archive for the ‘Integration’ Category

Enterprise Software Startup Valuation

Sunday, February 10th, 2008

Not a blockbuster headline, but I just noticed that Workplace, Inc. bought Cape Clear. I had never heard of Workplace before, they sell various Enterprise applications using a SaaS model. I had heard of Cape Clear, they are (were?) a pretty welll known Irish startup in the Enterprise Integration\SOA space - providing Enterprise Services Bus middleware.

Most the articles I have seen about the acquisition focus on the aspect of how integration into existing systems is a key capability for SaaS players, and that the Enterprise middleware space is rapidly consolidating. Makes sense, but for me what is more interesting is what this says about enterprise software startups and their valuation. The details of the deal are confidential - but I am guessing that the deal isn’t a blockbuster (given the size of the acquirer), and I’d be surprised if the deal was for more than $50M (maybe much, much less), all stock. Now according to Joe Drumgoole’s blog about $48M has been invested in Cape Clear over the years - so a $50M exit doesn’t leave much for anyone. Here is his list of Cape Clear investments:

  • 2 Million in seed funding from ACT in 2000
  • 16 million in Series A funding from Accel and Greylock in 2001
  • 10 million in Series B funding from Accel and Greylock 2003
  • 5-10 million: A phantom series C round raised as a set of warrants amongst existing investors. It was never press released and their is no mention of it on the net.
  • 15 million in a series D round in the last few weeks (April 2006 - Jacob) with InterWest

Cape Clear seems to have been a “technology” acquisition for Workday - which brings me to my point about Enterprise Software startup valuations. It is very difficult to become a stand alone player in Enterprise software (especially with all of the consolidation going on), and if you aren’t a viable stand alone enterprise software company - well that means you need to plan for the fact you will be acquired - probably for technology. To make sure that a technology acquisition is a viable exit path you need to make sure your valuation isn’t too high in the early stages. Enterprise technology companies seem to sell for $15M-$100M, depending how strategic they are to the acquirer - but require a lot of money in the later sales and marketing phases.

So make sure you don’t over value your company early on, it will come back and bite you later.

Microhoo - My Thoughts on a Microsoft-Yahoo Merger

Sunday, February 3rd, 2008

Well, it is in the news everywhere, the possibility of a $44B Microsoft/Yahoo merger.  Given that I have spent a lot of ink discussing how to manage mergers after they happen - I find it hard to believe that this merger will actually end-up as a net positive for either company over time. The companies are just too different. Yahoo has been spending the last few years making itself into a media company (though lately they have been talking about getting back to their technical roots), and Microsoft is, in the end, a software and engineering company. My guess is that it will be hard for the merged “Microhoo” to be both a media and software company at the same time, which will cause enormous tension w.r.t to management attention and resource allocation. I wouldn’t want to be the one who has to make that merger work…

Another point that has been discussed ad-naseum is whether this will help or hurt the start-up eco-system. I attached a table taken from the Israeli government website about recent acquisitions of Israeli comapnies. Taken in a purely Israeli context it will probably be a net plus. First of all Yahoo has been a complete non-player in Israel, while Microsoft has both a large presence and made three acquisitions lately (see the table below). People are right that Microsoft will be busy for a while digesting the acquisition, which will slow its pace. The good news is that it will probably cause other players to pick up the pace of their acquisitions - AOL (which bought Quigo and Yedda which even aren’t on the list), Ebay which has bought Shopping.com and FraudScience (also not on the list). Maybe even some of the other advertising\internet players - e.g. Google, Amazon, IAC, News Corp. will start acquiring differentiating technology in Israel which would more than make up for any slowdown by Microsoft.

Recent Israeli m&a activity chart

Data Integration and Mashups

Saturday, November 10th, 2007

I am attending Mashup camp and university here in Dublin (the weather reminds me of a poem that a friend of mine wrote about Boston in February - gray, gray, gray, Gray!). IBM was here in force at Mashup University giving three good presentations (along with live demos) on their mashup stack. They were saying that the products based on this stack should be coming out early next year (we’ll see, since from my experience it can be very difficult to get out a new product in an emerging area in IBM - since you can’t prove that the space\product is valuable enough). They have decided to pull together a whole stack for the enterprise mashup space (the content management layer, the mashup layer and the presentation layer -see my previous post on mashup layers). One thing that struck me, especially when listening to the IBM QEDwiki and Mashup hub presentations, is how much those upcoming set of tools for enterprise mashup creation are starting to resemble  “traditional” enterprise data  integration tools (e.g. Informatica and IBM\Ascential). These new tools allow easy extraction from various data sources (including legacy data like CICS, web data  and DBs), and easy wiring of data flows between operator nodes (sort of a bus concept).  The end result isn’t a DB load as with ETL, but rather a web page to display.  No real cleansing capability yet, but my guess is that will be coming as just another web service that can be called as a node in the flow. So it is like the mashups are the lightweight cousin of ETL - for display rather than bulk load purposes. It will be interesting to follow and see how ETL tooling and mashup tooling come together at IBM, especially since the both the ETL and mashup tools tools are part of the Data Integration group at IBM.

Microsoft seems to be taking another route, a more lightweight desktop like approach, and focused on the presentation layer. Popfly is a tool that also allows you to wire together data extraction (only web data as far as I could tell, though it could be extended to other data types) and manipulation nodes – as you link the nodes, the output of one node becomes the input of the next etc… It seemed very presentation oriented, and I didn’t see any Yahoo! Pipes like functionality or legacy extraction capability.

Serena is presenting tomorrow, it will be interesting to see what direction they have taken.

The Long Road towards Integration – Appendix

Sunday, October 28th, 2007

I was at Journey 2007  (E&Y’s yearly conference for startups and VCs) last week – it was an OK conference, a good way to catch up with people I haven’t seen for a while. I did sit through one interesting panel on Mergers and Acquisitions, and heard some additional insights that I would like to add to my “Long Road to Integration” series. The points reiterate some of the points I have made before, but I thought it was worth posting them anyway – since the whole panel more or less agreed with them.

The first is that there is no such thing as a merger of equals – the larger company ACQUIREs the smaller company – and make sure you understand that before you go into the transaction. Also, the bigger size difference between the company, the greater the chance for a successful outcome.

Even though you may need to let the CEO go, make sure you keep on the 2nd a 3rd level management at the company. They are what keep things ticking.

Finally, since culture issues are a large culprit in the failure of an acquisition the acquiring company should appoint a SPOC.

The Long Road towards Integration – Part 4

Sunday, October 21st, 2007

I am sort of surprised that I am back on this subject again, but when I read that Microsoft’s Ballmer plans to buy 20 smaller companies next year (Ballmer: We Can Compete with Google) it drives home for me the importance of being able to integrate well in the aftermath of M&A. My best guess is that those 20 companies will include 1-2 large companies, the rest being small and midsize companies - companies that are “innovating in the marketplace” (a term we used to use at IBM Research). So Microsoft is effectively outsourcing a good portion of their innovation, and placing a big bet on being able to integrate these acquisitions into the fabric of Microsoft.Thee types of smaller acquisitions seem to be in the cards for IBM and Google - and I think more and more technology companies will be outsourcing their innovation this way - augmenting internal “organic” growth with external  ”inorganic” growth. Oracle seems to have gotten this down to an art (though they tend to swallow whales rather than minnows), and even SAP has jumped on the bandwagon. One issue that will clearly come with these acquisitions is how the acquiring company doesn’t kill the spark of innovation that exists in these smaller companies  (of course that is assuming that they want to keep the innovation alive, and aren’t just buying a specific technology or existing product.I had the opportunity the other day to speak with someone that was on the Corporate side of an acquisition and discussed what was their thought process at the time of the acquisition, and how that differed from how things turned out after the acquisition.One thing that struck me was that both sides were fooled since they were (paraphrasing Bernard Shaw)  ”two companies separated by the same language”. The company being acquired thought they were communicating important information about the acquisition, but it turns out that they were using internal shorthand to describe people and situations, which were interpreted completely differently by the other side. This was probably exacerbated by the fact that one side was Israeli and the other American - but it could have happened with any two companies - especially when there is a high impedance mismatch between the two (or in English - the companies are of very different size). . For example when one company said a manager “kept the trains running on time” - they meant a clerk that could keep to a schedule - while the other side thought  they meant someone could manage a complex system with all its nuances and make sure that it keeps working. Understandably these kinds of miscommunications caused a lot of faulty decisions to made during, and right after the acquisition.In my experience it takes about 9  to 18 months until the sides really start to understand each, how the other side works - and how they need to work together. That is assuming that everything goes smoothly. If you try to speed it up too much - you will end up killing the innovation, and you may end up killing any possibility of a successful acquisition.So what is the bottom line? Assume that you will need to keep the current structure of the acquisition intact for about a year before you can make any drastic structural or strategic changes. See the rest of my recommendations in previous posts - and perhaps hire a consultant that has been there and can help smooth the transition.

HBR Article on Acquisition and Integration

Wednesday, September 12th, 2007

Haven’t posted lately. Not sure why (the kid’s summer vacation didn’t help much), but just couldn’t find the time. I read a good article on Acquisition and Integration in the September edition of Harvard Business Review (Rules to Acquire By - Bruce Nolop) which gives insight into how Pitney Bowes does acquisitions.  I especially liked the differentiation between “bolt-on” and “platform” acquisitions.

 However, even though all the points were right on, but I thought it was interesting that for the most part focused on things that need to get done before an acquisition takes place (probably makes sense given his CFO perspective).  I would like to see a similar article on “post-acquisition” since I have found that even if an acquision is made for all the right reasons - unless great care is taken for the first 12-24 months of the acquision to the integration process - the acquision will fail to live up to its promise (or just fail…)

Walled Gardens on the Web (and elsewhere)

Wednesday, July 25th, 2007

Facebook has been getting a lot of press lately - one discussion item that caught my eye was a number of blogs and discussions around whether Facebook can thrive as a  “walled garden” (which refers to a closed set or exclusive set of information services provided for users (click here for the Wikipedia entry).

The main issues raised were the viability of a walled garden on the internet, the pluses and minuses walled gardens - both for the provider and for the consumer (you can find an interesting discussion at http://www.micropersuasion.com/2007/06/walled-gardens-.html). Most of the examples talk about AOL and how it failed as a walled garden, as did cellular providers that tried to limit WAP access to only certain sites.

I am not sure I actually understand the point - since the the whole internet is just sets of walled gardens - how many websites let you use thier information freely. Very few have comprehensive (or any) APIs, more have feeds that give you limited access to the information actually available. So how is Facebook any different?

One key difference is that opposed to most sites - Facebook has collected your own, personal information (or that of your friends). People want to be able to do with their own information whatever they please. So I think the right analogy isn’t the AOL walled garden approach, but rather something even more “ancient” - the client server revolution  of the 80’s. For years after GUIs and PCs were available it was still very hard it was to get your own organizational information out of various legacy systems to use in new applications. Even though the information was yours  - you couldn’t get at it to use as you like - either because the vendors couldn’t keep pace with the emerrging technologies - or didn’t want to (so they could keep it “hostage”). This gave rise to an imperfect, but usable technical solution that let people get at their information even though the system didn’t have the capability - a whole new set of “screen scraping” technologies that emulated users to get the  desired information out of applications.

So I think that the same will happen here - either the walled gardens will open up or  people will figure out to get at it some other way.

The Long Road towards Integration – Part 3

Thursday, July 19th, 2007

Well, I guess you learn something new every day.  

A super critical requirement is a headquarters SPOC (Single Point of Contact) for any decision concerning the remote location - for any decision that comes out of HQ that is not day-to-day business as usual. Someone who cares about the over health and well-being of the lab, even for things that don’t directly effect them, or their department. This is especially true if the remote location consists of a conglomeration of smallish groups reporting to different HQ functions. Otherwise, the different HQ departments will try to optimize things for their own group - but these local optimizations can a have a huge impact on the overall health of the lab - which won’t be noticed until it is too late (unless their is a SPOC).

For example, two HQ departments  could decide to streamline their organizations and remove some positions - for example each decides to remove one person in the remote location.  Even though each decision on its own makes sense - taken together it could have a very negative effect on the remote location - lowering moral and motivation. Cleaning up the fallout could take months….

So make sure you have a SPOC. Live long and prosper!

Structured, Semi-Structured and Unstructured Data in Business Applications

Monday, July 16th, 2007

I was discussing these issue again today - so I thought this old paper must still be relevant….
 
There is a growing consensus that semi-structured and unstructured data sources contain information critical to the business [1, 3] and must be made accessible both for business intelligence and operational needs. It is also clear that amount of relevant unstructured business data is growing, and will continue to grow in the foreseeable future. That trend is converging with the “opening” of business data through standardized XML formats and industry specific XML data standards (e.g. ACORD in insurance, HL7 in healthcare). These two trends are expanding the types of data that need to be handled by BI and integration tools, and are straining their transformation capabilities. This mismatch between existing transformation capabilities and these emerging needs is opening the door for a new type of “universal” data transformation products that will allow transformations to be defined for all classes of data (e.g., structured, semi-structured, unstructured), without writing code, and deployed to any software application or platform architecture.

 The Problem with Unstructured Data
 The terms semi-structured data and unstructured data can mean different things in different contexts. In this article I will stick to a simple definition for both. First when I use the terms unstructured or semi-structured data I mean text based information, not video or sound, which has no explicit meta data associated with it, but does have implicit meta-data that can be understood by a human (e.g. a purchase order sent by fax has no explicit meta-data, but a human can extract the relevant data items from the document). The difference between semi-structured and unstructured is whether portions of the data have associated meta-data, or there is no meta-data at all. From now on I will use the term unstructured data to designate both semi-structured and unstructured data.

The problem is that both unstructured data and XML are not naturally handled by the current generation of BI and integration tools – especially Extract, Transform, Load (ETL) technologies. ETL grew out of the need to create data warehouses from production database, which means that it is geared towards handling large amounts of relational data, and very simple data hierarchies. However in a world that is moving towards XML, instead of being able to assume well-structured data with little or no hierarchy in both the source and target, the source and target will be very deeply hierarchical and probably have very different hierarchies. It is clear that the next generation of integration tools will need to do a much better job of inherently supporting both unstructured and XML data.

XML as a Common Denominator
 By first extracting the information from unstructured data sources into XML format, it is possible to treat integration of unstructured data similarly to integration with XML. Also, structured data has a “natural” XML structure that can be used to describe it (i.e. a simple reflection of the source structure) so using XML as the common denominator for describing unstructured data and structured data makes integration simpler to manage.

Using XML as the syntax for the different data types allows a simple logical flow for combining structured XML and unstructured data (see Figure 1):
1. extract data from structured sources into a “natural” XML stream,
2. extract data from unstructured sources into an XML stream,
3. transform the two streams as needed (cleansing, lookup etc.)
4. map the XMLs into the target XML.

This flow is becoming more and more pervasive in large integration projects, hand-in-hand with the expansion of XML and unstructured data use-cases. These use cases fall outside the sweet spot of current ETL and Enterprise Application Integration (EAI) integration architectures – the two standard integration platforms in use today. The reason is that both ETL and EAI have difficulty with steps 1 and 4. Step 1 is problematic since there are very few tools on the market that can easily “parse” unstructured data into XML and allow it to be combined with structured data. Step 4 is also problematic since current integration tools also have underpowered mapping tools that fall apart when hierarchy changes, or when other complex mappings, are needed. All of today’s ETL and EAI tools require hand coding to meet these challenges.

dm-review-no-affiliation.jpg
Figure 1: A standard flow for combing structured, unstructured and XML information

The Importance of Parsing
 Of course, when working with unstructured data, it is intuitive that parsing the data to extract the relevant information is a basic requirement. Hand-coding a parser is difficult, error-prone and tedious work, which is why it needs to be a basic part of any integration tool (ETL or EAI). Given its importance it is surprising that integration tool vendors have only started to address this requirement.

 The Importance of Mapping
 The importance of powerful mapping capabilities is less intuitively obvious. However, in an XML world, mapping capability is critical. As XML is becoming more pervasive, XML schemas are looking less like structured schemas and are becoming more complex, hierarchically deep and differentiated.

This means that the ability to manipulate and change the structure of data by complex mapping of XML to XML is becoming more and more critical for integration tools. They will need to provide visual, codeless design environments to allow developers and business analysts to address complex mapping, and a runtime that naturally supports it.

Unstructured data is needed both by BI and application integration, and the transformations needed to get the information from the unstructured source data can be complex, these use cases will push towards the requirement of “transformation reusability” – the ability to transform the data once (from unstructured to XML, or from XML to XML) and reuse the transformation in various integration platforms and scenarios. The will cause a further blurring of the lines between the ETL and EAI use cases.

Customer data is a simple example use case. The example is to take customer information from various sources, merge it and then put the result into an XML application the uses the data. In this case structured customer data is extracted from a database (e.g. a central CRM system), merged with additional data from unstructured sources (e.g. branch information about that customer stored in a spreadsheet), which is then mapped to create a target XML representation. The resulting XML can be used as input into a customer application, migrate data to a different customer DB or create a file to be shipped to a business partner.

Looking Ahead
 Given the trends outlined above there are some pretty safe bets about where integration tools and platforms will be going in the next 12-24 months:
1. Better support for parsing of unstructured data.
2. Enhanced mapping support, with support for business analyst end-users
3. Enhanced support for XML use cases.
4. A blurring of the line separating ETL integration products from EAI integration products (especially around XML and unstructured use cases)
5. Introduction of a new class of integration products that focus on the XML and unstructured use case. These “universal” data transformation products will allow transformations to be defined for all classes of data (e.g., structured, semi-structured, unstructured), without writing code, and deployed to any software application or platform architecture.

References
[1] Knightsbridge Solutions LLP – Top 10 Trends in Business Intelligence for 2006
[2] ACM Queue, Vol. 3 No. 8 - October 2005, Dealing with Semi-Structured Data (the whole issue)
[3] DM review - The Problem with Unstructured Data by Robert Blumberg and Shaku Atre, February 2003 Issue

Mashups and Situational Apps

Saturday, July 7th, 2007

Mashups both for prosumers (a new term that I had first heard from Clare Hart at the “Buying & Selling eContent” conference) - high-end consumers and creators of content and for scripters (my own term since I am not sure what exactly to call these high end-users - for example the departmental Excel gurus that create and manage departmental Excel scripts and templates).

The search for tools that empower these domain experts to create applications without programming has been around since at least the 80s (i.e.  4th generation programming languages) - which led to various new forms of application creation - but the only one that has really evolved into a “general use”  corporate tool for non-programmers has been Excel (though not really a 4GL). The reasoning behind those tools was to put the power to create appplications into the hands of the domain expert, and you will get better applications, faster. One new evolution of these types of tools are Domain Specific Languages (DSL) that make programming easier by focusing on a specific domain and building languages that are tailored to that domain.

So much for the history lesson - but what does that have to do with Mashups and  Situational Apps?  Well they both focus on pulling together different data sources and combing them in new ways in order to discover new insights. Mashups seem to be the preferred web term, Situational Apps is a term coined by IBM for the same tyoe of application in a corporate setting.

These types of applications (and application builders) have a lot in common:

1. They all start from a data feed of some sort. either RSS or XML.

2. They focus on ease of use over robustness.

3. They create allow users to applications easily to solve short term  problems.

Many of these tools are experimental and in the Alpha or Beta stage, or are Research projects of one type or another (QEDWiki, Microsoft Popfly, Yahoo Pipes, Intel MashMaker, Google Mashup Editor). As these tools start maturing, I think we will see a layered architecture emerging, especially for the corporate versions of these tools.  Here is how I see the corporate architecture layers evolving (click on the chart to enlarge it):

Mashup Layers

I think the layers are pretty self explainatory, except for the top-most Universal Feed Layer which is simply an easy way to use the new “mashup” data in other ways (e.g. other mashups, mobile).

If you look at the stack there are players in all layers (though most of the mashup tools I mentioned above are in the presentation and mashup layers), and the stack as a whole competes very nicely with a lot of current corporate portal tools - but with a much nicer user experience - one that users are already familiar with from the web.

One important issue that is sometimes overlooked is that mashups require feeds - and even though the number of web feeds is growing, there is still a huge lack of appropriate feeds. Since most mashup makers rely on existing feeds they have a problem when a required feed is not available. Even if the number of available feeds explodes exponetially there is no way for the site provider to know how people would like to use the feeds - so for mashups to take off, the creation of appropriate filtered feeds is going take on new importance, and the creation of these feeds is going to be a huge niche. Currently “Dapper” is the only tool that fills all the needs of the “universal feed layer” - site independence, web based and an easy to use, intutive interface for prosumers and scripters.