Enterprise 2.0's New Debate: Dam the Streams?

The reason is that in a previous era, access control was primarily a zero-sum function, with need-to-know as the operating principle. Dams were built primarily to manage and allocate information supply.

Today, it's also a wealth-generation function: think hydroelectric power, rainwater harvesting, watershed management, and smart agriculture. The stream does more than move value around. It creates value, and a yield management problem.

Yield management is a new design problem to be solved by access-control architectures.

The social business IT system, when it works, naturally generates a huge flood of structured and unstructured data: photographs of birthday parties, employee blog posts containing insights, viral slide decks, Yammer conversation streams, comments on big all-hands meetings.

There is no way a few IT "professionals" can mine all the value out of this flood. The job needs to be crowdsourced. This means access control architecture has to comprehend both need-to-know principles and intelligence harvesting principles.

The latter requires a mindset shift because it's a probabilistic function. When you share (say) a tricky production line problem on a company-wide discussion forum, you don't know a priori where the solution will come from. You're leveraging Linus' Law: With enough eyeballs, all bugs are shallow. By contrast, need-to-know is a much more deterministic principle, based on nominal job descriptions.

Traditional IT management has simply never had to perform this function: getting the right (large) set of eyeballs looking at the right data in a big stream. IT departments everywhere are comfortable with risk management roles. They're not comfortable with yield management roles.

How many CIOs do you think would be comfortable with the charter of delivering at least $3 million worth of "assists" to sales via lead discovery in the stream?

This is where the coupling between the boundary-drawing and dam-building components comes in. By defining boundaries appropriately, and controlling access with respect to the new boundaries, you get both risk management and yield management.

Take the two examples I used before.

An expanded Inbound Market Intelligence department can periodically create and share reports that go well beyond traditional post-sales metrics like "cost per call" and "mean service hours." Instead, the reports can now capture insights that can make their way to sales, marketing, and engineering, with appropriate accounting of value flows.

Similarly, a restructured HR function, with separate good cop and bad cop parts, would get rid of the schizophrenia inherent in today's HR models. Having the same organization trying to deal with soft-touch roles like attracting talent and maintaining motivation on the one hand, and hard-touch roles like managing compensation structures and sexual harassment lawsuits on the other, creates huge internal cultural tensions (usually soft yields to hard).

Reorganizing around natural good cop/bad cop fault lines revealed by the course of the enterprise stream removes the schizophrenia.

From Static Flows To Ad Hoc Flows

The basic geographic stream metaphor takes us only so far. The real potential of stream-based enterprise IT will emerge when we move beyond static flow control models to dynamic ones.

Unlike a river system, where dams and canals are expensive and static control mechanisms, the digital stream can be dynamically managed with very cheap, ad hoc flow architectures.

It won't happen today or tomorrow, but it will happen: The organization chart will be replaced by boundaries that morph continuously. The stream will be rerouted on the fly to meet new challenges or pursue new opportunities. Instead of new departments, we might see the equivalent of business flash mobs, miraculously generated by an adaptive and agile IT infrastructure, to swarm and solve a particular problem just in time.

But that's far ahead in the future. I'll discuss that sort of management science fiction some other day.

Putting it Together

So what we're talking about here is the emergence of a whole new IT sub-discipline, the equivalent of hydrological engineering.

Can CIOs and IT departments everywhere step up to this challenge? What will they need to learn to perform the new functions successfully? Who will need to be hired? Who will need to be fired?

All good questions. You should be asking them.