Big Data is a Small Market Compared to Suburban Data

Big Data is all the rage, and seem to be one of the prime targets for new entrepreneurial ventures since VC-dom started to move from Consumer Internet to Enterprise recently.  Yet, I remain skeptical about Big Data for a variety of reasons.  As I’ve noted before, it seems to be a premature optimization for most companies.  That post angered the Digerati who are quite taken with their NoSQL shiny objects, but there have been others since who reach much the same conclusion.  The truth is, Moore’s Law scales faster than most organizations can scale their creation of data.  Yes, there are some few out of millions of companies that are large enough to really need Big Data and yes, it is so fashionable right now that many who don’t need it will be talking about it and using it just so they can be part of the new new thing.  But they’re risking the problems many have had when they adopt the new new thing for fashion rather than because it solves real problems they have.

This post is not really about Big Data, other than to point out that I think it is a relatively small market in the end.  It’ll go the way of Object Oriented Databases by launching some helpful new ideas, the best of which will be adopted by the entrenched vendors before the OODB companies can reach interesting scales.  So it will be with Hadoop, NoSQL, and the rest of the Big Data Mafia.  For those who want to get a head start on the next wave, and on a wave that is destined to be much more horizontal, much larger, and of much greater appeal, I offer the notion of Suburban Data.

While I shudder at the thought of any new buzzwords, Suburban Data is what I’ve come up with when thinking about the problem of massively parallel architectures that are so loosely coupled (or perhaps not coupled at all) that they don’t need to deal with many of the hard consistency problems of Big Data.  They don’t care because what they are is architectures optimized to create a Suburb of very loosely coordinated and relatively small collections of data.  Think of Big Data’s problems as being those of the inner city where there is tremendous congestion, real estate is extremely expensive, and it makes sense to build up, not out.  Think Manhattan.  It’s very sexy and a wonderful place to visit, but a lot of us wouldn’t want to live there.  Suburban Data, on the other hand, is all about the suburbs.  Instead of building giant apartment buildings where everyone is in very close proximity, Suburban Data is about maximizing the potential of detached single family dwellings.  It’s decentralized and there is no need for excruciatingly difficult parallel algorithms to ration scarce services and enforce consistency across terabytes.

Let’s consider a few Real World application examples.

WordPress.com is a great place to start.  It consists of many instances of WordPress blogs.  Anyone who likes can get one for free.  I have several, including this Smoothspan Blog.  Most of the functionality offered by wp.com does not have to coordinate between individual blogs.  Rather, it’s all about administering a very large number of blogs that individually have very modest requirements on the power of the underlying architecture.  Yes, there are some features that are coordinated, but the vast majority of functionality, and the functionality I tend to use, is not.  If you can see the WordPress.com example, web site hosting services are another obvious example.  They just want to give out instances as cheaply as possible.  Every blog or website is its own single family home.

There are a lot of examples along these lines in the Internet world.  Any offering where the need to communicate and coordinate between different tenants is minimized is a good candidate.  Another huge area of opportunity for Suburban Data are SaaS companies of all kinds.  Unless a SaaS company is exclusively focused on extremely large customers, the requirements of an average SaaS instance in the multi-tenant architecture are modest.  What customers want is precisely the detached single family dwelling, at least that’s what they want from a User Experience perspective.  Given that SaaS is the new way of the world, and even a solo bootstrapper can create a successful SaaS offering, this is truly a huge market.  The potential here is staggering, because this is the commodity market.

Look at the major paradigm shifts that have come before and most have amounted to a very similar (metaphorically) transition.  We went from huge centralized mainframes to mini-computers.  We went from mini-computers to PC’s.  Many argue we’re in the midst of going from PC’s to Mobile.  Suburban Data is all about how to create architectures that are optimal for creating Suburbs of users.

What might such architectures look like?

First, I think it is safe to say that while existing technologies such as virtualization and the increasing number of server hardware architectures being optimized for data center use (Facebook and Google have proprietary hardware architectures for their servers) are a start, there is a lot more that’s possible and the job has hardly begun.  To be the next Oracle in the space needs a completely clean sheet design from top to bottom.  I’m not going to map the architecture out in great detail because its early days and frankly I don’t know all the details.  But, let’s Blue Sky a bit.

Imagine an architecture that puts at least 128 x86 compatible (we need a commodity instruction set for our Suburbs) cores along with all the RAM and Flash Disc storage they need onto the equivalent of a memory stick for today’s desktop PC’s.  Because power and cooling are two of the biggest challenges in modern data centers, the Core Stick will use the most miserly architectures possible–we want a lot of cores with reasonable but no extravagant clock speeds.  Think per-core power consumption suitable for Mobile Devices more than desktops.  For software, let’s imagine these cores run an OS Kernel that’s built around virtualization and the needs of Suburban Data from the ground up.  Further, there is a service layer running on top of the OS that’s also optimized for the Suburban Data world but has the basics all ready to go:  Apache Web Server and MySQL.  In short, you have 128 Amazon EC2 instances potent enough to run 90% of the web sites on the Internet.  Now let’s create backplanes that fit a typical 19″ rack set up with all the right UPS and DC power capabilities the big data centers already know how to do well.  The name of the game will be Core Density.  We get 128 on a memory stick, and let’s say 128 sticks in a 1U rack mount, so we can support 16K web instances in one of those rack mounts.

There will many valuable problems to solve with such architectures, and hence many opportunities for new players to make money.  Consider what has to be done to reinvent hierarchical storage manage for such architectures.  We’ve got a Flash local disc with each core, but it is probably relatively small.  Hence we need access to storage on a hierarchical basis so we can consume as much as we want and it seamlessly works.  Or, consider communicating with and managing the cores.  The only connections to the Core Stick should be very high speed Ethernet and power.  Perhaps we’ll want some out of band control signals for security’s sake as well.  Want to talk to one of these little gems, just fire up the browser and connect to its IP address.  BTW, we probably want full software net fabric capabilities on the stick.

It’ll take quite a while to design, build, and mature such architectures.  That’s fine, it’ll give us several more Moore cycles in which to cement the inevitability of these architectures.

You see what I mean when I say this is a whole new ballgame and a much bigger market than Big Data?  It goes much deeper and will wind up being the fabric of the Internet and Cloud of tomorrow.

Saw the Microsoft Surface Tablet and Liked It

I was at Houston’s Galleria mall during the Thanksgiving weekend and got a chance to spend some time in both the Microsoft and Apple stores there.  I had read a few articles praising the device, such as Jeff Atwood’s piece (which fairly gushes), but was skeptical.  I’m not at all an Apple Fan Boy nor a Windows Fan Boy.  There are things I like about each platform and things I don’t like.  I loved the 17″ Mac Power Book I had at my last job, but hated its lack of Del and other keyboard keys I’m used to as well as its $4000 price tag (the reason I didn’t buy one after leaving and probably the reason they didn’t let me keep theirs, LOL).  I love my iPad and my iPhone, but I stubbornly stick to having the most-powerful Windows machine I can buy (actually build) on my desktop.  I really dig the Apple monitors, and will eventually have to deal with writing the check for one to attach to my crazy homebuilt PC.  You get the idea–I’m all about Best of Breed for each device.

