Thursday, September 27, 2007

Take a pass on proprietary platform SaaS

Recently there have been a slew of announcements in a category that could be called Platform as a Service. SalesForce launched their new platform last week, and companies like Coghead and Teqlo have entries in this arena as well.

The details differ, but each Platform as a Service vendor provides roughly the following:
  • Web based development tools: graphical environment for building business productivity apps and deploying them immediately to an on-demand server.

  • Proprietary server technology: the applications and data are locked into a unique SaaS environment. Goodbye any hope of managing IT standards consistently!
Haven't we seen this movie before and doesn't in end in tears? For example, how many people still think SAP's ABAP is a good idea? In return for short-term pleasure (easy to build apps, don't have to worry about deployment), I let myself in for a long-term world of pain (including security, data quality and integration challenges).

Why would any enterprise want another company to have semi-exclusive control of their business logic and data?

To be sure, the SalesForce platform may well be an excellent way to extend existing SalesForce applications, as ZDnet points out here. It does not make sense, however as a stand-alone platform, particularly in comparison to more accepted platforms like J2EE and .NET.

At ActiveGrid, we believe that the whole distinction between on-site and on-demand deployment is an artifact of poor tool design. The next generation of web development tools will make it transparent whether you are deploying to your desktop, to the data center or to a SaaS hosting environment like Amazon's Electric Compute Cloud. Programmable web has a nice summary of EC2 applications here.

The next generation of virtualization will occur when enterprise developers can make on-the-fly decisions about whether to host applications on-site or on-demand. Put succinctly, SaaS manageability goodness is not enough to overcome proprietary badness.

Wednesday, September 19, 2007

Social media hangover - why can't we all just be friends?

Just like in the 60's (but I suspect we had less fun this time around), social media excess has inevitably led to social media disillusionment.

As all technical wonders, it started with the delight of seeing how many people want to be your friend, some of whom you actually know. There was also the added titillation of all those MySpace friend requests from users with names like Lola, Estelle and Nichole.

Of course it all had to end in tears, as we found that our LinkedIn friends were only using us to get a new job, that our Facebook friends were only using us prove that they were still more popular than us and that our MySpace friends charged for their services.

Or in kindergarten terms, we have gone from wandering all over the playground asking everyone else, "will you be my friend" to the pre-emptive exclusion of sitting in the corner and declaring "you're not my friend" to all comers.

The behavior that constitutes friendship varies dramatically based on context. My favorite example was when my sister was in 2nd grade and arrived home announcing that she had a new boyfriend. When I asked her how she knew, she replied "he's my boyfriend because he threw a pear at me on the way home."

Every context has different rules for being "friends" - much of the fun of social media is that we are getting to live through a global learning process around the rules that apply to friendship in a variety of new communication environments. As Rob La Gesse points out here,

This goes back to "context" - something these social network sites are not managing very well. I should be able to check my levels of interest in various aspects of soccer (player, coach, parent, investor, etc) and communications and friend requests should take this information into account when handling requests.

ps Thanks to Shel Israel for kicking off this train of thought with a question he posted on Facebook here.

Saturday, September 15, 2007

We liked TurboAjax so much…we bought the company

Over the next few months, almost everything about the company-currently-know-as-ActiveGrid will undergo dramatic transformation. We are announcing the first step in this transformation on Monday with our acquisition of a top Dojo tool provider, TurboAjax.

TurboAjax brings an incredibly cool Dojo widget builder and equally talented developers into ActiveGrid. We first saw their products on July 26 and had a signed Letter of Intent exactly one week later - probably a land speed record for software acquisitions!

This acquisition also lands us at the center of the Dojo community of AJAX developers. Why Dojo? Well, we are targeting the enterprise, where internationalization and security are critical. We believe Dojo is creating the best UI toolkit for enterprise developers.

Earlier this week I waxed eloquent on the flaws in proprietary non-AJAX solutions like Silverlight, Flex and JavaFX. However it is also fair to point out that there are many challenges within the open source AJAX community as well, including:
  • Lack of commercial support: without the availability of commercial support, AJAX will not achieve enterprise adoption. With this acquisition, ActiveGrid will now stand behind both the TurboAjax products and the Dojo Toolkit.

  • Missing features: common complaints around the Dojo toolkit include lack of complete documentation and robust samples. If AJAX toolkits are to be adopted, they need the same polish as proprietary solutions like Flex.

  • Inconsistent standards: as the saying goes, the nice thing about AJAX standards is that there are so many to choose from. There is an alphabet soup of Javascript libraries out there, including JQuery, Prototype, Rico, Scriptaculous, Ext and YUI. Each of these takes a very different approach to solving the same problem.

  • Security: don't even get me started on the security challenges in an environment full of widgets, gadgets and 3rd party web services. Suffice it to say that when this rock gets turned over, lots of ugly stuff creepy-crawly things will slither out.
The AJAX world needs a RedHat to create a common distribution and provide commercial support and training behind an enterprise-ready toolkit. With our TurboAjax acquisition, ActiveGrid is taking an important first step down this path. Stay tuned for our next move!

Thursday, September 13, 2007

Really Idiotic Approaches to RIA: Flex, Silverlight and JavaFX

