OpenSocial and the Enterprise

Okay, we've heard a lot about Google's OpenSocial APIs, and clearly opinions vary, from unbridled excitement to downright skepticism from Tim O'Reilly, at least regarding what is available right now. But most of the commentary on the web has to do with the consumer space (not surprising), so what does this mean for the enterprise?

Let's start with what OpenSocial is today: it is a way for developers to write a social app (or micro-app) that plugs into any social "container" that supports the API, much like you would write a proprietary Facebook app to plug into Facebook. For people that have been involved in portals, it is analogous to the standard portlet APIs, such as WSRP or JSR-168, which let you write a portlet that works in any portal. Wow, that's exciting.

Well, it could be, but it isn't now, except for developers or startups trying to get presence in the consumer cloud. As Tim O'Reilly notes, it doesn't help the end user.

Most modern individuals have fragments of themselves in several social networks. We need a sort of broker that can figure out which applications can have access to which fragments in which networks. This way we don't need to repeat our information again and again but the value of the networks we join can be preserved effectively, and help the knowledge worker in the enterprise.

We've talked about AquaLogic Pathways, and how it maintains an activity graph of interactions in systems, both explicit and implicit. This graph helps people find people as well as information. This implicit social network could certainly benefit from networks in the cloud -- if you and I work together but are also friends on Facebook, our connection is also stronger in the enterprise, and our coworkers should be able to find me through you and you through me.

But now we're talking about the enterprise, where the rules are different. Some information is sensitive, some relationships are only for certain people to know about. Who "shares" what with whom can be complex. And almost none of this, for now, will be shared with the networks in the cloud.

So here is what we need: give us a data and social bridge from the cloud to the enterprise, so users can self-select what to "share" inwards. Enterprise systems can leverage the information it deems reliable (as discussed by Mark Cuban), which can make the enterprise more fun and more effective. This bridge will have to address basic things like identity mapping, and let users connect their various consumer systems for general, unified access by either cloud applications or enterprise applications. Let the enterprise pull data in today, and at some point it will be comfortable to push data out.