Putting that all aside, I walked into the Microsoft store with an open mind and low expectations.  The first bit of good news and bad news was there weren’t many people there so I got to spend a lot of time with the Surface RT and equally I had a very helpful salesperson do a demo so I didn’t have to struggle learning all the secret gestures folks are complaining about.  It didn’t take long to figure it out and once having done so, I don’t think I’d mind Windows 8 at all.  The biggest issue with it is what others have already said–it’s intended to be used in a touch environment and if you don’t have a touch screen, you’ll be left continually wishing you did.  The bad news was that there weren’t many people.  I went from the Microsoft store to the Apple store within the span of about 45 minutes and the Apple store was completely mobbed.  The big attraction was the tablets, and I got a good look at the new iPad Mini which was also very cool, but I didn’t get to put hands on to any of the pads.  There was a line everywhere I looked.  Clearly the world is thoroughly pre-conditioned at this stage not to bother even stopping in at the Microsoft store, which is a major problem they will have to fix.

Getting back to the Surface RT, I spent a good 20 minutes with it, including the demo.  I got to try both keyboards.  The short story on the keyboards is that they’re both light years ahead of Apple’s touch screen keyboards which I universally hate and avoid unless I absolutely have to get text into one of the devices.  The iPad is truly read only for me.  I will triage email so that anything requiring more than a sentence is left starred in Gmail and waiting for me to get back to my desktop.  With the Surface RT, not only could I type without a problem on either keyboard, but I was doing so in Microsoft Word.  What a joy for someone who writes as much as I do!  The Touch Cover is the thinnest and comes in all those crazy colors.  It’s actually not to bad and I found I could touch type decently on it.  I had read complaints about keys being in weird places and such, but didn’t really notice a problem there.  However, the Type Cover was a revelation because it is a real keyboard.  I had to keep lifting it up to check how thin and light it is because I couldn’t believe they could build that nice a keyboard without having it weigh down the Surface too much.  It’s not a problem.  By all means, try out both, but if you’re anything like me, you’ll want the Touch Cover.

The overall device is super slick.  Apple has little or nothing on Microsoft in terms of the hardware aesthetics.  The touch screen looks great and works great.  I know it isn’t a retina display, but frankly, it looked fine to me.  I loved having access to MS Office, and the demo person was quick to point out that there is a tile that corresponds to the Start menu, so all that gnashing and moaning about the demise of the start menu seems unfounded.  I suspect there are probably some subtle differences that will occasionally be maddening, but it all seemed to hang together really well.

Based on this experience, there were really only two issues I could identify with the Surface.  First, this was a Surface RT, and you really want a Surface that’ll run any Windows software.  That’s coming, and the demo person actually steered us to think hard about waiting for it.  She was very straightforward about trying to understand what we wanted to use the device for, and one of us was looking for a much lighter and slicker alternative to a laptop.  When further queried on which apps she runs most of the time, the salesperson told us the upcoming device would be much better for her.  I think that’s probably true for me too, so I’ll be waiting for the “real” Surface to make a purchase.

The second issue was the troubling difference in traffic to the Apple Store versus the Microsoft Store.  It doesn’t matter how great the device is if nobody knows about it.  It’s early days yet, but I’ll make a prediction.  Once people start seeing the Surface (and not the RT) turning up in work situations and people find it is far lighter but works just as well as a laptop, that’s when it will take off.  It’ll be the workhorse device for what we all used to call Knowledge Workers.  I think Microsoft will have a very nice level of success with it if they handle it reasonably well.  There are shades of the old, “Microsoft wins with the Third Release” rule, and this time it is taking 2 releases as the RT is not the winner.  It’s just kind of a placeholder platform that shows the potential.

The real interesting story will be watching how Apple responds.  Despite all the kvetching about Windows 8, Microsoft now has a unified platform that spans devices.  Yes, it has a UI tuned for tomorrow’s PC’s moreso than today’s through it’s extensive optimization for touch, but historically, betting that tomorrow will get here sooner than expected has been a good bet.  Steve Jobs had been known to roll those very same dice more often than not.  Apple has the challenge that OS/X and iOS are not a unified platform.  They’re vaguely similar platforms.  For now and some time, they have the luxury that their installed base is so large most developers will build for iOS first.  Win 8 has the luxury that a ton of software is already built for it.  It also has the luxury of potentially being the best corporate or business platform.

The other interesting story will be watching who patented what.  Clearly Apple and Microsoft both have huge patent portfolios.  If Apple can patent rectangles with round corners maybe Microsoft can patent tablets with built-in keyboards.  If one gets a decisive patent wedge in, that’ll make it much harder for the other.  I hope there isn’t too much of that because I am firmly in the camp that patents stifle innovation.

It’ll be a great competitive race and consumers can’t help but win from it.

The Two Most Desirable Features of a Platform as a Service

Big Data?

Multitenancy?

Uber DB scaling?

Mad Hadoopishness?

Faster app development?

Universal Social Connectivity?

Not so much.  Some platform or other claims all of those things, but the two most desirable features of a PaaS appear to be revenue generation and commodity pricing, not necessarily in that order.

Let me first say that I’ve come to view AppStores as PaaS offerings of a sort, and their ability to generate revenue for developers drives those developers into their arms.  This also applies to more traditional PaaS offerings such as Salesforce’s Force.com.  As nearly as I can tell talking to folks and scanning the blogosphere for activity, people write for Force.com either because they need to integrate with the Salesforce CRM app or because they want the revenue tailwind you can get via Force.com.

The commodity pricing piece applies to what many prefer to call IaaS, or Infrastructure as a Service, with  Amazon Web Services being the most widely used example so far.  Let’s go ahead and keep them in our PaaS list for this discussion and ignore the IaaS moniker.  If we start cutting out things like Amazon and Force.com for various reasons, there is so little left it’s hard to talk about it.  I would submit we may have divided up the market into too many A-A-S’s a little prematurely without waiting to see what would stick.

This is the gist of my problem, BTW.  There’s been plenty of time for PaaS to get big, but it is kind of lumbering along.  Yes, we get things like Heroku.  Doesn’t that qualify largely under the Commodity category though?  Force.com we’ve already talked about and Amazon too.  But in this Cloudy-Cloudy-*aaSy-*aaSy world, what else is flying high?  There’s room for a ton of things, but you have to solve the revenue and commodity checkboxes first.

