Chatting Cars and Enterprise Software

Today’s big news is Salesforce Teaming up with Toyota to create a private social network where you can befriend your car and it will “tweet” you when it’s thirsty, need a checkup etc..etc..etc – see the details from @Krishnan’s post.  The opportunities are really endless – more on that later.   I have to get something off my chest first.

I admit when Chatter first came out, I did not get it.  Yeah, another activity stream, so what?  I’ve long agreed with Chief Curmudgeon Dennis Howlett that activity streams without business context offer little value in business.  Things started to get interesting when Chatter added the ability to follow documents, opportunities and other business objects.  Aha!  So now we’re getting business context in Chatter!  But why?


Continue reading here.

(Cross-posted @ CloudAve » Zoli Erdos)


FUD in the House of SaaS – More on Suites

Recently I wrote about the evergreen Best-of-breed vs. Integrated All-in-One Suite debate again, arguing:

Call me “old school”, but I also believe in the value of having one tightly integrated system for most business needs, and I believe it’s true not only for large corporations but much smaller businesses.  I don’t have CIO’s to back it up, but that’s exactly the point: I am talking about small businesses that don’t have CIO’s at all – in fact they  likely don’t even have full time IT stuff ( a good reason for SaaS in the first place), so they clearly lack the bandwidth to deal with integration issues and multiple system providers.

It wasn’t just hypothetical speculation, what really prompted my post ( and hence the reference to CIOs) was a study conducted by Brian Sommer who contacted several large corporate CIOs about SaaS implementations, and found that despite improvements in technology, and easy integration by firms like Boomi, Pervasive ..etc, CIOs still prefer to buy an integrated suite of applications and deal with one vendor for most of their needs.   It’s not what we think, it’s what they do – and they are the customers.  Says Brian:

But, customers will do what customers want to do.

Amen. But my post attracted a detailed comment from a PR professional (a fact that took a little digging to discover):

… the Suite approach requires the business to make compromises in areas of the business, and only works if you can run your whole business on that one suite – as soon as you need some other specialist system, or acquire another operation that you need to integrate, you’re in trouble because Suites, by definition, are not designed to make integration easy…

… essentially brings cloud apps together as a Suite by offering exactly the combination of tight integration, common interface and flexibility. Many businesses can already find everything they need on the platform, even the last critical element required for a serious business system: enterprise-class finance 😉 Many companies, especially smaller ones, don’t need a full ERP suite. They need a handful of critical applications that can grow with them.

Wow… where do I even start?   Perhaps by the only statement I can agree with:

Many companies, especially smaller ones, don’t need a full ERP suite. They need a handful of critical applications that can grow with them.

Yes, of course I agree.  In fact I am a small business myself, and guess what, not only I don’t need ERP, I don’t even need or use a CRM system, or one for business accounting.  The only lightweight business system I use is invoicing (happens to be Zoho Invoice), but frankly, I could get away without it.  Yes, some small businesses will want Accounting, and Accounting only, others will need CRM and nothing else – there are many good choices for them. And yes, (which the commenter represents) is great, and we’ve given it ample coverage @ CloudAve.

But that’s where reality ends, and plain old FUD begins. There’s nothing inherent in the “Suite approach” that would prevent customization, integration with additional systems, extension by third party apps.  In fact the key difference between an integrated Suite or discrete  point applications is just how much of the core business they cover natively before  add-ons are required.

And here’s the ultimate irony: I was reading these “ex-cathedra” statements (that’s nicer words for BS) while sitting at NetSuite’s SuiteCloud conference, that was all about working with development partners, releasing a new version of SuiteCloud, the app development and integration platform along with SuiteFlow, a graphical modeling and customization tool, and a bunch of other  announcements all geared to making and maintaining a thriving partner ecosystem, that builds on the core NetSuite functionality and delivers additional value to customers.

