Nodeable Blog

When you’re charting new territory with a product or service, it can be difficult to explain exactly what you’re doing.  It’s easy to say “We’re like XXX, but faster/cheaper/better.”  But when you’re helping to create a new market, you have to invent a new vocabulary to describe it, or at least find old markets that can serve as analogies for the new market.

Such is the case with a rising breed of social, enterprise services.  Wells Fargo analyst Jason Maynard is predicting a $4 billion market in “engagement apps” over the next few years, a market that hasn’t existed before and can therefore be somewhat squishy to describe.  In a new report — “Fostering the People: The Shift to Engagement Apps” — he makes a valiant attempt:

Business applications are moving beyond merely transactional and analytical functions and are becoming critical tools to engage with customers, to improve productivity, and to facilitate collaboration within the enterprise and throughout the entire value chain. With the digitization of local commerce and the growing adoption of social operating platforms, mobile computing, and global value chains, we believe the trend toward business of adoption of “Engagement Apps” will grow rapidly and rise in importance over the next five years.

These systems represent a new layer in the application topology, moving beyond analytical and transactional systems. We define engagement apps as applications, processes and analytical tools that enable companies to actively interact and empower interactions with customers, with and between employees, and with external partners across the value chain.

These apps should be native cloud, socially aware, mobile ready, and embedded with intelligence. Collectively we contend the shift to engagement apps will manifest into a new system of engagement for these processes that sit above existing transactional and analytical applications and data. We think engagement apps can be segmented in the following three main categories: (1) social CRM or customer experience management, (2) internal productivity, and (3) external value chain collaboration.

Enterprise software companies are increasingly turning to consumer-facing services like Facebook and Twitter to figure out clever ways to engage users.  Even stodgy old IBM, which has inflicted the Lotus Notes experience on enterprises for years, is getting in the act.  This isn’t surprising, given how appallingly bad the user experience has been for enterprise software.  If IT isn’t using a system, it’s difficult for the purchasing team to focus on the needs of end users, rather than their own requirements (security, features, etc.).

But most activity streams are still a rushing river of information, not nearly selective enough about the type, timing, and form of the information they share.

Take my own personal Twitter stream.  To keep my stream manageable, I only follow 332 people/things.  Even this, however, is way too much.  I miss most of what happens in my stream, as I don’t want to spend all day staring at it.  I have work to do.  (Really, I do!

Yes, I can set up filters (saved searches and the like), but I find these a bit difficult to manage in Twitter’s browser-based interface, and I no longer like going to a separate, native client.  What I really want is for Twitter to become much better about serving up a pared-down stream with the updates I actually want to see.

Facebook tries to do this with its “Highlighted stories first” sorting mechanism.  But in my experience it does a terrible job of determining what I want to see first.  And this after plenty of coaching the system as to whose updates I want to read on a regular basis, and whose I can live without.

Here at Nodeable, we think we’ve cracked the code on managing the stream for cloud systems. After talking with developers and operations people from a range of large and small enterprises, we have a pretty good idea of what sorts of information people want from their systems stream, and we crunch a lot of data on our global pool of users to ensure we’re constantly balancing what we inject into the stream and what we hold back for individuals.

A user, for example, likely doesn’t want to see her Ubuntu guest images on AWS constantly chirping that “Everything is fine.”  That’s the equivalent of “Woke up.  Made toast.  Ain’t life grand?” tweets that no one wants to read.

But if Ubuntu is trending, or if a threshhold storage limit is reached, or if memory is spiking 30 minutes after a GitHub commit went live, I probably want to know those things.  And if we can see that Amazon East is slow, suggesting a move of one’s app to Amazon West is something I’d likely want to know.  And so on.

At first, it’s unlikely that developers will want the system to make big decisions for them.  But over time, developers want to spend building applications, not managing their infrastructure.  Each developer has different requirements, however, and Nodeable allows her to guide the stream accordingly.

In my case, for example, I want to see all of our GitHub commentary and commits, and so have that data stream set to deliver verbose updates (see left).  I care less about our AWS instances, however, and so tightly rein in that stream.

Nodeable makes tracking the software development lifecycle easier, both by delivering timely, useful information in a data stream, but also by helping to take actions against that data stream, based on set responses to certain thresholds, but also based on what other users do in a given situation, and what you’ve done in the past.

The stream, in other words, is not the sum total of what’s going on in one’s cloud systems like AWS, GitHub, JIRA, Salesforce, etc.  It’s the actionable, information-rich stream that follows and coaches the software development lifecycle.

Or, rather, that’s what it should be.  And it’s just part of what we’re doing at Nodeable.

One of the casualties of the Big Data explosion is that we still have little idea what to do with all these data. In a world that allows us to collect data on click-throughs, purchases, weather patterns, traffic, etc., we can amass so much data that we’re drowning in it.

My friend and venture capitalist Bryce Roberts made this point recently, arguing that “Data, big, medium or small, has no value in and of itself. The value of data is unlocked through context and presentation.”  He’s right, and the solution isn’t to graduate and hire a nation of data scientists.  (Apparently we have a shortage.)

No, the solution is to make the data speak to average people, using familiar media like Twitter or Facebook.

I view this as similar to what Microsoft did for system administration and development.  Microsoft may not have always played fair on its road to the top of the enterprise software heap, but much of its success stems from enabling average IT people and developers to be productive through things like Visual Studio.

Sure, we’re all above average.  Or so we think.

But for those few, unlucky souls doomed to be average, well, the Big Data movement needs to lower the bar to entry and productivity.

This is one of the guiding themes at Nodeable.  We believe strongly that the DevOps trend is real, and means that a great deal of exceptional programmers are suddenly…below average Operations people.  It’s not that they have low IQs.  It’s just that doing operations well requires years of experience, just like doing most anything well does.  Developers, however, want to focus on building applications.  They want 90 percent of their job to be “Dev” and 10 percent to be “Ops.”

So that’s what we do.  We tame the “Big Data” in cloud systems to enable developers to visualize and control the complete software development lifecycle.

What to call this?  We’re still not sure, but Dan Woods comes close in a recent blog post for Forbes:

Operational Big Data is about automating and streamlining the process of distilling huge amounts of data into a form that can support decision making and process execution….I call these vendors [EMC, IBM, etc.] operational because historically their main value claim is to increase speed of processing not the speed at which analysts work. All of these vendors know that they will succeed more if they can make their products less complex and more agile, and some like EMC Greenplum through its Chorus product are attacking the issue head on. All of these operational vendors support a process of discovery, but usually it is on that is far more intermediated than the hands on experience of using something like Splunk or 1010data. The data visualization and exploration vendors Qlikview, Tableau, and TIBCO Spotfire have all been helping bring agility to the operational data vendors.

I’m not sure I’d agree that these particular vendors are doing enough to make Big Data easy to understand and actionable, but I like the term “Operational Big Data.”  And I agree with the thrust of his argument that the vendors who succeed at making complex data easy to visualize and take action against will be big winners.

That’s what we do at Nodeable.  We make systems data as easy to read and work with as a Twitter stream, which is considerably easier to grok than IBM’s Netezza or other products from the traditional enterprise software crowd.  They’re still so concerned with how “big” they can make the data that they’ve neglected that the real value is in making it “small,” that is, easily understood by someone that didn’t get the PhD in data science.