Here is the problem for all you would-be PaaS vendors out there–it’s darned hard to get design wins if your platform involves heavy lock-in, heavy rewriting, too much cost, or isn’t otherwise a requirement for a Minimum Viable Product.   Yup, there’s that darned MVP concept rearing its ugly head again.  The trouble is, it’s no longer just something the Cool Kids bandy about while sipping lattes.  It’s become something of a requirement for survival and an article of How Things Are Done In The Valley.  You can’t get capital to fool around with fancy products any more, so you have to go MVP all the way because you’re likely starving on your own nickel until you do.  In addition to the VC’s, Agile thinking and a general suspicion of Premature Optimizaton have really made it hard to sell Feature Density.  The trouble with that list of things at the top is they’re either not that commonly needed, they involve dealing with scale you should be so lucky as to get to (and are therefore not MVP material), or they solve problems you’re convinced you can easily solve as you’re starting your journey (e.g. multitenant).  Yes, those problems are harder than you think, but it doesn’t matter.  They don’t look harder when you’re eyeing what it takes to get an MVP off the ground.

PaaS vendors, you have a couple of choices available to deal with this.  You can ignore it, argue that it’s early days yet and your time will come.  It’s pretty hard to dispute that because it is early days yet.  But don’t get too target fixated at such an early stage either lest some upstart take the early days away.  You can still be Zucked pretty darned easily precisely because it is early days.  Note: To be “Zucked” is to be treated to the same fait Facebook dished out to MySpace.  Call it Fast Follower on Steroids with a Heavy Case of Rabies.  It’s not a pleasant thing to happen to your life’s dream.

Okay, so what’s the alternative for would-be PaaS Masters of the Universe?

Hey, this is a good time for the Cloud.  You know that.  We hear less and less whining about security and all that.  Clever marketers are even now letting IT get just a little bit infected with “Private Clouds”, a potent Trojan Horse strategy to win over their hearts and minds.  Whatever it takes, resistance is futile.  Once their apps and data are on my servers it’s only a matter of reconfiguring the subnets and voila!  All your Apps are be in my Cloud!

Given that is the case, there may be some first mover, network effect, and momentum issues to think about.  In other words, stop being so darned pure to your vision and line up as many customers as you can as fast as you can.  That’s how we win in this part of the Bubble, um I mean Business, Cycle.

What the heck does that mean?

I’m glad you asked, but it should be obvious:  PaaS vendors need to embrace these two desirable features and nail them before worrying about much else.  There are two simple questions:

1.  Are you directly delivering revenue producing traffic to your customers by virtue of some aspect of your PaaS?

2.  Do you have an offering that lets people buy into some commodity-priced-let’s-get-started-without-boiling-the-ocean version of your PaaS?

If you do, Hallelujah Brothers and Sisters!  You have a shot at the promised land and you can now start looking at more potent differentiation rather than table stakes.  If you don’t, back up and let’s figure something out, because this PaaS stuff can turn into a Darwin Test if you’re not careful.

There is room for innovation on the commodity side, but it’s getting harder.  The days may be gone when you can deliver commodity infrastructure.  Storage and CPU like S3 and EC2, in other words.  If you aren’t already spun up and doing good things, you need to start skating where the puck is going to be.  I have offered up my PaaS-as-bite-sized-pieces strategy before (Sell the Condiments, not the Sandwiches).  Check it out.  Lots to commoditize there.

There is also room for tons of innovation on the “delivering revenue producing traffic” front.  We’ve seen it for mobile platforms, in fact, one could argue the appstores are the defining element there coupled with the relative desirability of the platforms to their users.  The participants seem to be pretty mercenary about those two related dimensions.  I am mystified about why Amazon, which ought to understand App Stores better than anyone, is not doing so great with their Android App Store and doesn’t appear to have one at all for Amazon Web Services.  The latter is inexcusable.  There’s got to be all sorts of opportunity to create an App Store there.

Salesforce keeps wanting to be a major PaaS vendor, but they somehow misunderstand the data they were among the first to collect.  Yes, they do have the revenue producing traffic piece nailed.  But, they seem to be very much in denial about whether that is the main reason people will use Force.com, and totally opposed to solving the commodity issue.  Every time I talk to an entrepreneur or investor that wonders whether they should use Force.com or one of its offshoots, I ask them to consider a simple thought experiment.  Look up Salesforce’s current cost of service as a percentage of revenue.  Take the cost they will be charged to use Force.comand divide by SFDC’s cost of service.  That number is what they must charge to have the same margins as Salesforce, and that assumes they don’t spend another dime on anything else to deliver their service.  Most of the time that makes for a short conversation.  Oh, I didn’t think about it like that.  There’s no way we can be competitive if we have to charge that much.  And so it goes with a lot of other PaaS offerings too, BTW.  Perhaps Heroku is their way of covering both bases and a sign that they do understand.

For other PaaS vendors, maybe there is a sliver of hope.  If you can change that cost of service to be cost of service plus some cost of marketing, because the PaaS will deliver revenue producing traffic, you can afford to pay more.  Heck, Steve Jobs gets 30% just for delivering the traffic and not helping you in much of any other way.

The revenue producing traffic is by far the hardest thing to do.  You can’t materialize it out of thin air.  You either already have a solid traffic stream you can repurpose (that’s what Salesforce did), or you may have to look at partnering opportunities.  For those that have a stream, now is your chance to enter the PaaS business in an interesting way.  Casting eyes around, Adobe is well positioned for this.  Get an AppStore together, Adobe, and link your dev tools and *aaS efforts to it.  There are bound to be others too.  Open Source vendors in the tools business, maybe you have this sort of opportunity as well.  IBM, Oracle, HP, and whomever else this is a huge opportunity for you.  Maybe Cisco too as I think about it.  Trouble is, your Big Sales Force may think it hampers them in some way.  Ignore their parochial interests and charge ahead.  This is a Silver Bullet for PaaS and Cloud ascendancy.

Give it some thought.  It’s high time for some break out PaaS action.

Remember HP’s New Wave? Here We Go Again!

Sam Diaz has gotten clarification on the future of Windows in the light of their Web OS announcements.  It should come as no surprise that Windows isn’t going anywhere, and certainly won’t be replaced by Web OS any time soon.  Instead, HP is saying:

HP will integrate the WebOS experience into Windows, but not through virtualization. He said: “…it will be a combination of taking the existing operating systems and bringing WebOS onto those platforms and making it universal across all of our footprint.”

Sounds great.  Been done before.  Remember HP’s New Wave?  It was a new object-oriented UI shell and mini-platform (we looked at possibly using it for our Windows apps at Borland but declined–not enough value add for the trouble) that HP launched way back in 1989.  They’ve been down this road before of trying to enhance Windows.

It’ll be interesting to see whether it works any better this time around.  Personally, I’m betting against.  The little things it adds that have been demoed so far are all obvious things Microsoft should be building into Windows and in fact will have to build if they want to make their Nokia partnership perform as it should.

This is more or less what happened to New Wave.  It introduced some cool stuff that Redmond promptly scooped up and marginalized through various releases of their own.  It’s good news for Microsoft though.  Their engine is not particularly innovative, but if someone else can show them what to do that’s in a format not too far removed from what they’re familiar with they will grind that stuff out like nobody else.  They’ve needed some of that help, though frankly it has been out there lately and Microsoft hasn’t bitten (Xobni, anyone?). 

Perhaps this will get their attention.

Scoble Discovers Developers are Schizo About New Platforms

