Watch that stream become a wave

Hello everyone!

We are excited to be working to support the Google Wave Federation Protocol in SAP StreamWork to let tools – collaboration or business – work seamlessly between any wave server, including Google Wave! With SAP StreamWork, we help business be more productive by letting people drive decisions together. Since our first BETA announcement a number of months ago we have been constantly compared to Google Wave, due to the real-time characteristics of the collaboration patterns we use. While products each have a different focus, they are also naturally complementary, and from the moment we saw Google Wave we were excited about the possibilities of connecting the two. This year’s Google I/O is our first opportunity to tell the story of how we plan to work collaboratively with Google, the Wave Federation Protocol, and OpenSocial.

For those of you who are not familiar with SAP StreamWork, it is aimed at transforming the way people work. When Google developed Google Wave it asked the question, “What would e-mail, instant messenger, and collaborative document creation look like if it were invented in the 21st century?” Similarly, SAP asked the question, “How can people solve important business decisions in a natural, fluid way, making every day more effective and fun?”. SAP StreamWork is a new on-demand, collaborative decision-making application that brings together people inside or outside your organization with information for fact-based decision-making and interactive business tools for collecting feedback, strategizing, and brainstorming, and is available today in a free version for anyone. It is also fully extensible by developers using open REST APIs.

Many of you make decisions every day, using a range of tools, from e-mail, to white boards, to shouting matches, to business applications and business intelligence. We get the work done, but it often becomes chaotic and hard to follow and can hinder clear decisions. Wave is modernizing collaborative communication; SAP is modernizing business. SAP StreamWork brings together people, information and proven business methodologies to help teams naturally and fluidly work toward goals and outcomes. Teams can assess situations together, develop strategies and make clear decisions, with a full record of what transpired. What better idea than to include anyone with a wave account?

So this is how we see you rolling in the near future: A supplier just notified you they couldn’t deliver materials that you need tomorrow to continue production. Crap! You bring that context fluidly into SAP StreamWork and assemble a team, bringing experts in that industry to see who might have capacity. Some of the people you know are registered as Google Wave users – instead of having to enter a different system, the business discussion complete with analytical and business tools show up in their wave inbox. It no longer matters where people are, or what tools they prefer – they can safely make decisions, in real-time, and directly drive the business applications that run the largest companies in the world. Now that feels like an improvement, yeah?

At this year’s Google I/O we will show the beginnings of this. But, what exactly, are we talking about?

Passing the Wave (Wave Federation):

At I/O we plan to show how SAP StreamWork has added a Wave Server to the platform to enable conversations between SAP StreamWork and other Wave servers. In SAP StreamWork a user starts an Activity where in they invite other participants to collaborate with them on a work activity like making a business decision. The group can then add the data and tools to guide them through the decision process. When an activity is created, StreamWork creates a new wave and federates the content of that Activity to the Wave server of any Wave users that may have been invited to that activity. With this integration Wave users will be able to seamlessly collaborate with SAP StreamWork users to work on the important decisions they need to make every day.

Go Go Gadget! (Gadget / Method Interoperability):

In order to ensure that content from an Activity or wave is properly federated between each other, we had to ensure that the content found in both systems was compatible with each other, and this included Wave Gadgets and StreamWork Methods. Wave Gadgets are shared programs that run inside waves, and are very comparable to StreamWork Methods which are business tools that run inside StreamWork Activities. Theproof of concept will show the compatibility between a StreamWork business method being federated over to Google Wave. We intend to create a generic compatibility between StreamWork Methods, and Wave and OpenSocial Gadgets so that developers will be able to ensure that gadgets or methods built for one system will work in the other.

These are the early days with our Wave Federation Protocol support and we are still in proof of concept stage, but we are excited to discover together with you how Wave, OpenSocial and StreamWork naturally extend each other, and we intend to deliver value to our customers, based on this work, within the next year. So please let us know your ideas, and we can figure out how the make the world a little more productive every day.

-David Meyer, SAP

Beware the Water Hammer