In fact the evening before the conference, CEO Zach Nelson spent an hour busting industry myths.  Now look at the slide above: he did not talk about NetSuite specifically, he was advocating Cloud Computing / SaaS in general.  That’s the somewhat usual formula:  myth spread by defenders of the “old model” busted by the innovators – who would have expected the old-time FUD served up by a PR flak for another SaaS provider… 🙁

At the conference itself I saw several customers presentations, like that of Campus Villages which replaced 38 instances of MYOB + Intuit MRI with NetSuite OneWorld, including extensions like Nolan Fixed Assets and Electronic Payments, Celigo Smartclient, and are currently evaluating Adaptive Planning.   Those are functions not provided by NetSuite, so guess what – they add third party apps, just like they would to Coda or any other system.

The key criteria for any software company trying to penetrate the SMB market will be vertical industry epxerience, and NetSuite has clearly stated their industry experience is Software and Services – everything else is open to the ecosystem.  Case in point is manufacturing:

NetSuite RootStock MRP

Suites are not customizable?  Just look at  Rootstock, a third-party developer house that created an entire MRP system on the  SuiteCloud platform.  If that’s not living proof of the system’s expandability, then I don’t know what is…

A key difference between the / Appexchange and NetSuite / SuiteCloud approach is that the former facilitates the creation of any product / utility that you can pick up from a marketplace, while programs developed on SuiteCloude all tie into the NetSuite system very closely – not only on the data but also on the UI level – i.e. the additional business functionality becomes available within the NetSuite UI. In other words they run so smoothly, the fact that parts of the system were written by a 3rd party is hardly transparent to the end user – which is just the way it should be.

So in the end, there is no hard rule that says Suites are inflexible, non-expandable: there only well-written and poorly written Suites, just like well-written and poorly-written point applications.  There will be businesses who only need a few point apps, and should not think of a Suite, and others who will benefit from the All-in-One approach.  It’s their choice.  What they need is honest information, not FUD.

(Cross-posted @ CloudAve)


Are Suites Really Sour? The Best of Breed vs. Integrated Suite Debate.

The evergreen Best-of-breed vs. Integrated All-in-One Suite debate is back again. This will be a somewhat long post, so let’s sit back and start with some entertainment first.

Episode 2, “Suites Are Sour”  is from the mini-series SuiteMates, which I admit I find hilariously entertaining, albeit rather pointless.  Why?  It’s run by supply chain solution provider Kinaxis, but I don’t see much direct benefit to them. I’m reminded the Bill Gates – Seinfeld commercials: what’s the point?  But hey, we’re being entertained:-)

Now, back to those Suites.. are all Suites really Sour?  Fellow Enterprise Irregular Brian Summer clearly does not think so, his money is on the Suites, here’s why:

One of the biggest value drivers behind a customer’s move to SaaS is the reduced internal IT support cost a company has when using SaaS products. In the SaaS world, the vendor maintains the application not the customer. But, in a best of breed SaaS world, the customer is back to maintaining interfaces and integration aspects across a number of (SaaS) applications.

If the argument sounds familiar, it is – it was the same in the good old on-premise world, but much of it holds true in the Cloud, too.  Besides, this isn’t simply Brian’s own opinion, he has conducted a poll of large corporate CIO’s and most expressed strong preference for integrated business solutions, a.k.a.  “one throat to choke” (well, not exactly with those words…).

Call me “old school”, but I also believe in the value of having one tightly integrated system for most business needs, and I believe it’s true not only for large corporations but much smaller businesses.  I don’t have CIO’s to back it up, but that’s exactly the point: I am talking about small businesses that don’t have CIO’s at all – in fact they  likely don’t even have full time IT stuff ( a good reason for SaaS in the first place), so they clearly lack the bandwidth to deal with integration issues and multiple system providers.