I just listened to Scoble’s bar interview of @longview (Nick Long) and @renatto (Paul Robinett), two Dreamworks developers who are building a mobile app of their own.  They’re talking about the Mobile World, and there are some great sound bites coming from the interview.  BTW, the Cinchcast tool he used to do the interview was pretty cool.

These developers conclude Nokia-Apple are “screwed”, Android is the cutting edge, yada, yada.

Some key passages and ideas I’ve paraphrased: 

-  The constant refrain: “No one is developing apps for X”.

-  It’s costly to learn a new platform.  Android has Java.  If you know Java and have to learn Objective-C that’s hard and vice versa.  You have to hire a new programmer.

-  It’ll be hard for developers to straddle 2 platforms and 3 is impossible.  How can there ever be a #3 of any consequence?

-  You have to pay us up front enough so it wouldn’t matter if anyone bought the platform.  Because they can’t guarantee the distribution.

 - Cool is about openness, not about closed.  The big momentum is with Open on Android. 

-  The Cool Kids want to be on the cutting edge, but that’s slowing down a little bit for Apple.

-  When somebody builds the uber cool app on Android first, that shift away from Apple will be here.

-  Scoble’s advice to Microsoft, get rid of Windows and go XBox.  They may have been too long in the bar at this point!

-  What if the Apple store is full of hundreds of thousands of apps, and you’re lost in that sea of apps.  How about a marketing decision to launch on Google first so you stand out?

Takeaways for Once and Future Platform Kings

I am a developer and have worked with developers for my entire career in a variety of different markets.  I’ve also spent a lot of time doing the “impedance match” between marketing/sales and developers, and formulating winning product strategies in new markets.  Let me tell you it is an interesting challenge to juggle all of those balls just because of how the various players think and are motivated.  It’s worth getting behind the sound bites of this interview and understanding the developer, marketer, and strategic implications for companies who want to be Platform Kings.

Let’s start with the marketing / strategic perspective for the mobile world.  It’s all about the apps you have on phones, and Scoble gets this in a prior blog post very eloquently:

Nothing matters in this world more than apps. Write that on your forehead. Write that on the mirror on your bathroom wall. Write that on your car windshield. Whatever it will take so you remember it.

HP execs know this. Google’s execs know this. Everyone in Silicon Valley knows this.

Apps are the ONLY thing that matters now.

Why? Because when a customer, whether in Cape Town or San Francisco or Tel Aviv walks into a store to buy a smartphone they will NOT want to feel stupid.

What makes you feel stupid when buying a Smartphone? Buying one that doesn’t have the apps your friends are taunting you with.

Apps need a platform, so if you’re going anywhere in these markets, you’d better have one that will attract the right apps.  Unfortunately, it’s getting late to try to establish a new platform.  Why?  Because the developers are in control of whether or not apps will appear on your platform, and you will have a hard time attracting them.  Many companies are woefully unprepared for the idea that if they’re in the platform business, they actually have two sets of customers.  First are the people that buy the phones.  Those are the obvious customers, the ones marketers at companies like Nokia have built their entire professional careers learning how to deal with.  Second are the developers that bring the apps.  These are the customers many of these companies have no earthly idea how to deal with, yet they are the gate keepers for the apps.

So how do we think about developers as customers and how do we get them to adopt our platforms?

There are a very limited number of opportunities to attract developers because they are so schizoid about new platforms.  On the one hand, developers really hate having their expert status reset to beginner while they learn a new platform.  They may protest that its cool, they’re always learning new things, they love to learn, yada, yada, but they really hate the nuts and bolts of the learning.  This is a corollary of what happens when you give a developer somebody else’s code to maintain.  The code may have come from their most revered uber geek hero, but if they don’t know that’s the source, their first words on briefly looking over the code will be, “This code is shit–we have to rewrite it.”  Welcome to the real source of NIH.

So what will get a developer to voluntarily surrender his Uber Geek status for the time it takes to learn a new platform? 

There really are only two things.  Either that platform is so hot and sexy they will lose their Uber Geek status anyway if they don’t learn it, or the platform is so successful that profit motive dictates it must be supported.  Are you beginning to see the problem with introducing a new platform?  It hasn’t been around long enough for profit motive to kick in, so you have to make sure it isn’t just a little bit cool, it has to be ultimately way-over-the-top-super-duper-no-kidding-insanely-friggin-UBER COOL. 

This has been Steve Jobs genius.  He has managed to create such platforms multiple times in his career.  That’s no small accomplishment, and I don’t know whether we’ll ever see it again in our lifetimes from someone else.  The Apple II.  The Macintosh.  The iPod.  The iPhone. The iPad.  Dang Steve, that’s gettin’ jiggy with it.

When the corpocracy wants to roll out a new platform, that’s what they’re faced with.  There are a limited number of things the Corpocracy (my term for that faceless Big Business  thing the lady in the Apple 1984 commercial threw her hammer at) can do about this.  The best one is to make their platform absolutely compatible with some other platform so that developers don’t have a long learning curve.  We’ve seen a lot of those kinds of things going on in the industry.  It’s one reason why some things just won’t die.  Sometimes it works to give away the platform, and make it open.  It’s helpful if in the process you can make it as compatible as possible with something developers know.  Enter Android with a lot of Java inside.

That’s about it.  If you can’t make your platform fit those molds, you’re probably not going to be a Platform King.  Not enough developers will learn your stuff no matter how great it is because it was either not sexy enough or didn’t already have a big enough installed base.  The latter, BTW, is why Gordon Moore says it is better to go from app to platform than vice versa.  At least you’ll have the installed base and ecosystem of the app users to drag developers onto the platform.  They come to make the app users happy if there is enough motivation in that.  But this does not necessarily a huge platform success make.  This is the problem Salesforce struggles with in Force.com. 

Getting back to the Scoble interview, are these developers right, is Nokia screwed?  And whither the other mobile platforms?

Because developers have this big speed bump in their willingness to learn new platforms, they will tend to create sub-cultures that don’t communicate very much.  Right now we have a huge division between the Unix + Open Source world and the Windows + .NET world, for example.  Only a very small number of developers can claim to be Uber in both camps.  The vast majority know very little about the camp they are not Uber in, and often hold it in extreme disdain as a result.  But that does not mean they’re right.  It only means you have to understand where those boundaries are and what they mean to the success or failure of your product strategy. 

Translation:  don’t ask a set of developers about whether a platform they will have to learn will succeed unless all you care about is whether they perceive it as cool.  They don’t know much else.  It’s all religion to them.  Despite the fact they are engineers, very few will look at this sort of thing objectively.

In fact, Microsoft may have the only viable alternative platform opportunity that will work for mobile after Apple and Android.  Why?