Water Hammer:  a pressure surge or wave resulting when a fluid (usually a liquid but sometimes also a gas) in motion is forced to stop or change direction suddenly (momentum change). Water hammer commonly occurs when a valve is closed suddenly at an end of a pipeline system, and a pressure wave propagates in the pipe.

They say everything you need to know you learned in Kindergarten.  I still managed to learn a little in later years, including my graduate years studying water.  But the concept is the same -- the world is full of patterns, and systems begin to look alike regardless of the discipline.

Which brings me to my point: driving change in an organization has analogies to driving change in a fluid system.  The people dynamics have corollaries in fluid dynamics.  People have momentum and fluids have momentum.

When you close a valve in a water system, it is easy to congratulate yourself for your success.  No water is passing!  I have changed the system!  Problem solved.  But depending on the system, seconds or minutes or hours later you might be dead.  Explosions, ruptures, and implosions, sometimes deafening and disastrous, can be your end.  Why?  The accumulated momentum in the system is hard to stop.  You have to think of all of the water, all the way upstream, and determine where all of that momentum will be absorbed.

In working on 12sprints, we had to change the system of SAP to account for some of our new models.  Elastic subscription services have a ton of ramifications for a traditional software company, from accounting to legal to privacy to support, and every time we reached a decision (closed a valve / redirected flow) we learned that other parts of the system had momentum we hadn't anticipated.  And were there explosions?  That would be too strong a word, but there definitely turbulent debates and some bent metal in the expansion joints.

My conclusion?  Change is a lifestyle.  It is a lifestyle only survived by being relentlessly attuned to the rest of the system, and using a simple recipe when the pressure builds: be open, creative, and luckier than most.

And always wear waterproof clothing.

Where's that confounded data?

Where did I put that data again?

I get data in email attachments, in PowerPoint, in Excel, in Crystal Reports.  I read data on the web.   I get data on phone calls, over IM, from the mouths of customers.  I hear about data that other people have and ask, sometimes timidly, for a copy.  Like my brother’s MP3 hording I want to have it, just in case.  There is a comfort in having all of this data.  That is, until I need to find it.

Finding data is hard.  With Draconian email quotas and the difficulties of searching archives, it always becomes lost.  I can find my music now in iTunes, but what about my data?

More and more I use two very different tools to help me survive this information-saturated world: Evernote and SAP BusinessObjects Explorer.  Think of Evernote as your external brain, where you can store your every thought for perpetual retrieval, and Explorer as your company’s external brain, where every last bit of data can be retrieved instantly.  I'll talk more about Evernote later, but this week seems to be all about BusinessObjects Explorer.

Yes, this week SAP BusinessObjects Explorer is being launched, but the technology antecedents to this powerhouse have been around a while.  It is comprised of a product previously known as BusinessObjects Polestar and some cutting-edge in-memory acceleration technology previously manifested in SAP Business Warehouse Accelerator.  Yet it is their combination is truly stunning.

I am an impatient man.  I love my Mac since I open it up and it is ready with no delay – I cannot wait for something to boot.  I have loved using Explorer over the last year since I can hit a web page and answer my questions as soon as I ask them – I don't have to wait for someone to build a report.  I just have a conversation:

You say revenues are bleak for a certain product in the United States?  Let’s look at it by city.  Whoa.  San Francisco and Washington are down, when they are up for the rest of the business.  Let’s get California sales on the phone and see what’s happening – send them the link.  Richard, what’s going on here?  Oh, we didn’t run the right campaign?  Let’s budget for that next quarter, it showed good results everywhere else.

[caption id="attachment_201" align="aligncenter" width="500" caption="Fun with Data"][/caption]

Bingo.  In a 60 minute meeting, we can have 5 conversations like that, and have discussions based on substantive fact.  Coming from the data-desert of past jobs, this kind of knowledge oasis is intoxicating.

Yet combined with the in-memory technology the potential is breathtaking.  Terabytes are now your friend, they are not demons threatening to slow your life to a crawl.  Petabytes are an afternoon snack.  You don’t have to look at statistical samples, you can look at the truth.

