Convergence with the 1.0 World

As we move along in our journey, I'm pleased to share with you the harder questions we have to wrestle with, how we're making our decisions, and how it all turns out -- for better or worse.

No one has written the definitive book on this stuff (yet!), so we all should feel free to use our best collective judgment in deciding to go one way or another. 

And now, we're getting to a very interesting discussion on this whole "2.0 vs. 1.0" thing.

I don't have any answers yet, but it's turning out to be interesting, to say the least.

Our Story So Far

So, to recap our story so far, we built our internal social computing platform over a year ago (EMC|ONE), and it's cruising along.  More to do there, but all goodness.

About 4 months ago, we formed a group to accelerate the formation of external communities, but maintain a certain loose coherence to things.  That's coming along very nicely as well, all things considered.

Outside of GE and a few others, EMC is probably on a short list of companies that's really putting this social stuff to work in a meaningful and business-transforming way.  It's being done with intent and focus, which is a nice way to do things.

We now have two related pillars to our 2.0 strategy -- internal and external.  Both are important.  Both are related.  But they're run by completely different teams, using completely different methodologies, requiring completely different skills, and on distinctly different platforms (albeit with common technology, e.g. Clearspace).

Why?  They're solving very different problems.  Based on what we now know, there'd be no way in hell that I'd ever foolishly attempt to solve the internal and external 2.0 thing using a common team, common platform, common methodoligies, etc. 

Some may look at that and say "well, that's inefficent, there's got to be some redundancy there that you haven't taken out yet".  Spoken like a true engineer.  But, I would counter, look where we are and how fast we got there, and how well it's all working.

Why would I risk all of that in some foolhardy effort to squeeze another 10% out of the equation?

Remember that specific thought in a few paragraphs.

Here Comes The 1.0 World

So, like most companies, we have our own uber-repository that supports all sorts of business functions: sales people, support people, partners, employees, etc.  Ours is called Powerlink.

Like most companies, we spend a lot of corporate money on this platform.  Like most similar platforms, it ends up serving everyone, and generally pleasing almost no one.

And, in the big scheme of things, it's time to go re-invent (again) what this corporate content portal is all about.  That's good -- the timing is right, and we're much smarter about this sort of thing than we used to be.

Not surprisingly, the team is wrestling with two very important and very strategic challenges that are interrelated.  And I thought you'd like to understand what they are, because you may be at this exact same place in your journey before too long.

The Architectural Challenge

I don't know what it is about how most people think about these things, but the natural tendency seems to be to do what you essentially did before (architecturally speaking, that is), but somehow just "fix" what you got wrong the last time.

Maybe it's my background, but -- at least for me -- architecture drives just about everything else. 

Want a different outcome?  Think about a different architecture.

Imagine you don't like the house you live in: the kitchen's too small, the ceilings are too low, there aren't enough bedrooms, there's no real place for the kids to play, etc. 

Some people embark on extended renovation projects to "improve" what's basically an inadequate architectural design.  Others are smarter about the problem and go looking for a house that's architected around their needs.

This simple human behavior from the real world seems to have difficulty translating into the software world, or so I'm finding.  I guess the word "architecture" scares people off -- it's nothing more than a set of design principles and segmentation of function.

So, not surprisingly, most people associated with this "new 1.0 efforts" are thinking about improving the house they're already living in, rather than what they might want in a new house.

This will lead us inevitably to some sort of massive uber-database, with some massive uber-portal user interface, and all sorts of uber-process to get things into, and out of, this 1.0 repository.

I am one of the lone voices in the wilderness, it seems.

A Suggested Architecture?

I see this as potentially being a simple, but elegant architecture.

Here are all the places where content comes from.  They are owned by different parts of the business, which control what goes in, and what comes out.  These parts of the business are responsible for labelling the content they want to share, so we know who can see what, and what it might need.

More and more of these content sources are becoming external, right?  Think filtered RSS feeds with attention management.  "Google Alerts" is my most recent favorite ...

Most importantly, the content repositories are NOT part of this project scope.  They exist, and must be interacted with, but they are not "owned" by the project team.

Consider, just for a moment, the impact of the above statements above in a large, complex organization.  Imagine trying to dictate a single place where all useful content lived, or a single process for getting things in and out, or defined taxonomies, etc. 

Come to think of it, that's what we tried the last time, and we're certainly not happy with the results :-)