Because there is a large community of developers who don’t have to relearn their tools.  To the extent the phone platform can minimize relearning and appeal to that group, they’re in.  It would be ideal if Microsoft can also create the commercial reality of a big enough market.  In fact, that will be a requirement in the long run.  But in the short run, Microsoft needs to stimulate some innovative hit apps on the platform that show life and prime the pump.  Steve Ballmer, if you’re listening, that’s the most valuable thing the billions you spend on R&D could purchase.  Bring 3 to 6 hip, really cool, must have apps to your platform so your customers don’t have to feel stupid (ala Scoble and mobile phone apps) and you have a chance.  While you’re waiting for that lightning to strike, at least make sure you have apps that give great experiences for all the key hip web properties out there, such as Facebook and Twitter.  And with whatever cash you have left, make sure your phone platform is minimizing the speed bump for .NET, Windows, and XBox developers to put apps on your phones.

It’s not too late, but it is far from early.

Related Articles

This community of developers who know Microsoft platforms is one of the under-served markets I alluded to in my article saying that Nokia-Microsoft are filling the last of the 3 winning market strategies.

Forget SaaS vs On-Prem, Here are 8 Application Styles to Consider

The EI discussion about Microsoft’s poor handling of Silverlight brought out the different viewpoints swinging. The “RIA was never a good idea” camp was in full force as was the “this confirms everything about HTML5″ and the “Flash is on the same train as Silverlight” camps.

I don’t see these developments nor the evolution of Flash and its strategy as a confirmation that RIA is a bad idea at all, that Flash, at least is going away, or that HTML5 is the answer to all the world’s problems. Whether your RIA consists of Flash widgets embedded in HTML (my favorite RIA strategy for web apps) or AJAX HTML, RIA’s are essential for many kinds of app and HTML5 is years from being a first class choice for that work. There has been too much tendency to conflate every conceivable nuanced app type as one single web app that is best served by one single technology. That way lies crappy UX, high dev costs, and longer lead times to market.

There are new categories of application coming along all the time, and the vast majority haven’t really stopped to think about the evolution of application types and their ecosystems. Let’s forget the ongoing dogfight about Clouds, elasticity, SaaS, and Multitenant for a minute, and have a look at factoring software along some other dimensions.

I see 8 different application design centers, and you choice of which design center to use and which tools and platforms to go with it can matter quite a lot.

#1 Plain Old Desktop (POD) Apps

 

I always loved the term “POTS” = Plain Old Telephone Service, so I’ll borrow the idea for PODs, which are “plain old desktop” apps. This is still a huge business including MS Office and much of what Adobe sells by way of content creation tools. It’s also huge for complex games, though the platform is sufficiently separate we will want a separate category for console games which I won’t get into here.

Typical platforms include the desktop OS–Windows or Mac, and the traditional developer languages such as C# and Java. To deal with the pains of PODs, your app needs to be something that requires too much horsepower for the other architectures as well as a rich User Experience (UX).

#2 Server Software

A command line is a UX, and for some purposes, its even a good UX, so we will count this as an “app” category. It’s like the PODS except there are more languages and OS’s to consider. On the OS side we have Unix in commanding lead (in all of its many flavors) with Windows distantly to the rear. From the langauge side, the world has probably spent more time and effort building an explosion of different evolutionary language branches here than anywhere else. I can’t even begin to list them all, but suffice it to say that when in doubt, you could do a lot worse than to bet on it being a language for server side development. Certainly we can count on Java, C#, and Ruby on Rails as all being in this category.

Some languages are a little bit muddled as to whether they’re server or client languages. PHP is a little of both that mostly errs towards client in my book, but you wouldn’t think of it for server-less apps (if no client is a headless app, are those tail-less apps?). For this app category, we have no UX but a command line, so I’m not sure we’d pick PHP. Put it in the category of helping out Plain old web apps and RIA’s.

#3 Client Server

 

The Client Server model is tried and true and still a huge business, especially for business software. I don’t know how much genuinely new Client Server software is being built anymore. The Cloud and SaaS are a much better model for most applications. Think of Client Server as the somewhat unwieldy combination of a POD and Server Software. Most of what I’ve said for those other styles carries to this one when combined appropriately.

The combination of Desktop, Server, and Client Server are the oldest app styles that are still vigorous today. We’ll call mainframe software a flavor of Server or Client Server. All three are under siege or revolution. Desktop and Client Server are clearly under siege as various web technologies via to take their place. Server is under the dual revolutions of Cloud and Multitenant SaaS. There have been many minor infrastructure revolutions as well as the world transitions from SOAP to REST or decides POJOs (Plain Old Java Objects) make more sense than deep J2EE architectures (let alone CORBA style, Service Bus, and all the rest of that melee).

#4 Plain Old Web (POW) Apps

 

No fancy RIA tech, AJAX or otherwise. This is the modern equivalent of the half duplex 3270 green screen. But, it is lowest common denominator friendly. That means everyone can access it, but the experience may not be great. Save it for times when coverage is more important than satisfaction. Simple UI you just have to get through once in a blue moon is perfect.

The platforms? Who cares. POW apps should use such vanilla HTML they never notice. Tools and languages? Vanilla HTML and whatever your favorite dev tools are for that.

If we add POW apps to the other 3, you really do have the majority of revenue and installed base at present. What follows are newer models that are catching on to a greater or lesser degree. I should add that I see POW as stable and non-controversial, Server as growing but full of revolution, and the other two (Desktop and Client Server) as in decline to greater or lesser degrees.

#5 Rich Internet Apps

RIA’s are web apps that live in the browser but provide a nicer UX than a POW can offer. AJAX, Flash, or Silverlight have to be there for it to count. HTML5 supports this poorly at present, but everyone knows it wants to go here over time.

The “Rich” part of a RIA can boil down to lots of things, so let’s call some out so they don’t go unnoticed. Yes, we will started with Rich User Experience. But what does that mean?

Well, instead of posting a form, you have enough expressiveness that you can actually create new kinds of widgets and respond to user inputs with much more fluidity. We also have rich media, including sound and video to play with, as well as sophisticated ways of manipulating bitmaps to produce animations and art.

However, depending on the RIA platform, you may also experience other “riches.” Flash player delivers a very high performance virtual machine. It isn’t Java-class, but it is darned good. Recently, browser makers have decided performance matters for HTML as well, but it isn’t clear they’re keeping up with Flash. If your RIA has to do some kind of crunching, Flash may help it along. It isn’t just about the high performance VM, there is also the support for more elaborate data structures, which are also helpful where more horsepower is needed.

I have been fascinated by an idea I came up with called “Fat SaaS”.  We live in the multicore era where computers no longer get faster in raw terms, they just get more cores.  At the same time, it is very hard to write software that takes advantage of all those cores.  On the server side, the world has been evolving towards dealing with the issues need to scale large problems onto grids of commodity PC’s as a way to deal with the realities and economics of the multicore era.  On the client side, it seems that machines accrue more and more unused capacity without delivering good reasons for customers to upgrade as often as they used to.

Fat SaaS is an architecture that pushes as much down onto the client as possible and leaves the server farm largely for data storage.  In an extreme Fat SaaS case one could imagine that the clients become the business logic processing grid.  The goal is to tap into the computing resources that lie fallow there, and there are a lot of them.  Most organizations will have more client cores than server cores.

But we digress…