This is not a popular view, after all the Millenial World View is all about open standards and APIs where best-of-breed cloud services that can seamlessly integrate and work together well.  I’m all for innovation, and hope we will get there one day – but for now the existing examples are all one-off, individual integrations between specific systems, or at best, ecosystem “satellites” centered around, the Google Apps Marketplace and the like.  These are great solutions, but not enough to run a complete business on them.  In the meantime businesses are looking for available (Cloud-based) solutions NOW.  So yes,  I admit, my view is less visionary, more constrained by market realities today.

Brian cites WorkDay as a potential SaaS Suite provider: they have the right DNA, coming from the Founder who built once-successful PeopleSoft, and they are building truly Millenial Software from the grounds up as Phil Wainwright eloquently points out – but for now they still have a Human Resources / Finance focus only.  Far from a complete solution, just like the other successful SaaS players in the Enterprise arena, like SuccessFactors, RightNow, ServiceNow, and the like.

Yes, I hear you… I missed a big name:, the GrandDaddy of SaaS or the Cloud or whatever the next fashionable name will be.  An amazingly successful company, and true innovators – having started as CRM company, moving on to as Platform provider, and who knows, tomorrow it may be a Media company? 🙂  As long as the keep on moving to hot new areas, always picking the low-hanging fruit, the company and it’s stock price will remain hot.  Again, a great company from an Investor’s point of view.  Just not a Complete Business Solution.

One and a half SaaS Suite players

I can count the number of SaaS Business Suites that actually reached significant traction on one hand.  In fact the exact number is 1.5.  Yes, one and a half – and for now they mostly cater for the SMB segment, with undeniable ambitions to “grow up”.

netsuite The “One” in  that 1.5 is NetSuite.  Having started as NetLedger, the company has developed an integrated All-in-One solution, encompassing ERP, CRM, e-Commerce .. you name it.  Those acronyms are becoming quite useless – in that respect I agree with Dennis Howlett who says we should “dump the  disciplines formerly known as CRM/SCRM/SCM/ERP/3PL/HR/HCM/E2.0….etc” – hence I stick to the term All-in-One. Or Business Suite:-)  It’s been a long (and winding?) road for NetSuite: developing a full suite of apps you can run a business on is by far more complex than throwing out point applications.

The company also learned the hard way that with business complexity (please note, I am not talking about Software, but Business complexity) comes a more difficult, stretched out sales process.  The fact is, as much as I am a fan of the click-to-try-click-to-buy pull model, the more business areas (and stakeholders) are involved, the less feasible the fully pull model becomes.  A Business Suite is not something you simply pick up from an App Store:-)
So NetSuite experimented with more direct sales model first, gradually building towards a more channel-based model, to the recently announced SP100 program in which partner VARs get the entire first year subscription revenue.  Along the way they grew functional richness as well as market penetration, to the point that they often compete with Enterprise giant SAP directly.  Now, let’s quickly qualify that: NetSuite is not comparable to the SAP Business Suite, but it is often an ideal satellite solution for smaller divisions of large companies, many of which just got acquired and are facing the choice of a long SAP implementation vs. a SaaS solution from NetSuite (see Ray Wang’s post on two-tier ERP strategy)

I should probably mention that way back, before their IPO and the fame that came with it (from the times of NetWho?) I was an early NetSuite customer, picking it over the market leading CRM (and I mean that as a stock symbol), simply because it had a better process flow, even for Sales, which I was heading at the time. (Yes, we got p***ed learning we’d have to create Sales Orders outside the other system, even though we had quotes in the system, only to come back and re-enter the data manually).  NetSuite was simply a better CRM system, even before considering other business areas.

Parallel to our NetSuite implementation we introduced a Wiki, JotSpot, which just launched in those days (since acquired by Google) and soon we realized a lot of the support information for Sales could either reside in NetSuite or in the Wiki.  This has been bugging me ever since:

Why do structured, process-oriented systems and unstructured  collaboration tools live in different worlds?

Like I’ve said, I’m all for Suites, but the true Suite in my definition includes integrated collaboration and communication tools – I’m still waiting for that … perhaps not for long 🙂