Above that layer, there's a metadata layer that normalizes and abstracts the content sources below it.  Differences in labelling and semantics are captured here.  You don't need to know where the information might live to use it.  Of course, there's search, collections, filtering, tags, etc.  There's a static view (here's what I have) and an RSS view (here's what's new).

Over on the right hand side, there's an authentication engine.  It can support multiple concurrent authentication and access models, understands the concepts of inheretance, can deal with ambiguity, etc. etc.  Most importantly, it's a service -- when it's time to determine whether someone can see something or not, it's asked for its opinion. 

Specifically, it is not embedded in other layers.

Going up the stack, there's a corporate mash-up layer.  Here's where we construct composite views of what pre-defined personas and roles should see.  There's a lightweight workflow engine to suggest changes to what's being seen, review, approve and publish.

If I was being fancy, here's where I would put the analytic capture and analysis components -- who's looking at what, and so on.

At the top, there's the user presentation layer.  It works on desktops, and it works on smartphones with sufficient browser resolution.  Not everyone will want to customize the appearance, but you can if you want to.  Eventually, user mashups will become more popular, and people will want to publish and share "their" views.

Finally, since I care greatly about such things, there's a service delivery layer.  The more complex the environment, the more important it is to have an end-to-end view of end-user performance experience.  And, yes, I see this an integral piece of the architecture, just like authentication management. 

It doesn't "just happen".

Now, I'm too lazy to draw this up on a powerpoint, but I hope this verbal description gave you an 80% view of what a next-gen 1.0 uber-portal / uber-repository architecture might look like.

Now, Let's Layer In The Previous 2.0 Discussion, Shall We?

I mentioned previously that we had two "2.0" pillars up and running already: internal and external.

And, creating great agita for me, is the thought that we combine all of this "2.0" stuff into a single uber-platform that does it all.  I wince over and over again as I think of different reasons why this would be a Really Bad Thing To Even Foolishly Attempt. 

At the same time, I know how people tend to think.  And I also have had plenty of demonstrations of how large companies sometimes get into really bad situations simply because it was the "consensus view" at the time. 

So I'm taking this line of thinking very seriously, indeed.

Now, let's consider the 1.0 architecture I described above.  If you think about it, pretty easy to layer in the 2.0 content and interactions, no?

Given The Above Architecture, It Works Both Ways

I am either very deluded or very excited that a variant of the above architecture works both ways.

From a 1.0 perspective, social content becomes just another content type.  It's searchable as to what's already there, and what's new in terms of RSS feeds.  It's mashable at either the corporate level or the user level.  A common authentication mechanism ensures that there's a consistent way to deal with people, rights and access. 

Really interested in the discussion you're seeing?  Click here, you're in, we know who you are!

From a 2.0 perspective, this works as well.  All 1.0 content is exposable and mashable as part of the social and/or community experience.  You have extended content search capabilities as well, not usually found in the typical 2.0 environment. 

What Are The Big Ideas Here?

First, uber-thinking (from an architectural view) is extremely dangerous stuff.  The corporate application world learned years ago to decouple functionality, and build things in architectual layers and pieces. 

I'd hate to learn that lesson all over again in the "1.0 meets 2.0" domain.

Second, there is no "right experience".  Just as there is no "right taxonomy", "right tag cloud" and so on.  It's all based on what the user wants to see, and when they want to see it. 

And users have this way of changing their preferences, so you better be dynamic.

Third, not to oversimplify, there are probably a couple of "poles" we can think about.  There are users that are looking for content, but wouldn't mind being exposed to relevant discussions (a content-centric experience).  And there are users looking for discussions that wouldn't mind being exposed to relevant content (a conversational-centric experience).

Fine, create a presentation / composition / mashup layer that can do both, ok?  Even if you have to use different tools to do it.

Fourth, let's not think in terms of Really Massive IT Projects.  I, for one, would be happy with a small team that prototypes a few architectural concepts, tries them out with a few target users, and learns from the experience, rather than a typical waterfall IT project approach.

Because if we do take a traditional path, I think it's going to be really, really ugly.

Comments

[gminks]

Chuck, did you ever see the Innovation Conference entry I had about creating a PLE (Personal Learning Environmen)? It's basically a framework for what you are describing. :)

[Chuck Hollis]

No, I didn't see it, but I should -- can you send me a link?

I think there are a lot of us that are envisioning this next gen environment in many of the same ways.

Now all we need to do is garner the will and the vision to build it!