The last bit of “riches” I want to touch on is device independence.  We largely got there for server software, and write once run anywhere is a beautiful thing.  Other than Flash, we are nowhere in sight of it for the client.  This is a sad and embarrassing tale for our industry, and one that developers too often try to power their way through by just writing more code.  Browser incompatibilities are insidious.  As I write this article in WordPress, I’m trying to use their rich text editor.  It runs with varying degrees of success and a little differently on each browser.  Lately, it mostly fails on IE, meaning the UX has not been kept up to snuff.  If they would simply invoke Flash to do one single thing, manage the text editing, they could deliver an identical experience on every browser, not to mention many mobile devices too, though on Apple’s devices they would need an app to do that.

This browser dependence is absolutely the bane of HTML based RIA’s, and I can see no reason why the problems won’t continue with HTML5.  As vendors race to see who can deliver better HTML5 support sooner, keep eyes peeled for the incompatibilities to start.  If they do, that’s a sign that the HTML5 dream is not all its cracked up to be, even in the fullness of time.  It will take some new generation and a bunch of restarted browser implementations to get there.  Meanwhile, Flash will have gained another 5 to 10 years lease on life, despite detractors.

#6 Rich Internet Desktop Apps

RIDs!  A RID is a really cool thing.  It is the web era approach to building desktop apps–we build them with web technology.  Amazingly, nobody seems to have noticed that if you need to run disconnected, or if you want to build an app with web technology that does meaningful things on the desktop, Adobe is the last man standing.

Google killed Gears and Silverlight looks more and more deprecated by the day.  HTML5 is still struggling to get to the minimum RIA bar and will be for years.  What’s a poor RID developer to do, but focus on Flash?

RIDs are fascinating apps, and I would argue your nuts to build any new PODs or Client Server when this model would work. In the area of games, there are amazing developments in 3D coming for Flash Player that will also play to this architecture. Lastly, Ialready mentioned “Fat SaaS”, a model which is ideally suited to RIDs.  The RID just gives the Fat SaaS access to local disk and more of the machine’s facilities.  Fat SaaS work can go on whether the client is connected or not, and a connection can wait until the client needs to connect, which reduces the demand on the Cloud Server Farm still further.

#7 Mobile Apps

MAs are closely related to RID’s, and certainly much better known. The non-HTML RIA platforms are excellent for this purpose, and it is no accident MSFT sees this as Silverlight’s future.  HTML5 doesn’t do enough and it will be years before it does to have real apps stand alone with it. iPhone’s default toolset is basically foisting desktop technology on you to build these apps, and I’m skeptical this is as productive, but the stakes are high enough people deal with it.

#8 Mobile Internet Apps

MIAs:  when you want to live in a browser on a mobile device.  Plenty of data suggests that for apps that are not heavily used, users prefer to consume via browser.  This shouldn’t be controversial as it simply makes sense.  The browser makes it much easier to dip in and out of a lot of apps that you probably never use enough to learn really deeply.  MIAs are a different category than RIAs because like the RIA, there are considerations beyond one-size-fits-all HTML.  However, a MIA could be a RIA MIA (LOL) or a simple HTML MIA.  I won’t bother breaking those two out as new app types–we already have 8 and that’s enough.  The reality is the MIA is a placeholder reminder that you have to do something to make your app palatable on a mobile device lest you have a below par UX.

Conclusion

Have you thought about when to use each of these design centers, what the optimal tool sets are for each, and especially how to weave an all-platform strategy with as little work as possible?

Most haven’t.  I see low expertise in out in the world as much of this is new and very few organizations have so much breadth of experience.  Most of the time organizations start with one design center and move chaotically on to others as targets of opportunity present themselves.

We increasingly live in a world where being on one or a few platforms will not be good enough, and we won’t be able to build for all with organically grown “luck” strategies.  Maybe this is a good time to start thinking through these issues in a systematic way for your organization and its products?

Related Articles

Recursivity and RWWeb talking about Fat SaaS.

Dell Buys Boomi: Right Inline With My Cloud Strategy

Just read that Dell is buying Cloud data integration company Boomi.  That’s right in line with the focus on data strategy I’ve recommended for Cloud vendors.  I’m not sure how many more companies in this space are available to be picked up.  IBM picked up Cast Iron Systems, which was another great catch.

Just a refresher on why these companies are so pivotal, because it amounts to two key observations:

First, Clouds have latency, which creates a network effect.  It’s easier for apps in the same Cloud to talk to each other than it is to go across Clouds.  Hence Clouds are going to accrete applications based on which ones need to talk to each other.

Second, in the SaaS world, integration is a tremendous competitive and transaction friction issue.  No Enterprise application is an island, they all need to talk to some other application.  If that integration has to be done without the leveraging benefits of a supporting technology, if it has to be done strictly as a service, that adds a lot of friction to the transaction.  That friction can slow down sales momentum.  In addition, from a competitive standpoint, SaaS apps are often bought by the Business with the idea that they will cause minimal support overhead for IT.  Whether IT buys into that or not, the availability of suitable integration technology is going to determine how happy everyone is.  If IT has to constantly dive in and bandaid the integration, nobody is happy.  If IT can get comfortable at the outset that the integration solution will be high quality, everyone will be a lot happier.

These data integration acquisitions are very strategic to the Cloud space.  Good on Dell for going after Boomi.

What is the Sound of One Cloud Thunderclapping?

I just finished reading Randy Bias’s piece, “Elasticity is NOT #Cloud Computing … Just Ask Google“, and I must admit, it takes me back to all sorts of questions of a vaguely unsettling nature that have been bubbling below the surface of my cloudy thinking for some time.

If Elasticity is NOT Cloud Computing, and I profoundly disagree with that statement, then what the heck is Cloud Computing?  I admit to already having been pretty skeptical about whether Private Clouds are really Cloud Computing, but I got over that from an understanding of elasticity and private clouds.  However, if we take away Elasticity, and make whatever is left Private, I’m not sure we have anything profound whatsoever.  How does it differ from an outsourced data center, for example?

Randy seems to have come to his position about elasticity by looking at the large web operators like Amazon, Google and Salesforce who offer Cloud platforms of one kind or another (IaaS, PaaS, and the rest of the alphabet soup).  He’s interested in their history, why they built the kind of infrastructure they did, and why that turned out to be an ideal platform from which to offer Cloud Computing offerings.  My problem is that the mere fact that Amazon did not get the Elasticity benefit from its Cloud that AWS customers can does not in any way diminish the revolution that is the Cloud and that comes with Elasticity.  Without customers, these fancy Amazon and Google data centers are literally the sound of One Cloud Thunderclapping (because Clouds don’t just clap in the sense of the old Zen saying).  I don’t see how you can regard those data centers as “Cloud” at all.  A term more like “commodity computing” data center, perhaps with some form of “virtual” thrown in makes more sense.  Interestingly, it is the addition of the customers to their data centers that exposed Amazon and Google to a little elasticity.  Why?  Because now they have customers to help pay for excess computing capacity and hence elasticity.   What a beautiful thing, and another strong argument for why elasticity changes everything. 