Now, if NetSuite was the “one”, who is the “half”?   It’s SAP’s very capable, but dormant Business ByDesign – which may just come to life later this year.  But I’ve been torturing you long enough, so let’s leave that to another discussion.

(Cross-posted @ CloudAve)


Socialtext 2.0: Usability vs. Usefulness

Socialtext recently announced version 2.0 of it’s enterprise wiki. The two big news are a completely revamped user interface, aiming to make Socialtext a lot easier to use, and the publication of the REST APIs to support integration and mashup development. For more information watch this screencast by CEO Ross Mayfield, and see this review at TechCrunch.

The revamped UI is a huge deal, and it’s been long overdue. For some background check out Jeff Nolan on the “UI sucks” issue. One may agree or disagree, but as long as there are reviews like this:

I have tried on at least four separate occasions to use and like Socialtext but I can’t…I just can’t use this application.” – well, you definitely know you have a problem.

Interestingly enough Socialtext, the company realizes how important ease of use is, and they are contributing resources to bringing WYSIWYG Wikiwyg editing to Wikipedia. But let’s focus on Socialtext, the product for now.

The new UI is aesthetically pleasing, has nice colors (somewhat reminds me of JotSpot’s blue), but most importantly it’s clean, simple, in short it passes the “blink test“.

thumbs_up The Home Page is of key importance in the new release: a Dashboard gives users a quick glance of a shared whiteboard, personal notepad, customizable watchlist, a listing of what’s new (i.e. recently changed pages) as well as the users active workspaces (i.e. wikis). The Home page has become the central place where you can access all extended features, like a listing of all pages, files, tags, or change settings. You can start adding information using the New Page button, which, just like the Edit and Comment buttons on all subsequent pages clearly stands out, again, passing the “blink test”. I love the new colored side-boxes for tags, inbound links and attachments.

I can’t emphasize enough how important inbound links (backlinks in the previous releases) are – a wiki is all about associating pieces of information with each other, and the inbound link shows you where the information on the current page is used elsewhere. In wiki systems without this feature on would manually have to create them, a task most often forgotten (as it does not fit the natural flow of creating new pages), thus those systems don’t offer the full potential of a wiki. I can’t for the life of me understand why inbound links haven’t yet made it into the standard feature-set in JotSpot 2.0, when it’s been long (for more than a year) available as a downloadable plugin on the Jot Development wiki – but how many users search the development wiki? In contrast, Atlassian’s Confluence has long supported incoming links.

We know from Ross and others that in creating the new design the primary objective was to increase ease of use, and in doing so Socialtext conducted customer usability studies. The number one customer request was to reduce clutter, which was quite abundant in Socialtext 1.x. They certainly achieved this objective – perhaps too much. Playing around with the beta I run into trouble trying to create a page from an already existing page – I simply did not find the New Page button. “This is something too obvious to be a bug”, I thought, and Ross proved me right: It’s all part of “getting rid of the clutter” and doing what customers had requested.

Socialtext believes this helps eliminate a frequent problem: the existence of orphan pages in wikis. (Orphan pages are valid, existing pages that no inbound hyperlinks point to; thus it’s difficult to find them, other than by searching or listing all pages).

I am not sure binding users to the Home page is a good idea (it’s not just the “new page”button, all other extended features/tools are anchored here). To me the natural flow is typically top-down: one would create a subpage from the parent where the summary level thought flows, thus creating a parent-child relationship. In a business wiki, where after a while you’ll end up having a large number of pages, the further away you are from the right place (the parent), the more likely you will forget to create a link to the new page, thus may end up with a proliferation of orphan pages.

Interestingly enough, the most elegant solution to the orphan problem comes from two products at the opposite end of the spectrum: Wetpaint, the friendliest consumer/community focused wiki (actually a blend of wiki-forum-blog features) and Atlassian’s Confluence, the market-leading enterprise wiki. Other than the standard user-created links within the flow of text, these products also offer an automatic index of subpages along with each page. JotSpot‘s 2.0 release offers a less foolproof but reasonable solution: when you create a page by using the “new page” button, technically it becomes an orphan, however when you hit “save”, you’ll find yourself at the parent level where a quick alert pops up proposing to create a link to the child page you just set up.

