Our graphic contrasting explicit software versus emergent software attracted quite a bit of interest. Since we got your attention, I thought I’d talk about the contrast between process-centric versus outcome-oriented software a little more.

It seems to me that there are two kinds of thinking taking place in most work environments: process thinking and outcome thinking. People who subscribe to the process model tend to favor rules. They care about establishing and following effective, repeatable methods for conducting work activities. They feel that if you structure the work properly, you’ll get consistent, high quality results. There’s good evidence they’re right. After all, process-centric approaches have revolutionized manufacturing and logistics.

People who tend toward outcome thinking feel that results should speak for themselves. (Sausage is tasty, but you wouldn’t want to see it made.) They care about speed, flexibility and responsiveness. There’s good arguments to be made that a results-oriented approach can improve customer service dramatically. Nordstrom’s famously asks its sales associates to follow just one rule: “Use your good judgment in all situations.” Most of the entertainment industry subscribes to an outcome approach.

Worldviews Collide

In most industries, both attitudes are present.

As an example, a long time ago, I worked as a junior clerk for the Australian Defence Force. I was given the important task of faxing purchase orders to various companies at the end of every day. One Friday, while faxing orders out, I noticed that one of them was wrong – by a significant amount. So, I went to my computer, and printed a new order, this time with the correct amount. But, it was late in the afternoon, and there was nobody around with the purchasing authority to sign off on the revised, correct order. In fact, there was nearly nobody around at all.

I knew I wasn’t allowed to sign a purchase order. But, being an outcome based guy, I decided not to let that stop me. I simply cut out my boss’s signature from the previous incorrect order, glued it into the “Authorized by” space, and faxed it off. After all, it was a fax, right? Nobody at the other end would know the difference. The outcome was achieved, and I went home feeling quite proud of myself.

Needless to say, when I got back to work the next day, and told my boss what had happened, I was in a lot of trouble. There was a lot of stern talking to me about things like “Standard Operating Procedures” and “Protocol”, and “Fraud”, and things like that. It turned out that my outcome based approach to solving the problem wasn’t very popular with senior management. I couldn’t understand why they were so upset. I had saved the department lots of money and time, and yet they were mad at me. They wanted me to follow the process.

The Social Software Shift

Process based thinking is where Enterprise Software of old was born, and where it grew up. Computers can be taught to follow a process — it’s something that they do very well. Today’s workflow solutions, for example, mostly take their cues from assembly line automation.

You can’t automate social interaction, however. (Though Miss Manners has tried.) There are no blueprints for innovation, and “creative process” is something of an oxymoron. Social software is outcome focused. It empowers and connects people with the ability to get things done — however they like.

People are innately familiar with both of these ways of working. However, until now, Information workers have been largely bound to formal processes. The groundswell towards social software in the enterprise stems from the realization that computing devices (PCs, PDAs, Cell Phones) are as much communications devices as they are calculating machines.

Continue Reading

Dion Hinchcliffe has a really important post about the impending maturity of the Enterprise 2.0 market, in the wake of Forrester’s prediction that the Enterprise 2.0 space will be a $4.6 billion industry within 5 years.

He contends that a hallmark of the new enterprise solutions is that they are emergent — that they aren’t handed down from on high through the traditional IT/management channels — that instead they are introduced by people in an effort to solve their problems.

“In other words, we seem to be coming from a push-based era of command-and-control management and are heading into an era where more and more work is being conducted using a decentralized pull-based model that’s more scalable, efficient, and leads to increasingly innovative outcomes.”

We’ve spoken about this at length before, because we see emergence as a crucial property for any system that’s going to be able to deal with the kinds of unpredictable situations that occur for modern knowledge workers.

Dennis Howlett, also over at ZDNet calls Forrester out on their Enterprise 2.0 definition:

A set of technologies and applications that enable efficient interaction among people, content, and data in support of collectively fostering new businesses, technology offerings, and social structures.

Forrester’s definition is indeed pretty vague. But then, no analyst is ever going to be precise. (Vagueness means never having to admit you were wrong.)