The term “Cloud”, in any sense I’ve ever heard it used, is a service of some kind provided by one organization and shared (this sharing is critical) by many other independent customer organizations.  Thinking back on the idea that Amazon’s data center wasn’t cloud until they flipped the switch and started sharing it with customers (that’s the point where they got elasticity too), you can see that the ideas of “sharing” and “independepent customers” are critical.  Without both, there is no way to pay for the excess capacity that is elasticity, or at the very least, if the sharing is the sort pushed by companies like VMWare to up server utilization, it isn’t quite the same as having real net positive dollars coming in from paying customers, versus simple cost savings.

This is where I get into trouble with the Private Cloud concept.  Yeah sure, people are interested in building data centers that use technology similar to what the “Cloud” vendor’s data centers use.  Yeah sure, there is some benefit to that.  Those technologies were developed by organizations that needed to commoditize their data center services into as cheap an offering as possible.  But to call that Cloud Computing sure seems like gratuitous marketing to me.  If nothing else, it radically understates the challenge those organizations faced.  A little bit of storage virtualization, a healthy dose of VMWare-style machine virtualization, and do you really have the full benefits of Cloud Computing?  Not in my book.  You just have a modern data center. 

There are steps beyond that to take advantage of.  And the advantages are enough of a quantum leap that it isn’t fair to award the accolade “Cloud” for anything less.  If you do, you’re just engaging in gratuitous marketing, trying to draft somebody else’s hype and momentum.  I am already on record as arguing for the definition of Cloud being two things: 

-  It is Software as a Service.  I sometimes refer to this as “Ops as an API”, meaning rather than crawling around cages and machine racks, you perform ops by making API calls on your Cloud infrastructure.

-  It is Elastic.  Yep, I refuse to separate Elasticity from the Cloud, though Randy’s piece wants to leave it more in the camp of simply “Data Center as a Service”.

So then what really is a Private Cloud, and can we still call it a Cloud?  If you include the Software as a Service Piece, and the Elasticity, I would say “yes”.  The difference between a Public and Private Cloud is simply that in the Private case, the Customer paid the service provider to decouple their Private Cloud from the rest of the Public Cloud so no network traffic can get into the Private Cloud without its full knowledge and consent.  This is no biggie–it’s a subnet with the additional proviso that we don’t run anyone else’s Cloud Software but the one owner of the Private Cloud insider that subnet.  This is actually a pretty good deal for all concerned.  The Private Cloud user still gets nearly all the benefits of the Public Cloud user.  They do not get quite a good a price as they must monopolize the hardware to a greater extent than their Public brethren, but it is still a great deal.  Elasticity is still available to them, as is “Ops as an API”.  If your Private Cloud lacks either one of those characteristics, you have a modern data center, but it isn’t Cloud, despite what your vendor’s marketing people want to tell you.

Why do a Private Cloud? 

Largely to reduce perceived risks.  The risks boil down to security and performance.  The Private Cloud is presumably more secure, and its performance is more predictable because no unknown Public Cloud tenants can get into the Private Cloud and do unknown things.

There is one more advantage I will mention for the Cloud, which very much does include Elasticity, versus the Modern Data Center, which uses some Cloud technology, but has no Elasticity and is not a Cloud:

You Cloud Vendor may have more buying power than you, more technology they have amortized over more customers, and hence a lower cost to deliver the service than even relatively large corporate data centers can attain.  Hey, if it was easy, everyone would be doing it, instead of just everyone claiming to do it.

PaaS Strategy: Sell the Condiments, Not the Sandwiches

This is part two of a two-part series I’ve wanted to do about strategy for PaaS (Platform-as-a-Service) vendors.  The overall theme is that Platforms as a Service require too much commitment from customers.  They are Boil the Ocean answers to every problem under the sun.  That’s great, but it requires tremendous trust and commitment for customers to accept such solutions.  I want to explore alternate paths that have lower friction of adoption and still leave the door open in the long run for the full solution.  PaaS vendors need to offer a little dating before insisting on marriage and community property. 

In Part one of this PaaS Strategy series, I covered the idea of focusing on getting the customer’s data over before trying to get too much code.  We talked about Analytics, Integration with other Apps, Aggregation, and similar services as being valuable PaaS offerings that wouldn’t require the customer to rewrite their software from the ground up to start getting value from your PaaS.  Now I want to talk about the idea of starting to get some code to come over to the PaaS without having to have all of it.  My fundamental premise is to create a series of packages that can be adopted into the architecture of a product without forcing the product to be wholesale re-architected.  I use the term “packages” very deliberately.

Consider Ruby on Rails Gems as a typical packaging system.  A gem can be anything from a full blown RoR application to a library intended to be used as part of an application.  We’re more focused on the latter.  The SaaS/PaaS world has a pretty good handle on packaging applications in the form of App Stores, but it needs to take the next step.  A proper PaaS Store (we’re gonna need a better name!) would include not only apps built on the platform, but libraries usable by other apps and data too.  Harkening back to my part one article, data is valuable and the PaaS vendor should make it possible to share and monetize the data.  Companies like Hoovers and LinkedIn make it very clear that there is data that is valuable and would add value if you could link your data to that data.

What are other packages that a PaaS PackageStore might offer?

I am fond of saying that when you set out to write a piece of software, 70% of the code written adds no differentiated business advantage for your effort at all.  It’s just stuff you have to get done.  Stuff like your login and authentication subsystem.  You’re not really going to try to build a better login and authentication system, are you?  You just want it to work and follow the industry best practices.  A Login system is a pretty good example of a useful PaaS package for a variety of reasons:

-  It doesn’t have a lot of UI, and what UI it does have is pretty generic.  Packages with a lot of UI are problematic because they require a lot of customization to make them compatible with your product’s look and feel.  That’s not to say it can’t be done, just that it’s a nuisance.

-  It adds a lot of value and it has to be done right.  As a budding young company, I’d pay some vendor who can point to much larger companies who use their login package.  It would make my customers feel better to know this critical component was done well.

-  It involves a fair amount of work to get one done.  There is a fair amount of code and it has to be tested very carefully.

-  I can’t really add unique value with it, it just has to work, and everyone expects it to work the same way.

-  It is a divisible subsystem with a well-defined API and a pretty solid “bulkhead” interface.  What goes on the other side of the bulkhead is something my architecture can largely ignore.  It doesn’t have to spread its tendrils too far and wide through my system in order to add value.  Therefore, it doesn’t perturb my architecture, and if I had to, I could replace it pretty easily.

These are all great qualities for such a package.  What are some others?  Think about the Open Source libaries you’ve used for software in the past, because all of that is legitimate territory:

- Search:  Full text search as delivered by packages like Lucene is a valuable adjunct.

- Messaging:  Adobe and Amazon both have messaging services available.

- Mobile:  A variety of services could be envisioned for mobile ranging from making it easy to deal with voice delivered to and from telephones to SMS messages to full blown platforms that facilitate delivering transparent access to your SaaS app on a smartphone.