There’s a fool-proof way of creating new pages that can’t become orphans: create a link before the page, and forget the “new page” button. While typing, wherever you want to branch out to a new page, insert a link to the page about to be created, typically by highlighting text and using the “link” icon, or in JotSpot you have the option of simply typing a WikiWord (also referred to as CamelCase), it becomes a link automatically. This “trick” creates a shell, essentially a placeholder for your new page: you can add content later, but since it’s already linked to, it can’t become orphan. All the wikis I’ve talked about allow this method, but Wetpaint and Confluence don’t really need it, since they provide navigation based on the auto-index of child pages. (Update [2/17/07]: I’ve just discivered a perfect existing term for what I am trying to epxlain here: LinkAsYouThink.)

Back to Socialtext, perhaps there is more to the new design than the desire to create a very simple, clutter-free user experience: the underlying philosophical difference between hierarchical structures, parent-child data relationship vs. everything being flat (created at the home page ) and only associated through links embedded in page text. But hierarchy, structure are not necessarily evil; only pre-existing ones are.

smile_wink We tend to think in structures, need organizing principles – there is a reason why books have a table of contents. Wikis, as unstructured as they are in “virgin state” are a good tool to create structure – our own one. The assumption of a parent-child relationship mimics our usual workflow, and it does not impose a rigid structure, since through through cross-linking we can still have alternate structures, no matter where we create a page.

Perhaps that’s the fundamental difference between Socialtext and the other wikis I’ve mentioned – which would explain why it doesn’t have breadcrumbs (navigational line at the top): this standard feature of all the other three products (Confluence, Wetpaint, Jot) does not really fit in Socialtext’s flat world.

My other issue about with Socialtext 2.0: I really would have expected to see document versioning by now: when you upload an attachment (typically doc, ppt or xls file), Jot and Confluence shows the current version, indicating the most recent version number and the user who changed the document last. Click for details, and you get all previous versions and details. Confluence even allows you to label every instance of the attachment with a comment. Socialtext simply lists all documents with the same title (or not), not recognizing them as version of the same file.


Finally, a minor gripe: it would be nice to see threaded commenting, like Wetpaint and Confluence does, allowing users to enter comments to a page itself or to a previous comment. Socialtext, just like Jot, only has a flat list of comments.

Summing up, the new Socialtext 2.0 Beta is really good-looking, but in my view limits functionality for (perceived) ease of use. That said, it’s a beta, and Ross conformed repeatedly that they are seriously evaluating test user comments and it’s possible that the final 2.0 release will have a better solution for the edit/navigation/orphan problem.


Last, but not least, let’s revisit document versioning. It’s very-very important. In my “prior life” where as corporate VP I introduced a wiki-based intranet to the company, we used it for document management first, before exploring more of the native wiki functions. But here’s the catch: document versioning in wikis solves a very old problem, but solves it on the bases on yesterday’s (OK, today’s ) technology. Even with proper versioning one has to download documents, locally update them, then upload them back up to the wiki. The process is a lot easier using Office 2.0 applications, be it an editor, spreadsheet or presentation. There is no uploading/downloading, all updates happen online, if need be by multiple users at the same time, and instead of attaching them, one would simply link to, say a Zoho Sheet or Presentation from the wiki.

My ‘dream setup’ for corporate collaboration: a wiki with an integrated Office 2.0 Suite. The next step will be the wiki integration with ‘traditional’ , transactional enterprise systems – that’s a little further away (although … reading this, who knows?

smile_wink ) I hope to discuss many of these concepts with my readers next week in San Francisco, at the Office 2.0 Conference.

Update (9/5): For more insight read Socialtext 2 Design.

Update (11/1): Usability review on InfoSpaces.