So as I index the world around me, play a little for yourself online.  See what it is like to manipulate 1000 rows of Excel in this remarkable tool.  And then imagine what it would be like to manipulate the world.  That is, if you can handle the truth.

Torture is bad, everywhere.

In Torture, Plain and Simple, Suzanne points out that while it is true that torture doesn't work, it doesn't matter: it's illegal.  But let's dwell for a minute on the first point: torture doesn't work.

Elaine Scarry gave this subject a scholar's attention in The Body in Pain, where she explained that pain nullifies the world around us -- with extreme pain nothing exists but the pain.  This deconstructs the ego to a point where conversation is meaningless and information extracted in this state has one goal: to make the pain stop.  Say anything to make the pain stop.  In fact, there is a long history of torture being used to extract misinformation to support campaigns of misinformation.

While this simple fact is well established in research, it seems appallingly under communicated.  If it was well communicated, I imagine it would lead to this:

Interrogator 1: Should we do it?

Interrogator 2: Well, it doesn't work.

Interrogator 1: OK then, let's not bother.

The complex ethics simply disappear.

The Art of Trust

I was about to tweet about some happy cows I saw while driving to work today, until I remembered the law and thought better of it.  The cows weren't worth a ticket.  But aside from the desire to avoid tickets and stay alive, there is another hazard of automotive texting - thumbing the wrong key and sending the wrong message, perhaps to the wrong person.

When I hired a guy last year entirely over SMS I committed a gaffe - I received a Twitter DM (direct message) and hit reply, sending the reply to all of my followers.  This is a variant of a DM Fail, when people think they are sending a message to just one person but instead broadcast it widely.  In my case I uttered something relatively harmless like "req opened this week."

Something more nefarious happened recently on Twitter: they actually sent DMs to the wrong people, detailed in TechCrunch.  Jason accurately called this a "breach of user trust," but it was resolved quickly.  Twitter is not alone here.  A colleague of mine was using an esteemed Web2 product when they one day got a trove of someone elses messages dumped on their desktop over IMAP.  Only once, but once is all it takes.

The Downside of "Efficiency"

Preamble: I started this post over 3 months ago, so many of the links are a bit dated.  I decided to finish it up ad post it since this very delay illustrates the point I'm making: in a highly stressed system, where all capacity is consumed, minor additional stress can make a system collapse.  That feels a lot like work today, where budgets have been cut, and we all have to do more.  So we lose time to think, let alone blog.

---

Times are tough.  Buckle down.  Buck up.  Be lean.  Be efficient.  Do more with less.

Yes, Indeed.  But before we all become super-efficient pieces of a super-efficient machine let's take a moment for pause.  Because there is a downside of efficiency (or at least what the world around us often calls 'efficiency')

I think it was in graduate school when it first became clear to me that efficiency was great until there was a problem, and then it wasn't so great.  I was studying complex water systems, and how to manage them to leverage the most capacity (electrical and consumption) while preserving fish happiness and keeping the land pretty.  Once you balance all of the uses into a finely tuned system, and make it reliable, people will build complex systems around that reliable water, and if it isn't there... well complex systems start to break down.

What this amounts to is setting up systems to have the butterfly effect, since making systems more efficient generally creates more complex dependencies.

Consider George Monbiot's recent interview with Fitah Birol's, Chief Economist of the International Energy Agency.  Much of the world's governments rely on assessments of the IEA regarding how long oil supplies will last, and it turns out they now think they were off, but only by a factor of 2.  They had modeled a decline in output of 3.7% per year, which they now think is 6.7% per year.  And we're using more.  So we'll be running out around 2020.  This means that "unconventional" sources of oil, like tar sands, would need to be processed into oil to keep the machine running, but don't worry: that would only amount to an environmental catastrophe.  It is similar to the phases of drilling in conventional wells, where primary, secondary and tertiary recovery start to require more resources, be worse for the environment, etc.

Or consider the minor business dispute between Russia and Ukraine that led to freezing out Slovakia, the Czech Republic, Austria, Hungary and Romania over the past few days.  As gas flows efficiently between regions, complex systems begin to rely on it, so it better keep coming.

