Heard about an executive recently departing a large Enterprise Software Company, “He was disruptive.”
I don’t know the man, but couldn’t help but wonder. “He was disruptive,” has been the epitaph for many a career.
Posted by Bob Warfield on November 21, 2010
Heard about an executive recently departing a large Enterprise Software Company, “He was disruptive.”
I don’t know the man, but couldn’t help but wonder. “He was disruptive,” has been the epitaph for many a career.
Posted by Bob Warfield on November 16, 2010
There’s quite a bit of back and forth about the Facebook Messaging announcement. Since a little time has passed, people have settled in and we’re slightly past the hype. Time for my two cents:
Facebook has an opening based on at least two value propositions that I can see. There is value in a single inbox, though at least one EI discussing the issue seemed to think that value was marginal. I disagree. Every “2.0” effort has to overcome the cost of introducing another silo where you have to divide your valuable attention. This is one of the reasons I wrote my E2.0 is dead note–too many times the 2.0 effort doesn’t offer enough value to deal with yet another silo. Without getting sidetracked into that discussion again, any new Social offering has to provide enough reasons to overcome the cost of divided attention. What better gambit than to argue they will reduce the division by providing a single inbox?
The second value proposition is that they can use their Social Graph to add value to this inbox. Zuckerberg wants to improve the signal to noise ratio, and most people would welcome that, if it works. Scoble paints an interesting picture of Facebook as repository of better contact information in his discussion of the Social Graph openness war between Facebook and Google:
It’s too late for Google. Facebook knows this, which is why it’s being more open. Why? Well, my Google social graph has rotted. The 8,000 names on my Google Contacts are attached to email addresses that are old, not good, and phone numbers that are old, not good. Tonight I tried to call someone from my phone’s contact list. The number was dead. I went to Facebook, grabbed his new number there and I even made the call right from the Facebook iPhone app.
Now Scoble is not representative of any audience I’m very close to, but he is representative of some audience. Perhaps it’s a growing audience. I know people who spend hours in Facebook, but not many. Perhaps their contact information is more current in Facebook than in Google Contacts. For those folks whose contact and other information is more current, I can see where this might make sense. Or perhaps Scoble just represents that audience that insists on having 8-10,000 or more close friends and nobody on any smaller lists. I can see where it would be hard to keep that contact information current.
I have to say that after having tried to train Google’s Priority Inbox for about 6 weeks, I finally gave up. I was spending more time training it than it was saving me. Somehow the information available to Google was either not adequate, or their algorithms didn’t make good use of that information. The bottom line is we shouldn’t take the logical-sounding promise of vast improvements in the relevancy of our inboxes based on Social Graph manipulations as a forgone conclusion. Extracting useful semantics from data is a hard problem that will remain hard for some time to come.
However, if you are going to buy into the “Social Graph Can Add Value to Your Messaging” camp, you need to pick the Social Graph that fits your life. Is there really one? Don’t some people like Facebook mostly for friends and family, LinkedIn for professional contacts, and somebody else for some other thing? Hold that thought!
Okay, those are the reasons why Facebook has an Opening for Messaging. Did they score?
The answer so far seems to be a resounding, “No!”
Discussion among the EI’s was decidedly underwhelmed. Nobody could understand what new value was being added. I want to be sensitive to the notion that maybe these EI’s, all older software company execs, but not too old (grin), are not necessarily communicating in the same way that some demographics would. There’s been a lot of talk for example about how the younger crowd has no use for email. Perhaps there is value to them in having a threaded conversation inbox for their many other channels of instant messaging. That’s a possibility the crowd brought up on email would overlook. If that turns out to be a big issue, then the communication divide between these generations will turn out to be a lot larger than anyone thought. It amounts to having an older generation that only listens to radio and a younger generation that only watches TV. You can imagine how profound that might be. Zuckerberg is watching this closely, and apparently High Schoolers tell him, “We don’t really use email. It’s too slow.”
I will also reiterate that there is huge value in a single Inbox. But this one has some serious flaws. I briefly touched on the question of whether the Facebook Social Graph is the penultimate Social Graph to base your life around. It isn’t for me, and I suspect it isn’t for a lot of people. It might not even be for the majority of Facebook users for all we know. That graph simply cannot capture the nuances of every aspect of our life, if for no other reason than Facebook has already mismanaged its stewardship of it for far too long. They have constant privacy bru-ha-ha’s. They’ve demonstrated a willingness to exploit it beyond the pale as the ultimate walled garden. I frequently hear opinions along the lines of, “nor do I want to put my online identity anywhere near that company.” Facebook is definitely getting a reputation as “that company” when it comes to trust.
Sam Diaz’s “First 10 Impressions” article was fascinating too. The impression one gets is of a product with a fairly deeply flawed User Experience. Sam is surprised by an awful lot of what goes on in this experience, and his summary makes that clear:
“Facebook CEO Mark Zuckerberg was exactly right when he said that this is not a GMail killer. For now, it’s confusing and that’s intensified by the integration of SMS.”
Just as fascinating as the conclusion is some of the specific things Diaz found. I found this one to be the most telling comparison of E-Mail and “2.0 Things”:
I have this overwhelming urge to go in and clean out my messages. I had no idea I’d had that many message exchanges on Facebook. And I had no idea that I had unread messages dating back to August 2009.
Note to 2.0 software designers: think hard about what this means as it’s an experience a lot of people are having. It’s okay to miss a message or two among friends and family. They will remind you if it was important and tease you about your forgetfulness if not. However, when it comes to using Social for business, missing messages can be a real problem. Imagine if your best customer tried to get some answers from your Social CRM support forums and you just missed the message. This happens all the time. It’s why the rest of the Customer Service world invented the Trouble Ticketing or Case Management systems. They’re nothing more than managers of messages and action items that must not be forgotten. In fact, contractually, they often must be handled within a specific SLA. When was the last time you saw a Social CRM system do that? To do it right, it has to be tightly integrated with your CRM system so it knows who is entitled to what treatment as well, no? My former company, Helpstream, did all that, but we digress.
Let’s agree that Facebook has an opening, but this ain’t it. That puts the ball back into Google’s court. What should they do?
First thing is they need to resist the normal Geek mentality. You know, the one that leads to Second System Effect, defined by Wikipedia (hopefully with a hat tip to Fred Brooks!) as:
The tendency, when following on from a relatively small, elegant, and successful system, to design the successor as an elephantine, feature-laden monstrosity.
BTW, the small, elegant, and successful system is GMail. And Google Reader. And many other successful offerings in the Google lineup. The tendency to monstrosity would be personified by Wave. Repeat after me guys, “Wave was a bad idea and we don’t want to do it again.” BTW, they won’t repeat that mantra. Geeks hate to lose and somewhere is a Google Alpha Geek thinking it was a failure due to marketing, not waiting long enough, being too early to the market, or almost any reason except that it was a bad idea. After all, it was probably hard to build, and anything hard to build is a Good Idea so far as most Alpha Geeks are concerned. If it was easy, pretty soon non-Geeks would be doing it.
Okay, having thought hard about it and having decided to avoid Second System Effect (phew!), this is not that hard. Borrow a page from Sun Tzu. Break out your OODA loops while you’re at it. Competitive Strategy Sun-OODA 101 says, “Focus your strengths to strike your enemy where he is weak, force him to fight his war on many fronts, and keep him second guessing his own strategies so he never sticks to one long enough to see it to fruition.” Let’s translate that to action:
Google, you are in the Inbox and Reader business, not the Social Graph in a Walled Garden Business (that’s Facebook). Through Inbox and Search you are the Reader for the entire Internet for cripe’s sake. Revel in your time and crush these pathetic date-seekers. You are only missing two things:
1. Unified Inbox: Find an elegant combination of Reader and GMail and you are mostly there. It ain’t that hard. Resist the Second System Effect and git ‘er done.
2. Promiscuous Connectivity: Unfortunately, you are not good at this and have a lousy track record, but you have to succeed at this one because it’s the only antidote to 500 million strong Walled Social Graphs.
Why do I say Google has a lousy track record at promiscuous connectivity? I dunno. Maybe I’m soured by my experiences trying to integrate GMail with Outlook-Exchange. It gets the email part because they can fall back on the POP/SMTP open standards. It failed miserably with contacts and calendar integration, even when iPhone could do the job beautifully. Maybe it’s because Google has never gotten for the Apps business that there are only 2 kinds of compatibility with Microsoft Office–100% Compatible and Not Compatible. Guess which one Google Apps has?
This inability to promiscuously connect is not a failure of technology or IQ, it is a failure of willpower. No Geek likes to have to slavishly deal with someone else’s standard. They will hold their noses for Open Source, or some other Open Standard, but as for these other things? Fuggedaboutit. You may as well ask a Geek to maintain someone else’s code instead of rewriting it (Gasp!). Oh the horror, the humanity of it all.
But wait, does Facebook have this issue too? Evidently not. They will lower themselves to the moral equivalent of screen scraping to get Google’s data while Google sits around and whines to the press instead of engineering some whizbang gizmo to suck the Social Graph out of Facebook’s Walled Garden.
Dudes, you are going to have to get good at doing this thing you evidently detest–living in the shadow of someone else’s software. If you can seamlessly, easily for your users, and in real-time, continuously scrape all the Social Feeds and Graphs that are out there and feed them to a nice elegant little reader, you will win. You do want to win, don’t you? Well then that’s a technical problem worth solving.
BTW Google, consider this Facebook Messaging thing a shot across your bow. Facebook will now start reaching out into your web. If you don’t move quickly, they are going to OODA you and get inside your decision loop.
Posted by Bob Warfield on November 11, 2010
After reading Dennis Howlett’s piece, “Enterprise 2.0 is beyond a crock. It’s dead,” and Andrew McAfee’s counterpoint, “Social Business is Past Retirement Age,” I found myself in the surprising position of agreeing with Dennis that E2.0 is dead. I’m not suprised because of any issue with Dennis, I’ve been reading and enjoying his work for years, but rather because I would’ve expected to come out more on the side of E2.0 idealists. After all, I was very recently involved in a closely related space called Social CRM, and I’m supposed to be a card-carrying “Social Guy.” Dennis has never made a secret of his skepticism.
Here is my problem: the Business Social Scene has rolled forward under the banner of the Consumerization of IT and not much else. That’s a polite way of saying they’ve copied everything they can from Facebook, Twitter, and online BBS systems, without adding much innovation of their own. They’ve made it possible to visit the water cooler without leaving your desk, but that’s hardly an excuse for big ROI payoff.
Because of my past, I find myself talking to lots of companies that are interested in Social for Business. If there is one thing that constantly surprises me, it is the sameness of their approach. Really the only interesting new thing I’ve heard of was Chatter’s ability to have the Enterprise Software itself participate in the conversation.
Take recent reviews of Moxie (used to be called nGenera) where two reviewers (Ben Kepes and Klint Finley) remark along these lines:
Moxie is a full-featured social suite including internal and external community sites, wikis, idea management, microblogging and more. Ben Kepes is not particularly impressed by Moxie. He lists the things Moxie told him in a briefing set it apart:
- Pointers to people (think rich profiles and the like)
- Rewards for participants (thinks badges and stuff – yawn)
- Going where the people are (single sign on and enterprise integration)
- A compelling UI (code for “we look like Facebook”)
I was basically told the same thing in my briefing, and I agree that most of this is all pretty common place – except maybe badges, which aren’t a big deal.
I saw the demo some time ago and had the same reaction. They’re awfully late to the party to be showing a Me Too product, even if it does have a little nicer fit and finish than many.
The trouble is, almost everyone is late to this party in some sense or another because they’re all so similar. That means that the consolidation that’s already underway (where companies like Cubetree are bought by companies like SuccessFactors) will continue or accelerate.
There is also another disturbing tendency, and this is where Howlett’s piece really resonates and Andrew McAfee lets us down as an academic: it’s gotten to be all about faith and marketing. When it comes to ROI, “Where’s the Beef?” Discussions of ROI quickly turn circular: You can’t get the ROI until everyone is participating, but once they are, we’re sure the ROI will be huge. Dennis’ point is that in the end of the day, it’s all down to the people and their culture. If you have a company with a culture that’s capable of embracing E2.0, you may get some value from it. If not, fuggedhaboutit. And this is where my problems with Andrew McAfee start. He says the idea of a “Social Business”, is old as the hills, and E2.0 is the new new thing we have to focus on. In talking about “Social Business” (how people behave) versus E2.0 (Tools), he pens a great passage that if I were he, I couldn’t imagine wanting to be held accountable for:
This distinction matters. It matters because telling business decision makers “There are some important new (social) technologies available now, and they’ll help you address longstanding and vexing challenges you have” is very different than telling them “Business is social, and the more deeply you embrace that fact the better off you’ll be.”
Absent any other information, I would’ve expected McAfee to immediately embrace his second statement and move on. Wouldn’t you? After all, it is the more profound and more accurate statement. The first is more faith marketing from the E2.0 cheerleader’s squad. Imagine my surprise at his next paragraph:
The former sentence, I’ve found, is pretty effective at getting their attention. The latter one is less so, because I tell you with complete certainty that they’ve heard it many many times before. It’s a message that has been broadcast into the executive suite for fourscore years now. Sometimes it’s been delivered with great skill and clarity, sometimes not. Sometimes it’s been internalized and acted on, sometimes not. But the message has been heard so often that it’s faded into the background. I’ve found that the phrases “business is social” and “people, process, and technology matter” have lost most, if not all, of their power to persuade decision makers.
Hold on Andrew, when did you cash in your academic credentials, pick up a bag, and decide your most important job was selling E2.0 software? Aren’t you supposed to have weightier matters of the mind such as learning something new and discovering the fundamental truths of our time? Isn’t the fundamental truth, “Business is social, and the more deeply you embrace that fact the better off you’ll be.”
Here’s the deal: we are nearing the end of the time for Faith-Based Marketing. That’s an Early Adopter’s game. We’re staring at the chasm and wondering how to get across. You can’t cross the chasm with a hope and a prayer. The folks who live on the other side of the chasm are not Early Adopters. They don’t worship every new shiny thing. They are more practical and pragmatic people who insist on an ROI. Chris Yeh puts the mindset of these later adopters in a blunt but accurate fashion:
If you can’t sell more, buy less, or fire somebody, you’re not getting real ROI.
If there is one thing I learned selling Social Software, it is that the issue is very black and white. You can’t convince people to be Social unless they already are. There are no grays, and any company that bets its future on turning grays into blacks or whites is going to have such a high cost of Sales and Marketing they will fail. There is a crowd that believes it’s all down to demographics. “We just need enough Gen Y’s in decision-making positions and the world will turn Social overnight.” There is a crowd that looks at Facebook’s 500 million people and concludes, “It’s inevitable and moreover it is here right now today!” They are both wrong. They are both relying on Faith rather than actively doing something new. Remember that old definition of insanity–doing the same thing and expecting a different result. Get off of Faith and onto ROI and you can talk shades of gray. Chris puts the E2.0 mindset on ROI equally as bluntly:
I keep hearing that the benefits of E2.0 initiatives will take a long time to accrue and are difficult to measure, but that it’s still worth adopting because the cost of experimentation is so low.
Not to put too fine a point on it, but this is bullshit.
If we’ve been studying the Social Business for such a long time without a result, that’s a clue. McAfee will argue that’s precisely why he has quit focusing on it and started focusing on the E2.0 world. But that world has been here long enough too. Lotus Notes was an E2.0 tool, for Heaven’s Sake. A few of the E2.0 companies at the very top are doing great, most are so so, and there is a consolidation underway. If E2.0 is the Megatrend those with the faith think, there should be so much green field that many more of these companies are hitting the ball out of the park. We should be tee’d up for 3 or 4 IPO’s imminently, just as soon as the market opens. I don’t get the sense we are there or even close. We may very well have a repeat of the old Portal market, where despite many companies being in the space, only one (Plumtree) managed to have an IPO, and a tepid one at that.
As an Engineer and Products Guy, I have to comment on the software, and not just stick to the people angle. I do believe it is possible to do what Moxie claims to have done, and that is to construct a User Experience so compelling that it drives rapid adoption. To be clear, I don’t think they have done it, just that it is possible someone could. The fundamental problem with the UX for these products is they start from the assumption that Generic Social is the Goal. It ain’t the case. Solving a real Business Problem and Delivering an ROI is the Goal. This is the essential point McAfee is missing. In his article, he argues putting people first is dumb because we’ve tried that and nothing happened, while:
What is novel is the digital toolkit available to help businesses and their leaders become more social, more open, more Theory Y, more Model 2, etc. In the 2.0 Era, these tools experienced a quantum leap forward, not an incremental improvement. Because business is so social, this quantum leap is a big deal.
Andrew, the digital toolkit is not nearly compelling enough as it exists today to turn otherwise recalcitrant cultures upside down and thereby prove your thesis. Cultures that are already very sophisticated in their Social tendencies without the tools can benefit. Others will not change, and if they would, there would be no end of case studies showing it. The truth is that recalcitrant culture is corrosive to E2.0. It kills it dead as Howlett suggests through passive aggression and politics, the way people have always killed things they were afraid of. Why should a little bit of software upset the very structure on which people build their livelihoods, their reputations, and their power bases? Andrew, go back and study all those writings about a Social Business that you’ve so eloquently quoted from, because those forces I mention are more than powerful enough to derail E2.0.So are we doomed? Not at all. As I mentioned, it is possible to create a UX that is an agent of change. The trick is to design from the standpoint of not having to change the culture before it can be successful. That is something that no E2.0 offering to date has yet done, though we have been trying since Ray Ozzie brought us Notes a very long time ago. How would this new UX operate? I have some ideas, but let me start with an example of a market where something similar worked with a vengeance.
Long ago, but still in my recorded memory, there were no such things as spreadsheets. We had accounting and accounting software, which produced reports. We had various attempts at using computers large and small to do analysis, mostly by programming. Very little analysis was actually getting done because despite the availability of simple languages like BASIC, and despite the cult following PC’s were gaining, you had to learn to be a programmer to do it, and that was too hard. Then along came the spreadsheet. What an interesting confluence of properies it had:
1. Spreadsheets have tricked more people into becoming progammers than anything else in history.
2. They did this largely by not forcing people to learn to be programmers.
3. Instead, they became an electronic embodiment of what was already being done. A “spreadsheet” for those that don’t remember what it used to mean, was a particular kind of paper form that accountants would lay out in order to organize their numbers for computation. They used to call them “electronic spreadsheets”, in fact. I remember to this day driving over to an accountant’s home to see one for the first time so I could understand what it was people were so excited about. And there it was, a piece of paper come to life and calculating live numbers as I changed the cells.
The spreadsheet is a metaphor for where E2.0 has to go if it is to regenerate itself, make a huge difference, and Cross the Chasm. The UX has to start from how people are working today, not how you’d like them to work after they have accepted your E2.0 tool. Proponents will say, “We’ve already done that!” It’s true, but they’ve picked the wrong things to emulate and automate. Wikis are automated the means to publish books or perhaps to keep community filing cabinets. They’re great. But who will argue that books or filing cabinets have a radical ROI? Likewise with automating the water cooler. If you look at it in that light, have you really solved the water cooler problem so much better that it has a huge ROI? Was the water cooler ever capable of delivering a huge ROI? Probably not.
I will leave this post on that note because there are so many business processes that have the huge potential for ROI that to drill down on any particular one would do the others a disservice. E2.0 vendors, heed the spreadsheet. Quit trying to automate the water cooler, quit trying to change the culture, and figure out something genuinely new to do besides copying Facebook!
Posted by Bob Warfield on November 4, 2010
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.
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?
Posted by Bob Warfield on November 2, 2010
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.
Posted by Bob Warfield on November 1, 2010
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.