Infovark

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.

Sam Lawrence has a new post up about how social software could dethrone the big guys. Sam references the photographic industry, and how the big guys at Kodak ended up being a niche player in the new global digital photography age.

Like Kodak a decade ago, today’s enterprise software giants have a lot of legacy to overcome if they want to join the social software revolution. They’ll find it difficult to integrate emergent systems with the rules engines that drive their enterprise platforms. In many ways, those two approaches are polar opposites.

Of course, the big players have a lot of resources and talent at their disposal. (As two guys in a basement, we’re acutely aware of that!) But do they also have the vision and the will to reinvent themselves?

This week we began showing off what we’ve built to a select few folks, mainly former coworkers of ours. All of them were polite enough to say that the idea was very interesting and that we were very brave.

Frankly, we’re just glad that nobody laughed.

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 .