-  Billing:  There are companies like Zuora out there focused on exactly this area.  Billing and payment processing comes in all shapes and sizes, and many businesses need access to it.  You needn’t have full-blown Zuora to add value.

-  Attachments:  Many apps like to have a rich set of attachments.  There’s a whole series of problems that have to be solved to make that happen, and most of it adds no value at all to your solution.  Doing a great job of storing, searching, viewing, and editing attachments would be an ideal PaaS package.  There are loads of interesting special cases too.  Photos and Videos, for example.

I want to touch on an interesting point of competitive differentiation and selling.  Let’s pick one of these that has a lot of potential for richness like Photos.  Photos are a world unto themselves as you start adding facilities like resizing, cropping, and other image processing chores, not to mention face recognition.  There’s tons of functionality there that the average startup might never get to, but that their users might think was pretty neat.  After a while, the PaaS can set the bar for what’s expected when an app deals with photos.  They do this when their Photos package is plush enough and adopted widely enough, that people come to expect it’s features.  When it reaches the point where the features are expected, but a startup can’t begin to write them from scratch, the PaaS vendor wins big.  The PaaS customers can win big too, because in the early days, before that plushness becomes the norm, a good set of packages can really add depth to the application being built.

PaaS vendors that want to take advantage of this for their own marketing should focus on packages that deliver sizzle.  I can imagine a PaaS package vendor that totally focuses on sizzle.  They’ve got photos, video, maps, charts (bar charts to Gantt charts), calendars, Social Media integrations, mobile, messaging, all the stuff that when it appears in the demo, delivers tons of sizzle and conveys a slick User Experience. 

Before moving on, I want to briefly consider the opposite end of the spectrum from sizzle.  There’s a lot of really boring stuff that has to get done in an application too.  We’ve touched on login/authentication.  SaaS Operations is another area that I predict a PaaS could penetrate with good success.  Ops covers a whole lot of territory and the ops needs of SaaS can be quite a bit different than the ops needs of typical on-prem software.  For one thing, it needs to scale cheaply.  You can’t throw bodies at it.  For another, you have to diagnose and manage problems remotely.  One of the most common complaints at SaaS companies I’ve worked with is the customer saying performance is terrible.  Is it a problem with the servers?  Is it a problem in the Internet between your servers and the customer?  Is it a problem inside their firewall?  Or is it a problem on their particular machine?  Having a PaaS subsystem that instrumented every leg of the journey, and made it easy to diagnose and report all that would be another valuable, though not particularly sexy offering.

I hope I have shown that there is a lot of evolution left for the PaaS world.  It started out with boil the ocean solutions that demand an application be completely rewritten before it can gain advantage from the platform.  I believe the future is in what I’ll call “Incremental PaaS”.  This is PaaS that adds value without the rewrite.  It’s still a service, and you don’t have to touch code beyond the API’s to access the packages, but it adds value and simplifies the process of creating new Cloud Applications of all kinds.

Android is so Open, it got Flash Back on the iPhone

How ironic.  On the same day that MG Seigler was penning one of his characteristically snarky posts (snark is one of the ways Techcrunch pursues its Follower Economy) about how Android isn’t really open, Apple announces the return of Flash to the iWorld.

Adobe’s stock price is cooking this morning as a result (I wonder if 10% of Adobe’s revenue is even traceable to Mobile Flash? Maybe), and I have to admit, being the Adobe Flex fanboy that I am, I’m chortling over my morning cafe mocha too!

A couple of things to talk about on this news.

First, why do I award credit for this to Android?  Peeps, come on–Steve Jobs didn’t just wake up from his hissy fit about Flash (thanks for that link, Larry!) and decide, “Oh darn, I was wrong.”  No, no, no, not happening.  Something grabbed Steve Jobs by the throat and shook him right out of his reality distortion field.  That something was competition.  Not only has Android been selling extremely well, but the Bastiches have even been using Apple’s, “Hey, we’re not the Man, we’re Cool“, marketing tactics.  Dude, what’s next, Android thinking differently (I can’t see Google having the populist moxie to get that grammar wrong the way Apple did, all those PhD nerds just couldn’t handle it).

Competition is what forced this change, MG Seigler.  Android’s “We’re more open than open can be” pitch was working.  In fact, this Apple announcement sweeps away most of what one would’ve argued were barriers to openness.  It isn’t just Flash that benefits.  Besides which, a heck of a lot of people love their iDevices (3 out of 4 of our whole family have iPhones and we share an iPad) but want Flash access.  Forget movies, they can change.  I can’t even see the stock graphs on Yahoo because they’re Flash.

Gordon Gecko was wrong when he said, “Greed is good.”  It pains me as a person often described as being slightly to the right of Attila the Hun to reach that realization.  What Gordon should have said was this:

Competition, for lack of a better word, is good. Competition is right, Competition works. Competition clarifies, cuts through, and captures the essence of the evolutionary spirit. Competition, in all of its forms; Competition for life, for money, for love, knowledge has marked the upward surge of mankind.

And here, it has let Flash back into the iWorld.  Good job, Android!

Second, I want to take a few lines to talk about why I think Flash is so important.  Much has been made of how the LAMP stack has transformed web development.  Companies can now create products without requiring millions of dollars in R&D expense.  But the LAMP stack primarily benefit the back-end, in other words the server-side.  What about the client?  What is the equivalent of a LAMP stack for client development?  Unless you’re a tremendous fan of 3270 green screen UI, and I know some are even in this day and age, you need the equivalent of the LAMP stack to efficiently product great clients.  Here is the secret:  Flash is the LAMP stack of UI development!  Yes, there are some Flash wannabes out there, specifically Silverlight.  So what?  Microsoft would love for .NET to be the LAMP alternative too.  Flash is it for these simple reasons:

-  It is ubiquitious.  Aside from the iWorld, and that changes today, the vast majority of the world has already installed Flash and it runs in their browsers.  That’s 99.3% penetration in mature markets.  Essentially, everyone has it.

-  It is a write once run anywhere tool that really works.  You write your Flash code and all 99.3% of users can run it without you needing to give it another thought. 

-  AJAX and Javascript, the alternative, is riddled with browser dependencies.  Any dev team that has tried to get even simple rich UI like a Wiki-style rich text editor to work understands this.  It’s a huge overhead to keep up with all of these browser dependencies, and a constantly moving target.  With Flash, Adobe does that work for you so you can get on with building your app.

-  Flash has amazing graphical power and Job’s protestations to the contrary is actually quite fast.  People are writing 3D games in it, for example.

-  Flash can transcend the browser to create apps via AIR, and as we’ve discovered in the mobile world, apps are where it’s at.  Google used to offer Gears for this purpose, but pulled the plug on it.  Silverlight?  Hey, competition is good, bring it.  But they aren’t really there yet.

This all adds up to something that’s very important to the ongoing evolution of User Experience across all devices.  Simply put, Flash deserves to keep going and to be available on all those devices.  Thank you, Steve Jobs, for relenting, even if it took a gun to your head.  Adobe: now is not the time to rest on your Laurels.  There are some issues here and there in the House of Flash that you still need to attend to.