Dennis also suggests that Forrester have missed a key part of the problem. Forrester expects the major vendors to roll up all of these new “2.0″ features into their collaboration offerings. By doing so, Dennis feels that Forrester greatly inflates the size of the E2.0 market. He’s right; the true E2.0 market is much smaller, and the big enterprise vendors just don’t understand it.

The major vendors sell to CIOs and IT departments through traditional channels. They aim at the top of the corporate pyramid. Their systems enforce repeatable processes and follow established metrics. Their value is derived from imposing order on chaos.

Emergent systems, on the other hand, thrive on chaos. They address the “Barely Repeatable Processes” that happen within organizations. Emergent systems are decentralized, self-organizing and organic — the antithesis of the top-down, rules-based engineering approach taken by most enterprise software. To build an emergent system — an ecosystem — you target the bottom of the pyramid, building it up one user, one connected node, at a time. The value of an emergent system is derived from its flexibility, adaptability, and responsiveness.

Emergence isn’t another feature to add to the enterprise technology stack. Emergence isn’t a feature at all — it’s an approach to solving a problem .

Continue Reading

When I was starting out as a Software Project Manager, A Zen Master taught me something that I never forgot. It happened when I was complaining about the lack of process behind the development team that I had just inherited.

I was younger then, and was frantically trying to introduce more structure to the way that my team shipped software. I could see a lot of the reasons for the product delays and the quality assurance failures. I just wanted to help. I had policy documents, and process plans, and Gant Charts. Lots of Gant Charts. But every effort I made to modify the process was met with stony resistance. In conversation, people could see that I was making sense. They would agree that yes, things were broken, and they probably shouldn’t be.

And yet I couldn’t get them to change anything. That was when the Zen Master appeared:

Me: “Grrrr! These guys are just making it up as they go! Everybody is just sitting around waiting for the developers to be finished. No wonder everything is so crappy and full of bugs. There is no structure or process here! ”

Zen Master: “You are wrong. There is structure.”

Me: “???”

Zen Master: “Structure comes in two states: implicit or explicit. You are complaining because there is no defined structure. Particularly no structure that has been defined by you.”

As is so often the case in fantasy Zen Stories, the master was right!

There was plenty of structure to the way people worked. It had grown organically based on the way that people wanted to work. It was hard to describe, and it was optimized more for individual happiness than for productivity, but it was there.

It dawned on me then that the best way to effect change was to embrace the practices that were implicit.

This kind of thinking led to Agile Practices. It led to Extreme Programming.

And it is the central premise behind Enterprise 2.0 or Social Productivity software. Harnessing the implicit structure of an organization can be the best way to improve it. People are innately social. They like to talk. They like to discuss things. They like to achieve things. They like to share. They like to boast.

It turns out the easiest way to get things done is to optimize the way people innately tend to do them.

Incidentally, If your PM is complaining about a lack of processes, it means that she can’t effectively bring about the cultural change that is required. You should either give her more authority, or hire a new PM. Or you could see if you can rustle up a Zen master to change her mind.

Continue Reading

Laurence Hart over at Word of Pie calls us out on our approach to content management . Dean and I are both big fans of his blog, so we were pretty stoked to see a whole post about us.

Laurence raises a lot of valid concerns, all of which we’ve spent loads of time mulling over, and I’ll get to those in a second.

But first, to really understand our solution, you need to know how we got here. Dean and I absolutely understand where Pie is coming from. We have a long history of working in the ECM space with TOWER Software. We’ve read through countless customer requirement lists about compliance, Sarbanes-Oxley, retention, discovery and authoritative versioning. We’ve spent hours designing taxonomies, file plans, and security and access policies. We’ve drafted tender responses, and drawn large Visio diagrams. We’ve written integrations to nearly all the of ECM products in the market today.

After all this effort, once an organization deployed our tailored solution, we’d observe the same pattern. The content management software met the business needs, but it didn’t help the end users. Instead, It got in their way. It often made it harder to find things, and it made them work to understand things that they weren’t specialists in — like taxonomies and retention. User acceptance and training overheads were huge. We had to work like crazy to get people to use our carefully crafted solutions.

