I have been thinking lately about decision support in business settings. Executives and managers make many, many decisions a day about the business – most of them involving other people that need to either be part of the decision making process, or act on the decisions. Essentially as an executive, you gather some data, meet with some people, make some decisions and then fire off some emails (or phonecalls) - repeat. From my experience, most processes in an organization are of this ad hoc flavor – and really have no tools (except email) for supporting the end-to-end process (from an ad-hoc set of decisions, through execution and finally to results)

There are various tools that help with the steps – for example I remember in the late eighties\early ninties decision support systems (DSS) used to be all the rage. The problem was that executives were unwilling to use the systems and they morphed into the Business Intelligence (BI) tools that all are the rage today (at least based on the number of acquisitions going on in that space). But, both DSS and BI tools address only part of the decision process – gathering and analyzing the data so that an intelligent decision can be arrived at. So those tools help with the “gather some data” part.

Another set of tools are collaboration tools, which can help somewhat with both the “meet some people” and “make some decisions” part. Other tools like Excel, Word, Powerpoint and email also play an important part in these steps. Most executives I know don’t use the various collaboration tools that are available - they use meetings, secretaries and productivity applications. Maybe they’ll start using Wikis too, but as another productivity tool - not an end-to-end decision support system.

Now if you believe the Business Process Management vendors the final step should be to create a process using your easy to use BPM design tool, and then have the process execute using your BPM (hey maybe even BPEL) engine. Yeah, right. BPM tools are heavy duty tools for the IT department, and are used to string together various IT assets. They don’t support the ad-hoc nature of most business processes, or the heavy (or perhaps exclusive) human interactions needed. Even the emerging area of Human-Centric Business Process Management (as coined by Forrestor) doesn’t fit the bill – they really don’t support the ad-hoc nature of most processes in an organization.

So where does that leave us? Essentially with meetings, email (sometimes phone calls and faxes) and productivity tools (ala Excel, Powerpoint, Word). That is how most business and business processes are done. I think this is main cause of email overload in organizations – and until some more natural mechanism for managing these ad-hoc business processes come along – the overload will only get worse…

An interesting article on email overload from First Monday.

I am revisiting the topic I mention in my previous entry on “Overconfidence and Entrepreneurial Behavior” because of an interesting post I found on the subject by Bob Warfield. He points at a study from the Harvard School of Business, that essentially comes to same conclusions about experience as the Israeli study in my previous post, but has some interesting insights that are useful to a first time entrepreneur.

First their definition of success is different than that of the Israeli study - success is effectively defined as an exit (closer to the hearts of most VCs than the definition used by the Israeli study). Here is my summary of their findings:

1. Entrepreneurs who succeeded in a prior venture (i.e., started a company that went public) have a 30% chance of succeeding in their next venture. By contrast, first-time entrepreneurs have only an 18% chance of succeeding and entrepreneurs who previously failed have a 20% chance of succeeding.

To be honest the relations seem about right - though the actual numbers seem a bit high, but maybe it isn’t if you take into account that an exit doesn’t necessarily mean that money was made.

2. Companies that are funded by more experienced (top-tier) venture capital firms are more likely to succeed. This performance increase exists only when venture capital firms invest in companies started by first-time entrepreneurs or those who previously failed. Taken together, these findings also support the view that suppliers of capital are not just efficient risk-bearers, but rather help to put capital in the right hands and ensure that it is used effectively.

This is really important news for entrepreneurs (since you really can’t just increase your own experience) - if you don’t have the experience yourself, you should “buy” it. Choose your investors not just on the basis of money, but on the basis of their experience, and how much of that experience they are willing to put into a company (one day a month just isn’t enough). Or, if you can then you should hire the experience even though it is expensive. If you look at the numbers in the study - by getting the appropriate experience on board - you can increase your chances of success by 7%-12%

3. The average investment multiple (exit valuation divided by pre-money valuation) is higher for companies of previously successful serial entrepreneurs.

in other words - by getting the appropriate experience on board, you can not only increase your chances of success - but leave more money in your pocket when you are successful.

So for me the study proves the model that we are using at eXeedtechnology, while expensive, is the right model for entrepreneurial success (early heavy involvement of experienced industry veterans as an integral part of the startup). While it doesn’t increase your chances of a home run (which seems to be heavily predicated on luck) – it significantly increases your chance of a successful exit.

I have been musing lately about the connection between software delivered as a service and hardware virtualization. For me they are two sides of the same coin (I guess we could have just as easily called it Hardware-as-a-Service and Software Virtualization). The simplest way to implement a SaaS’ified version of an existing application is via Virtualization – just run as many instances of the application (or application components) as needed, each in their own virtual machine.

The down side is that this may not be very cost effective. First, you need to be able easily deploy and manage new instances of the application within you virtual environment (and hence VMWare’s acquisitions of Akimbi and Dunes), have a appropriate pricing model for the various components technologies that make up the application, and the ability to easily monitor the virtual vs. real machine resources needed for the application.