APIs can be a nice start, but design them for the use cases that empower the participant. I decide what I share on Facebook (even though I can't figure out how to hide all of those annoying zombies) and that is why Facebook is powerful and popular. Build me a bridge between systems, and I'll probably cross it. If the bridge goes to the enterprise, some of the energy and playfulness will come along as well.

They're all good, Bill

Bill Roth just provocatively posted that maybe all tags aren't good. I came up with a brilliant response:

They're all good, Bill. Really, they are.

The main problem with the alternative, is, well, the alternative. The alternative to the "false positive" problem is the idea that there are good descriptors and bad descriptors. There just aren't.

Let's describe Bill. Maybe developer tools, eclipse, BEA, blogger, these would all be good tags. But what about stagehand, actor, marquette tribune, bucky badger? It would depend on who you're talking with. If you're talking to Bill's college buddies, maybe the latter tags would be a much easier way to find him.

If one person tags an object, it is a good way for that same person to find it again, and that is enough. To thrive in the enterprise, you need to leverage people's selfish tendencies -- give them a way to get their job done easier. Whatever tags they use for that occasion, someone, even if it is only them, will benefit.

Of course the real enterprise needs some precautions, such as tagging blacklists, reserved words, etc., and Pathways can do all of that.

But then what about all of that noise? Won't it make the "real" tags disappear? Nope. Once there are a bunch of tags in the system, if people view the top 50 or top 100 in their tag cloud, they will only see the often-used tags, and the important (judged by ActivityRank) tags. The only times the "long tail" tags will show up if the search is so targeted that they rise to the top. And I can always use Views to see how a specific set of people have tagged it. If I am interested in Developer Tools, I might want to see the world with Bill Roth's view. Or maybe my son's. He's only two and a half, but that new generation seems to have something to say, even if I don't always understand him. His friends do, and those tags might help him show them the way.

Okay, maybe that was a stretch. But we have definitely found that if we add information in this seemingly chaotic way, we can reduce the chaos. No tag is bad, Bill. Convinced?

Pages has left the building...

AquaLogic Pages is now Generally Available, folks. Go and
Get It!

The world of work has just gotten a little bit easier...

Architecting for Participation

I was scanning feeds on Rojo last night, and saw this post about Steven Bao, and the Facebook apps he has created. He is 14. He's a freshman in high school.

What languages does he know? Java? Nope. But he knows PHP and MySQL, plus JavaScript and the rest... and he's learning C++. And of course he has his own company. At that point in my life I was trying a new skateboard trick, unsuccessfully.

Then I read a note about MySpace versus Facebook on TechCrunch, reinforcing the obvious.

A hallmark of Web 2.0 is that it is participatory, and as we delve into the enterprise we need to pay careful attention to this, not just from a feature/function perspective, but from an architecture perspective. Poll the enterprise today, and Java and .NET will be strong, poll the people hired in the last two years, and the LAMP stack and browser-side programming will show a steep rise. And if freshmen in high school are tooling away in these languages, just think what the work force will be like 5 years from now. All purveyors of Web 2.0 technology in the enterprise should take notice.

And what should the APIs give access to? Everything. If you're afraid of people doing themselves harm with your APIs, then either you don't have respect for people, or you have a bad architecture. Here's an idea: document the interfaces, and let people invent. If you seek to control the applications people build with your platform, then you are almost extinct.

Some people reading this will think he doesn't get it -- the things that matter in the enterprise are security, robustness, things not available in these new architectures. To you I say that you don't get it, innovations will fill the void, and that is exactly what we are trying to do. Embrace the architectures of participation, because you don't want to build for the past. Building for the future means being open, giving a big-ol bear hug to the emergent stuff on the web, and doing the heavy lifting to find ways for it to meet the needs of the enterprise. Because people will find a way to get their jobs done... either with or without the technology that their company wishes they would use.

Using Web 2.0 in the Enterprise today...

On Wednesday at the OReillly's Web 2.0 Expo in San Francisco, I joined Ross Mayfield, Joe Schueller and Michael Lenz at a panel titled Web 2.0 for the Enterprise: What Corporations Really Want and Use.

It was an interesting discussion, reported on by InfoWorld and InternetNews, and the questions indicated how much companies are hungry for practical guidance on adopting these modern tools within workplaces that might be, well, resistant.

When we were discussing the propensity of people to purchase wiki software with their credit card to begin collaborating without corporate approval, it was widely hailed as positive. The question is, how do you strike a balance? Ross, of course, didn't mind the credit card purchases. Michael, on the other hand, said he wanted to encourage people to use new tools, but instead of charge their credit card, it would be better to put it towards a common pool so IT could fund the right solutions to the problem.

That seems to put us back where we started, doesn't it?

When we were discussing Ensemble with an IT executive recently, he was intrigued, saying that he loved it at the same time they hated it. He desperately needed to wrap his arms around all of the rogue web applications in his enterprise without changing the way his people worked, and he was thrilled that it could do just that. After all, the minute you try to control people, they will find another way using consumer tools. But he worried about the air of legitimacy Ensemble would give these tools. In other words, while he was very pro-wiki, there were other rogue efforts he was trying to constrain, and having Ensemble made it harder to argue against them. After all, they were safe now, weren't they?

I say let your employees do what makes them productive, just give yourself the tools to govern and manage it. In other words, don't prevent people from misbehaving, but make sure that they are accountable when they do misbehave. Because in general, people surprise us in positive ways, especially when we do what we can to make their jobs more fun, or at least... less frustrating.

Have will, find way

In a recent study by McKinsey it seems that Web 2.0 adoption is being thwarted by nervous executives who fear two things:

IT ceding control

Disruption of the "knowledge economy"

IT ceding control...

This thorough study found that 33% of executives invest in wikis, 32% invest in blogs, while just 21% invest in "mash-ups." First of all, those numbers are big. Secondly, often there is more deployed than management thinks: almost no executive knows which wikis are out there. When we did a research roadshow in 2005 we asked companies how many unmanaged web applications were in their enterprise. Typically, people said they had very few. Then, we went through category after category (including wikis) and found that the average company had around 100 unmanaged web apps.

The article notes:

Jacques Bughin: "The reason why blogs and wikis, in particular, aren't well used is that companies are still afraid," he posits. "How do you basically regulate how to contribute?" He also thinks the wisdom of crowds isn't always sharp and that companies are worried about getting bad information on a collaborative document, such as a wiki.

The basics of these problems have been solved in a lot of wiki platforms (import your users from LDAP, use security, etc.). The remainder of the control problems are solved by Ensemble. As for getting bad information out of a collaborative document, it all comes back to traceability. If you know who edited what, when, using a page version history as well as a component version history you can easily solve this problem (Pages).

Disruption of the "knowledge economy"...

The conceit here is that since people are valued for their knowledge, recording their knowledge in a wiki threatens their status, so they won't contribute. Solution: celebrate the contributers, and let the others leave the company. Successful organizations of the future will be transparent, the idea people will be celebrated, and the knowledge hoarders will simply have no place. The first step? Put together the right feedback mechanisms to determine who is really valuable (in terms of contributing knowledge) in your organization. Yes, maybe this is a plug for Pathways.

Widget insertion, oh yeah...

Tech Crunch posted an article today on Widget Publishing, noting "Getting a widget onto a website, whether its a blog or a MySpace page or anything else, is a bit of a pain." And the "pain" is having to copy a snippet of javascript onto your web page. The solution discussed is a way to email widgets around to make the process easier.

Okay, that might constitute pain on the web, but that is
Xanadu in the enterprise. In the enterprise, as we know, widget insertion generally requires cracking open an IDE.

The exciting thing is the explosion of activity for Web widgets. Widgets aren't new. Anyone who ever played with Microsoft's 1997 foray into Active Desktop will find this area familiar. But with this secondary explosion comes evolving standards, such as W3C's Widget working draft, as well as evolving technologies, such as ATOM and RSS.

Ensemble brings the web ease into the enterprise. Just as you copy and paste widgets into your blog, now you can do it into any enterprise web site, replete with security and governance.

Next year you will be able to consume everything in your enterprise as if it is RSS and GData, in a way that makes IT calm and encouraging. I just hope they don't start clogging my email...

Tag Clouds coming out of my ears...

So Pathways has another tag cloud, big deal. I have tag clouds all over the place, its a nice metaphor. I might be able to find an enterprise document quicker with an enterprise tag cloud, but it isn't that exciting... until, maybe, you constrain it.

The tag clouds you use on the web tend to be public. That makes sense since most of the web is public. But not the web in your enterprise.

Pathways takes a novel approach to the tag cloud in adding the concepts of context, security, and views. Context means that as you click on tags they are additive, and your tag cloud shifts as you drill deeper. Security means you can only see tags on documents you have access too. Both of these are cool (and make the engine driving the tag cloud pretty complicated), but I want to spend a moment on Views. Views are really cool.

A View allows you to see the tag cloud as applied by a certain group of users. In other words, it gives you a perspective from a group of people. This can be very powerful, since it can show me how Developers view material I'm interested in as opposed to Sales people (yes, different types of people...)

Let me take a case in point. I was just looking for some CSS styleguide stuff internally. It just so happens that my company has a ton of documentation on a Core Security Service, handily abbreviated CSS. So all this irrelevant (to me) stuff came back. I switched my view to the UI teams, and I quickly found the documents I wanted. (And then I found the people I wanted, through the Experts functionality... how circular!)

Your organization is filled with intelligence, we just haven't had the tools to expose it in simple ways. The first release will just be the beginning, but I'm looking forward to answering questions like... which product managers are most influential with sales? Which salespeople understand the products the best? Let them work and have your systems figure it out...

Pipes and Pages... nice!

Attending the Yahoo Pipes talk at ETech... very exciting with respect to Pages...

Just announced, Pipes will now support XML and JSON as feeds. Point, click, build a Pipe, and expose it as a DataSpace in Pages over RSS. I can't wait to get home and play!

Mashups in the Enterprise, egads...

The term Mashup, a term that already feels stale, is being attached to all sorts of things these days. Whether it is real estate information overlayed on a map, or mobile-phone-uploaded videos illuminating a traditional-media news story, they can be fun to use and they can actually make our lives easier. Which is great. So let's rush them to the enterprise, where everything seems so hard to accomplish. Let's free the knowledge workers from the manacles of legacy systems and torrents of email. Let's let people think and act instead of wasting time finding stuff.

Imagine, for example, that your own life could be easier. I, for example, have found myself in one or two bug triage meetings. It is a necessary part of creating software. And it is painful. When we're talking about a bug, we want to know which customers it affects, and so we pull up customer incident numbers. And then we look at another system to see who those customers are, how many incidents they have, etc. And then we look at another system to see how large the customer is, how far away they are from deployment, etc. (Oh wait: did I just admit that we don't fix every bug?) Why don't we just build an application to pull all of this together in the traditional way? Well, its hard, and I'm not going to skip watching all those great sitcoms to write it.