OK, you might say — that’s fine. Work isn’t supposed to be fun. You just do what you’re instructed to do. As long as the enterprise as a whole benefits from the solution, the content management program is doing its job.

Except that the enterprises weren’t really benefiting. The push-back from the user community meant that people wouldn’t actively use the solutions to do their daily work. Large, corporate, and eminently scalable repositories all over the world are filling up with dusty, useless content, most of which is almost certainly never going to be seen again. Traditional content management is extremely effective at preserving things. It’s terrible at solving the kinds of tactical problems that people deal with every day. Sure, retention was up. But productivity was down.

(Pie knows this. That’s why he talks so much about invisible, or transparent ECM . Because yes, preserving things is important, but knowledge workers don’t care.)

So, when we started Infovark, we set out explicitly to solve the other problem. The people problem. The fact that people couldn’t connect and share with each other. We decided to build an enterprise product that people would want to use, first and foremost. The capture and retention come second. The point of a transaction is not to get the paper receipt.

OK, that’s where we came from. Now to answer some of Pie’s more technical questions:

• How do you manage the disk usage? Peer-to-Peer is concerning. I’ve used Groove and it can be a disk hog. You would need a fair subscription model to manage the whole thing.

Groove is a disk hog. Transferring files from a peer through a peer is not what we do. For one thing, Groove places content on your machine that’s merely “passing through”, i.e. unrelated to your work. This can be something of a security nightmare. How do you keep that information secure? For another, Groove is about pushing updates out to subscribers. Infovark works like RSS; we pull updates. And we only pull data relevant to you and to which you have access. The network usage is about the same as if I email a document from my computer to yours.

• Are the wiki pages also stored peer to peer?

The Wiki pages are indeed stored locally and accessed remotely.

• What do you do about items once completed and needed to be kept?

As of right now, we don’t do anything! One of the great things about the REST-based approach that Infovark takes is that that content is accessible and available to the whole enterprise. Any content-spidering search product, like the Google search appliance, can easily scoop up the latest version and index it. Periodic backup or archiving would work in the same way. Use your favorite off-the-shelf tools. We’re also planning some specialized versions of Infovark that can address all three needs in the same package.

• Items are listed on a user’s Wiki. Where does it get listed when a user leaves the company?

That’s up to the IT guys. The user’s Infovark could easily be picked up and hosted on a server. Then all you’d need to do is change a DNS entry or leave behind a permanent redirect. It’s kind of like an “Employee Graveyard”. Creepy…

• How do you track/prevent cross edits? Johnny starts to edit something and then I decide to make some edits as well. How is that managed?

Gah! Stop asking hard questions. We’re working on that right now. We’ll get back to you when we get to Alpha in June.

Continue Reading

April Fools Day has come and gone, and the Internet has largely returned to normal.

Yeah, the gags are pretty annoying. But they’re also kind of fun, right?

Yesterday’s antics led Dean to point out that April Fools Day would freak out the semantic web and emerging services based on it, like Calais and Twine.

As an example, out of no other reason than pure mischief, I mailed some of my friends a link to a video which I claimed was a leaked internal video analysis of HP’s recent acquisition of our former employer, TOWER Software. In my email, I harped on at length about some completely made up rubbish about strategy and future direction. Of course, the accompanying link was, in fact, to this video.

I know, I’m terribly original and downright hilarious, but back to the point:

Without the April Fool’s Day context, a careful semantic analysis of my emailed rickroll might permanently associate HP, TOWER Software, Strategy and Bad 80′s pop music. Or it might indicate that I was related to HP in some way (which I’m not). Regardless of how effective or capable any semantic engine is, any meaning that could possibly be extracted from my joke would be largely false, with the possible exception of the close — but now perhaps a bit strained — relationships between me and my friends.

No amount of metadata, microformats or markup can save the computers from human exaggeration, humor, or outright lies. And we humans have institutionalized a day where that’s all we do.

Continue Reading