In other words: efficiency increases output, output begets demand, demand requires continued output, and the scenarios of Too Big to Fail, or the corollary, Too Big to Exist.

To my friends who work in software this is just obvious: we are asked to use resources "more efficiently" all of the time, which usually means very little spare capacity to handle unexpected events.  And the software business = unexpected events.

So my solution?  I endeavor to become less busy.  Take more breaks.  Chew food slowly.  Say no.  Which will of course require and enable "true efficiency," but it might not look like that on the books.  And, of course, will never happen.

Peak production, peak waste, social media and Must Ignore

I enjoyed Tim O'Reilly's post today, Waking up from the 'Nightmare on Tech Street', itself a response to Om Malik's recent piece. Finally, I felt, someone was touching on the upside of oil demands finally declining, or celebrating the slowdown in our culture of excessive consumerism.

As he notes, peak production usually equals peak waste:

In a recent conversation with my daughter Arwen and son-in-law Saul Griffith, Matt Webb remarked that he'd like 2008 to be remembered as the year of "peak consumption." Saul pointed out, though, that the term "peak waste" is perhaps more accurate. In an analogy to peak oil, he suggested that maybe we've reached the pinnacle of waste in our consumer culture. I do wonder if we will look back at the past few decades as a kind of sick aberration rather than a golden age, with good times we want to get back to. Like Saul, I'm hopeful that we can get rid of the waste, and get back to creating things of lasting value.

I've heard the term waste applied in another way lately, in regard to people spending time in social sites, such as Facebook and Twitter. These pundits usually follow such comments with an aside like, "I don't need to be talking to people about what I just ate for lunch." And then, of course, people laugh, thinking, Oh, those silly, wasteful twitterers.

Those of us that actually use Twitter may have another perspective: perhaps this is a lean, efficient mode of communication. Perhaps a glance at it a few times a day can lead to unexpected insights and help build better relationships. And maybe even be a little bit fun.

OpenSocial is making progress; the world spins faster

Jason Kincaid wrote a nice piece on TechCrunch about the progress of OpenSocial (a standard interface for plugging your social application into a social network), with a rather attractive and impressive chart:

So what does this have to do with decision making? Not much, but it is such a pretty chart, so I thought I'd post it.

Actually, it is a bit relevant. We've talked about how the workplace is being transformed, and this is part of the reason... the increasing social aspects of applications. While OpenSocial is usually talked about in context of the popular consumer Social Networks (which gives them the ridiculous and oft-misleading numbers above), a growing number of enterprise applications are starting to utilize it, for a simple reason: it is not that hard, and it gives you wide reach.

Cars on Demand, College Laziness and Modern Efficiency

I'm a big fan of Zipcar, as those around me know.  I just reserved one for tomorrow, and since I waited so long, I had to choose a pickup waiting at a local McDonalds, instead of my usual Prius down the street.  But I didn't mind since it took me only about 25 seconds to find it, book it, and have a car ready for me tomorrow at 5:30 AM.

As I did this I was thinking about speed.  Satisfying the speed of business is not about perfection  -- it is about things being good enough, provided they are fast enough.

People People People People People

I work at a large company.  My nature is to move quickly, which often feels impossible.  In the past few weeks, a lot of the impossibility has involved not knowing the right people.

A lot of smart people think about this, for example the labcoats behind Organization Network Analysis.  Looking at how people work together in a network can often yield surprising insights into whether the organization can move fast or slowly.

A lot of the rest of us do this everyday without thinking about it, with LinkedIn, Facebook, Twitter, Yammer and the rest, leveraging each other to speed ourselves up (I didn't list MySpace, since that slows people down).

But it comes down to one thing... the degree to which you can communicate effectively, quickly, and trustfully with the people you need to get things done.  If you couldn't conceivably get agreement with someone over IM then you don't have the right relationship with them to decide things in business time.  The last guy I hired I negotiated purely over SMS while I was on the tarmac, otherwise I would have lost him.

Fast Fast Fast Fast requires People People People People.