It is not always easy to reconcile the software component models with virtualization. Many traditional software vendors charge per instance of their application deployed on a server. So if you want to deploy a DBMS for each instance of the application – the price can be quite prohibitive. It would probably depend heavily on the number of users per instance, but for many SaaS applications there are only a few users per instance. You could rewrite the application so that you could use a shared DBMS, having each application instance use a different DB in the DBMS – but rewriting an application is very costly.

Monitoring all those instances isn’t easy either. You somehow need to correlate all the virtual instances with the physical resources on the machine. One of the key reasons to virtualize is to be able to use machine resources (especially the CPU) more effectively – which means you want to load as many instances as possible before having to buy a new machine – very different then what is available from today’s monitoring tools.  A good overviewof these issues by Bernd Harzog can be found here.

So what’s my point? I think that we’ll see SaaS take-off when it really easy to take an existing app, and created a SaaS’ified version of it – and that will happen when it is as easy as taking a “virtual version” of the application and deploying it for “tenant” as needed. We are still missing some pieces of the puzzle for that to happen, but my guess is that we will see it happen in the next couple of years.

I have been blogging for a while now, and like everyone else I used to look at metrics everyday, now I look at them every once in awhile. What struck me most about traffic (and hopefully readership - since I can only know that users looked at the site, not whether they read it ) - is that the more you talk about currrent events the more traffic you get.

The blips that I saw on traffic were always around my blogging on topics that were just discussed by other sites, or events that just happened - rather than the blogs on general topics (e.g. the blog post on Mashup camp got a lot more traffic than my posts on Integration and M&A).  The traffic blip is of course even more pronounced if you comment or link-back to the main sites that discussed the event themselves.

This probably isn’t earth shattering news to most bloggers - but the heavy traffic to current event bias suprised me.

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.

I was looking around at some sites and was reminded of some older, but still relevant work done by the Stanford Persusive Technology lab on web credibility. I would have like to see the research updated to include some guidelines for UGC (User Generated Content) sites - but even so it is still very relevant. There are also a nice set of charts that describe captology here,  and web credibility here.

Another reason that I was reminded of the persuasive computing work is that I keep hearing from Israeli VCs the notion of “ease of use” being a key ingredient in the Web 2.0 world, and you need to make sure that Web 2.0 enterpreneurs understand that. IMHO that is a mistake - ease of use is the minimal bar - without that you don’t get to play… The real need is to make sure that developers and designers  understand that the real goal is “Joy of Use” - sure it has to to be easy and intuitive to use, but users also need to have fun using the technology - otherwise you won’t succeed.

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 2^nd a 3^rd 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.

I just read an interesting post on The state of Enterprise 2.0 and it seems like the various technologies that make up Enterprise 2.0 (RSS, Blogs, Wikis, Mashups, Communities) seem to be gaining acceptance and some traction in the enterprise.  Not surprising - I think the big losers will be the traditional enterprise portals. At the moment you can’t really find a complete Enterprise 2.0 stack, but it is clear that the writing is on the wall - and the Enterprise\Web 2.0 versions of the stack are much more useful, entertaining and engaging then the standard enterprise portal solution.

As I stated in an earlier post the Web 2.0 world is starting to penetrate into the enterprise, defining new ways to collaborate and raising ease of use expectations - things that are not usually at the forefront of existing enterprise portal technology.There was one specific quote in the article that intrigued me “The biggest impact of this lesson is that these new tools are so different and generally support such different types of knowledge than usually captured, that impact to existing systems seems to be minimal. Interestingly, you might see a decrease in the use of e-mail or ECM when the conversations that formerly happened on those platforms make a more natural home in Enterprise 2.0 platforms” (the emphasis is mine).  This got me thinking, since one of the main selling points of Web 2.0 technologies is that they will eliminate (or at least substantially decrease) email usage.  I have never seen any numbers to bear out this claim. My gut tells me that the number of emails in enterprises is growing, not shrinking (see “Intel flirts with No Email Fridays” for at least anecdotal corroboration), and I just don’t see why these technologies will change that substantially. Enterprise 2.0 technologies  may end up slowing the growth of email a bit, but are certainly not turning the tide.

My guess is that email is too pervasive, too general, too useful and too simple a tool to ever be replaced. I only wonder if as with the “paperless office” - where computers and technology were going to replace the need for paper, but instead only seemed to increase its usage - enterprise 2.0 technologies won’t actually generate additional uses for email…

I am not sure why we haven’t heard more about the effect of the sub-prime mortgage crisis on startups and VCs, but it seems clear to me that we will see an effect. The bad 3Q results (and bad 4Q forecasts) for many financial institutions will have a delayed effect on many later stage enterprise software startups. 

The Finance industry is a very large consumer of technology, and in many cases willing to be an early adopter of interesting technology. Of course, as with any downturn, new initiatives are always an easy target, and usually the first to go. Many enterprise software startups pin their hopes on selling their products to large US financial institutions. Those that have already signed deals- congratulations! Those that have deal propects in the pipeline, but haven’t signed the deal - don’t count your chickens, at least until the banks start growing again. 

No matter how the larger economic issues play out - the subprime  mortgage crisis will be a bad deal for startups.

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.