But maybe it would be easier to think of it as a mashup. Maybe if we started writing UI components that could be mashed-up we'd learn something about how to do this in the enterprise. And then I remember: we're launching a set of new products this year to help solve problems like this, and has some great products out already that can help, so maybe those could be of some use. More about that later.

First, let's think about how the mashup problem shifts when you move from the consumer world to the enterprise:

Security and Identity

Most of the internet is public, so you can mashup that public stuff pretty easily, since anyone is allowed to see anything. Take some public tax records and some public maps and you have a nice application. But all of the juicy (read: really useful) data in the enterprise is only available to a select group of people, which usually does not include you.

So you need a way to know who is who when they're using the mashups, and the mashup needs to forward that identity on to the widget-producers that serve up the bits that are being mashed up. In other words, identity matters and needs to be preserved throughout the data lifecycle and preserved in the mashup.

That sounds hard.

Enterprise-readiness of the bits

There are little web apps sitting everywhere in your company written by contractors and interns and internal developers or downloaded from the web. There's probably a good bit of Java and .NET, and I'll bet you a dollar that there is some PHP or Cold Fusion or Perl, and a bunch of other stuff lurking somewhere as well.

If you want to turn one of these applications into a widget-producer (I'll start calling these mashup-ready-widgets pagelets, which I'll define in a minute), what do you need to think about?