I just waded through a good article in DevX by Alexey Gavrilov on building Rich Internet Applications with Adobe Flex, Microsoft Silverlight and Sun JavaFX. The article worked step-by-step through how to build simple web applications with each of these products.

I had expected that there was some connection between Web 2.0, open source and the leaders in RIA. Instead, I found a set of time-warp technologies, each embodying its own uniquely idiotic approach. For the sake of brevity, I will here summarize the crowning idiocy of each approach:
  • The fat-client approach. Microsoft has determined that the only problem with browser-based apps is that it doesn’t run fat client apps. Silverlight fixes that bug.

  • The supermodel approach. Adobe was so entranced with the beauty of Flex’s audio-video capabilities that they forget to add little things like the ability to work with strings or dates.

  • The once more with feeling approach. Sun decided to take another stab at making good on their most famous lie about Java, “write once, run anywhere.” Unfortunately for them, the Javascript Genie is out of the bottle.
None of these approaches supports Javascript as the primary scripting language. Don’t tell Adobe, Microsoft or Sun that Javascript is hot and that those crazy open source people are starting to assemble lightweight applications to run in web browsers.

Having said all this, the open source AJAX community has plenty of work to do in cleaning up its own house. The good news is that if this is what we’re fighting against, we have only ourselves to blame if the evil scientists win!

Monday, September 10, 2007

Google - the platform cometh

Nicholas Carr covered the recent Google/Capgemini partnership announcement here. We are seeing an "Innovator's Dilemma" market appear before our eyes - cheap but underpowered Google apps against expensive, full-featured Microsoft apps. While the feature bigots laugh, Google apps will creep into the corporate IT fabric around the edges.

It will be interesting to see how the SIs start to knit Google apps into the corporate IT environment. There will be an opportunity to create the equivalent of's App Exchange around Google's apps/gadgets/storage. By driving an on-demand platform into Microsoft's turf, Google accomplishes two goals:
  1. Keep Microsoft off balance so they can't put all their efforts into taking on Google in Search
  2. Open up a "protected" market where Microsoft can't follow without undermining its own desktop business
Google recently announced pub/sub gadgets, which makes their potential role as an enterprise platform provider even more interesting.

Friday, September 07, 2007

Trick question: what is the most valuable database in the world?

I sit on the board of Kapow, a company that allows you to turn anything on the web into a data source.

As a thought experiment, I asked their executive team to tell me the most valuable database on the planet?

Here are some potential winners:
  • D&B - all the financial data you could hope for - nope
  • IMS - all the medical data you could uncover - nope

And the answer is...Google (is it my imagination or is the answer to almost every question these days Google?) The point is that the really valuable information is increasingly moving to the web. That means that the next generation of data adapters will treat the web as a gigantic database (albeit one that requires clever robots from Kapow to take full advantage of).

For example, when the National Oceanic and Atmospheric Administration (say that 3 time fast) wanted to put together the definitive global warming portal, they found that the best information was all on the web, and turned to Kapow to get that information into a single portal.

Wednesday, September 05, 2007

5 Show-Stoppers That Cause Enterprise 2.0 Apps to Fail

I had a great conversation today with one of my blog-heros, Jeff Nolan. Jeff recently finished a stint as the CEO of Teqlo, a pioneer in hosted tools for building Enterprise 2.0 applications. Others in this space include Coghead and Bungee Labs.

The nirvana we are all shooting for is a world where developers can assemble useful business applications with minimal coding or scripting. The idea is to take simplify certain tasks that are hard to do with code (e.g., visual assembly of page layouts, hooking controls to services) without making it harder than normal to do the things that will always have to be done with some sort of logic. The reality to date has fallen short of this nirvana.

We identified 5 reasons that Enterprise 2.0 apps today often fail to live up to the hype:

1. “Slowest man sets the pace.” Chaining together service calls to build applications creates bottlenecks where the slowest service call tanks the performance of the whole application.

2. Look but don’t touch widgets. Although this is changing (see here for the latest on Google’s pub/sub widgets), the vast majority of widgets can’t exchange data. This allows for an infinite variety of cute clock and horoscope widgets, but a paucity of useful business functionality in widget form.

3. Web service alphabet soup. There are a number of web service standards and even within a standard there are few rules for how the standard should be applied. This means that creating widgets to integrate web services is unexpectedly time consuming.

4. Still too darn hard. The world of widgets and building AJAX apps is still far too complicated for the typical end user developer. Current state of the art tools still require a knowledge of IDEs, standards and languages far beyond the grasp of casual developers.

5. Service throttling. At ActiveGrid, we have found that a number of web services like Google Maps are easy to mash-up for demo apps but much, much harder to use for doing real work. Given that Google has to pay for all the servers, it is easy to see why they would want to encourage people to use their web services in non-intensive ways.

Jeff believes a big market lies in creating “people, place, thing” applications like project management and time tracking. I would add that the killer app is tying Internet data presentation and collection with email workflow – sort of an updated Lotus Notes.

The market and the tools are evolving quickly, so in six months the landscape will look fundamentally different. For now, however, the vision of idiot-proof assembly of Enterprise 2.0 apps using rich business widgets has yet to be fully realized.