Pagelet: a snippet of UI, much like a portlet, that can live happily on any page in the world, look nice in that page, and interact with other pagelets on that page.

First of all, what if the pagelet producer goes down? I hope that doesn't wreck my mashup. Once I expose it to a mashup, how much traffic can it handle? Oh man, I don't have any way of tracking that. Maybe I should only expose it to a limited group of people using the mashup until I know it is stable. I got so excited about exposing my Ruby app to a larger audience I forget to get worried about exposing it with a broader audience in mind.

IT governance (Including regulations and all of that stuff)

That brings us to IT governance. Which is boring, so we'll keep it brief. IT will love mashups because they will reduce IT workload. IT will hate mashups because they are ungoverned. Aren't they? They don't have to be, provided the following is true:

• IT can control who has access to the mashup
• IT knows there is DMZ-quality security for brokering the mashup to the web
• IT gets usage data on how the mashup is used
• if part of the mashup goes down, the mashup stays up
• roles and policies can be managed in a central way, which the mashup respects

Budgets

Last point, I promise.

No one makes tons of money on add dollars in the enterprise, so there are fewer gaggles of torn-jean, designer-hair developers hacking together the next coolest thing. The budgeting cycle is annual, everything costs a million dollars, takes a year to build, is soon irrelevant. How do we change that?

Well, we need an approach that IT trusts, so they will cede control, but the governance stuff should help with that. Then we need it to be cheap to develop, and easy to change. If things are easy to try, and people are given the right tools, and it will make their life better, they will try. Let's call this the Selfish Principle. If I have to convince IT to build my Bug Triage Mashup, I will fail. But if the person that benefits (me) can build it (or convince my office-mate to skip a night of WOW to build it), and it will make their meetings shorter in the long run, I might pull it off. We need to empower the Selfish Principle, and the rest will take care of itself. Budgets won't matter, since budgets don't govern the "million smalls" of the long tail. You can I can each do a little bit of work to make our own lives better, and everyone will benefit.

Okay, enough drivel. This is a place to learn about a new product to make mashups in the enterprise not only possible but useful. I think its going to be a lot of fun, so stay tuned...