Meme-check - Enterprise & Web 2.0

Gartner has now officially anointed Web 2.0 a bona fide IT trend.  BFD. Of course, they straddled the meme, by putting it at the peak of their 'hype cycle' graph.  That is the consultant's version of plausible deniability.  If it turns out to be real, they called it.  If it is not, they still called it.  This idea has picked up a lot of steam since I first noticed it  ten months ago.  Dion Hinchcliffe and Andrew McAfee are the real thought leaders, emphasizing the technologies and social/managerial impacts respectively.  Dion Hinchcliffe does his usual masterful job of deconstructing some of the elements of this Gartner-validated wave.

Before we all jump on this bandwagon, let's exercise some intellectual restraint and rigor, and in the process perhaps abandon the use of 2.0 as a synonym for "new". The original moniker of Web 2.0 has been used to imply/describe/justify/motivate a collection of concepts that range from standards (like RSS) to technical methodologies (like AJAX) to social phenomena (like personal publishing, rating, and sharing).  Web 2.0 has been as much about sociology as technology. But Enterprises are not just big "collections of consumers" and so let's not graft the same concepts and expect a thousand enterprise flowers to bloom.

First, dispense with the sociology. Enterprises have two core attributes that do not exist as widely in the public web -- purpose and accountability.   So 'empowerment' and 'collective intelligence'  are not end points.  Nor are 'discovery,' 'networking,' nor 'sharing.'   These are embedded in processes and are methods for creating context to purposeful transactions.  A sales forecast is 'collective intelligence.'  Mining customer comments is a form of 'discovery.'  A internal blog post is more likely to be linked to a product release status than photos of my vacation. Viewed in this context, a lot of what passes for (aspiring) businesses in Web 2.0 are simply features of larger processes in the Enterprise. 

So Enterprise 2.0 as a platform shift is mostly about the enabling technologies.  Web 2.0 rode the back of Open Source and Moore's Law to crack the economic barrier in building web based services. What followed were technologies for making applications richer (AJAX), easier to build (Ruby on Rails), and easier to integrate (REST and RSS). 

But only a tiny community of developers have built Web 2.0 apps using AJAX, ROR, or LAMP.  It is really just a few thousand people -- and very few work in large enterprises or ever will, again.   So how will the Enterprise 2.0 apps get built?  I doubt it is from a startup like Jotspot who has no business process expertise nor business data management expertise.  I doubt it is Oracle or SAP who pride themselves on selling Sherman Tanks as radiation-hardened compact cars. The users will build Enterprise 2.0 apps, not the vendors. 

The question is who will "get it" first?

• Will the enterprise application guys (the IT dinosaurs) "get it" about embedding communication and social context in long-running transactions, or
• Will the web 2.0 guys (the IT plankton) "get it" about business processes being the purpose of enterprise community and communication?

Tough call.

Maybe there's a third choice.  Maybe the users will be able to imbue business processes with social computing features. 

The growing consensus is that web-oriented architectures in the form of "mashups" will be the first wave of Web 2.0 in the enterprise.  Maybe, but I think these are going to be niche tools, not mainstream.  Why? Because today's mashups are data mashups and once you have the data, you rarely need it again.  As a test, think about how often you got back to a cool mashup you've seen to re-use it over again. 

This is the promise of process mashups - user-driven, maybe even user-authored, collaborative applications that support core business processes.  Data mashups are the New EII.  Process mashups are the new EAI.  (To be meme-compliant you may want to call them EII 2.0 and EAI 2.0. I don't.)

We are ripe for an breakthrough as big as Visicalc.  The spreadsheet exposed the power of the microprocessor to millions of PC users.  It was and remains the only significant programming tool used by millions of people who know nothing of linting, compiling, scripting, or even looping.   It provides a simple method of assembling data sources to create a custom "application".  The application is really part of a business process, most often a financial process.  A spreadsheet for business processes would be a powerful way to unlock collaboration and process knowledge in Enterprise 2.0.

Comments

[Nick Carr]

Illuminating post. Do you have a concrete example or two of what a "process mashup" would look like? Thanks.

[David Tebbutt]

This blog shows how mashups can be applied in organisations. Talis is a library-centric software company but it has shown the potential value of web services and mashups and, it has to be said, the opening up of previously proprietary databases.

I wrote about one of their mashups here: http://blog.iwr.co.uk/2006/07/get_at_those_ho.html

Talis is at http://www.talis.com

Forget the fact it's library work, they're doing good, pragmatic leading edge, corporate Web 2.0 stuff.

I'm a journalist. I have nothing to do with the organisation other than occasionally interviewing people there for blogs and articles.

[Ross Mayfield]

A breakthrough as big as wikiCalc? ;-)

[Paul Cox]

FWIW, I have been writing about oil and gas systems development in the enterprise 2.0 environment.

[Peter Rip]

Nick:

A process mashup is the assembly of N applications to execute a business process, not just share data. For example, a Major Account Visit app might mash together a set of calendars, a wiki, CRM information, and mobile phones. A field sales person could use that web app to arrange a customer visit (with all the key people/topics) and have that customer's sales history available to all the key members, along with availability, topics/owners, etc. That's a fairly simple user-generated process today that is executed with emails, meetings, phone calls, and reports. The "process" is the execution logic that ensures the goal is met -- a group meeting, ontime, complete, informed and with follow-up.

There are hundreds of such microprocesses that usually cross boundaries (geo, org) and where the a process is executed in collaborative, on-the-fly style to execute a goal.

BTW, this is not limited to businesses. Think about the challenge of arranging a wedding or planning a vacation. There are goals, constraints, and resources. Thus there is process. The applications (expedia, wedding registries, Opentable, etc.) are all just data. The first trace evidence of process is an email. Where there is dependency, there is process.

[Megan Cunningham]

Great post, but per your comment/example, how is a process mashup different from an integrated suite of applications? The reason most enterprise software is custom-built is because the processes they are designed to achieve are so closely tied with the enterprise's competitive advantage, and --rightly or wrongly-- the CIO's at the enterprise tend to feel that the "custom" nature of their apps is key to their organization's operational superiority. Especially true in client-service/front office apps, like traders at an investment bank. The multi-million $ custom apps they develop would not be possible to develop in the way you describe here, if only for the political/beaurocratic barriers the mere proposal of such an idea would face. So (as someone who works with both IT dinosaurs and IT plankton,) I would argue that regardless of what is technically *possible* the process mashup is not a likely candidate for enterprise software. On the otherhand, the SMB market --where many Web 2.0 apps have gotten some real traction-- are a better target for the growth of process mashup.

And, of course this is my bias, but have you thought about *why* the spreadsheet, as you say the "remains the only significant programming tool used by millions of people who know nothing of linting, compiling, scripting, or even looping..." The answer is in your next sentence: UI simplicity. With this in mind, for my money, companies like 37signals and Upstartle will inherit the earth.

[Peter Rip]

Megan:

It wasn't just the UI simplicity. It was the power of mutability hidden in a great metaphor. A simple UI isn't sufficient. The notepad app in Windows or MacOS is a simple UI. It is the ability to combine an intuitive representation with the flexibility of user-driven assembly. The same is true (kinda) for Tivo. It is "programming" your VCR to execute logic unique to YOU (recommendation engine, season passes, etc.) The execution sequence is unique to your needs.

The example I cited *isn't* different from a custom app. It IS a custom app. But its sequencing is custom to what that user (the field sales guy) wants to execute within the bank of apps that are available throughout the organization. He doesn't have to wait for IT to decide this app is critical enough for spec out and build. He 'mashes' it himself.

That's why I said process mashups are the new EAI. (Good luck on your conversations, BTW)

PR

[Megan Cunningham]

Touché: excellent distinctions. But I think you give much more credit to the average enterprise end-user than I do.

From where I sit, TIVO took off because the compelling value proposition (of both time-shifting entertainment and overriding commercials) was so great that even television viewers in their 60's took the time and effort to harrass the Best Buy salesperson to teach them to use it. Assuming your everyday average end-user of a business process can somehow be educated on the details of customizing (a big assumption, even with "intuitive representation" given the state of computer science education in America), there's still the cultural hurdle: you really have to dangle a major carrot --like VOD-- to drive them to participate. How many of these thousands of processes you cite are so transparently improved by technology that the act of improving them will be widely embraced by end-users? To use your original example, how many daily end-users of excel have taken the time to memorize formula shortcuts, much less become true power-users?

"Improving execution logic" is not something most *enterprise* end-users of software I know with would readily skip a lunch hour to learn, much less contribute to the larger enterprise goal. Unless the end-result is defined in terms that are in alignment with a sizable self-interest (greater flex time? larger bonuses? There you might have a winner-). Still, I have more faith in the plankton and the dinosaurs. Sorry if that's misanthropic, but I see the challenge of customizing as firmly planted in the developers' camp for the foreseeable future. (Probably developers from other continents, of course, but developers nonetheless.)

I'm not saying what you're talking about isn't a major-league disruptive technology - I just think it's disrupting a different portion of the market, where the work-culture itself fosters an incentive to improve the organization of which you're a part, not to be risk averse and slog through suboptimal processes (as witnessed in the enterprise). As Jason Fried says, "We don't care about the Fortune 500--it's the 'Fortune 5 million'--the small businesses that are doing interesting things."

(And thank you. The conversations are happening faster than I can recover from jetlag to attend them, but I guess that's the atmosphere we're in...)

[Peter Rip]

Megan -

We'll see.

Who would have thought there were 50M people interested in self-customized hosted HTML pages five years ago?

A little ease of use goes a long way to unlocking our inner geek.

[viinnie mirchandani]

On Gartner I think you may enjoy this tongue in cheek post ( I am ex Gartner, BTW)

http://dealarchitect.typepad.com/deal_architect/2006/08/you_need_hype_t.html

On SAP, I posted this comment to Thomas

" I think you are just scratching the surface. Show that you can innovate at the cost of what the web 2.0 companies are doing. Even better show your customers they can implement the stuff without legions of consultants.

SAP and other larger vendors are still missing the seismic change. It’s not just about being able to deliver new technology. it’s also about business model innovation. Sorry, Thomas - you are still a big rock that falls on customer budgets -) "

[Dennis Howlett]

Who cares whether it's called mashup, enterprise 2.0 or whatever? The reason process is such a big deal is because no-one owns it, doesn't know much about what it looks like and has spent years getting their arms around data.

But - and I really think the big players need to take their cue from some of the minnows - when we start to see the first fruits of collaboration between the likes of Freshbooks and Pipelinedeals (if it happens), then we can say we've seen the start of what might be achieved.

Key point? Disparate apps, process connected, sharing, handing off and exchanging data as needed through relatively simple APIs.

What I don't see is that stuff on the hands of end users any time soon. There's a reason geeks are geeks.

[Byron Binkley]

I’m compelled to throw something into the mix regarding tool development at banks having spent some time at a swaption trading desk.
Megan – you’re making an argument that end users have no place in enterprise software development. That sounds to me like the mantra of IT departments: front end users should not write code. I think that’s true with respect to mission critical components, but it’s a questions of boundaries and the effective division of responsibility. There is a huge difference between writing pricing algs, trade order management, and firmwide risk and building front end tools that leverage those technologies. No front end user wants to write backend code. But they do want to leverage those components in an ad-hoc way which can be kludgey, dangerous, and impossible to do with Excel when multi-dimensional data is involved. Programmers who are not on the trading desk have no more business creating the UI than a trader has writing option pricing code. Neither one has the time or desire to really learn what’s necessary to do a great job. The promise of being able to integrate business processes (not just data mashups) in an ad-hoc front end environment would be hugely attractive, and wouldn’t breach the line you’re drawing in the sand – it would allow each entity to ‘program’ the parts that they should program and do so in a controlled and safe environment. The ‘glue’ that would be necessary to facilitate this would have to be a workspace with the same level of data manipulation and processing flexibility as a spreadsheet to effectively ‘mash’ data between the processes. Thus I think a “spreadsheet for business processes” is a pretty apt description of what’s needed and could fit the enterprise end users more appropriately than Excel does.

[jccodez]

" Maybe the users will be able to imbue business processes with social computing features"

Wowzers...chew on that for a while...Social computing features
integrated into business processes...It would have to take advantage of an existing social network, where it does not take calling the help desk to get joe in tokyo an account so we can include him in the conference call and get him the necessary "binary" crap he needs to do what joe does... good stuff!

[Dejan Nenov]

Regarding Enabling Technologies …

The mention of Ruby and Ruby on Rails in the original post made me question the entire premise of Enterprise 2.0 being about enabling technologies. Frankly I do not see Ruby as the cornerstone of enterprise infrastructure today.

I wonder if we will see any Ruby based enterprise apps anytime soon – having given it (Ruby) an actual trial I was very disappointed with performance – it needs to improve by an order of magnitude (today 50 times slower than Java in processing XML for example).

[Neil Ward-Dutton]

Peter, it's great to see you call a couple of things out that have been concerning me about the term "enterprise 2.0" - specifically: "enterprise" and "2.0".

The label "enterprise" is only valid here in the same context as it might be for something like "enterprise application integration" - ie meant to convey a technology that has the potential to be used as infrastructure across an organisation. This is pretty disingenuous though, because as you correctly point out what's really being talked about is only enabling technology - it's not the "enterprise" itself. So I *might* be convinced about "enterprise IT 2.0" - but not "enterprise 2.0"....

Except that the label "2.0" is cringe-making (at least here in Europe, where eyeballs are almost guaranteed to roll when you say it) at the best of times. In the context of an idea like this, it's just counterproductive. Even if we're talking about "enterprise IT 2.0" we probably should also be back-versioning to include mainframe, client-server, first-generation web, and probably a few other iterations around the technology merry-go-round in between those.

We need to clearly distinguish here between the enabling technology, and the new practices that might be enabled through it. "Enterprise 2.0" fails on a number of levels.

Lastly: who will "get it first"? IBM is having a good go. Take a look at the work they're doing on Activity-Centric Computing.

[Raj Kumar]

Architecture by objective

I came across your views at Dion Hinchcliffe's blog. Very stimulating. I wish to both agree and offer a direction for disagreement.

The first book on excellence was written in India over 2300 years ago. Before that ancient Greece had achieved excellence and Aristotle had concluded concerted action driven by consensus is the way to excellence. Since then, while mankind has progressed from animal energy to nuclear energy, it has remained dependent on personnel energy for driving concerted action cum consensus. As a result achievement of excellence, though universally desired and understood, is very rare – less than 1% of all administrations have succeeded and that too for limited periods of time. The global need of government and business administration is reliable and inexhaustible energy for excellence to become a successful pursuit.

IT has the processing power, storage, access and connectivity to offer a language of interaction for the collective mind to progress towards excellence. IT’s ubiquity, and ability to anticipate and be indispensable (with programming) can assure adoption for reliability. IT is inherently inexhaustible. However, the needed language, viz., a compelling means for total interaction, has yet to be created.

How is IT oriented? It is confined in its thinking to the last created tool, laboriously progressing step by step, and may even be headed in the wrong direction with its emphasis on output of useful software, e.g., data mashups instead of process mashups. Tool based thinking (Web 2.0 is alas only a tool) limits IT to the role of passive energy dependent upon humans for the primary drive. The crucial need is intelligent energy that can lead the collective on to the path of excellence. SOA is not even architecture for this energy. It is at best a method to create the architecture needed.

The contours of the architecture required are clear. It has to be the way itself for the daily work and interaction instead of a tool for the way. Communication and collaboration should follow from the way. The way is not going to come with process thinking since the end-to-end process required for continuity in collaboration is impossible. The way will likely be a synthesis of the two alternatives thrown up by Peter Rip, viz.,
• Will the enterprise application guys (the IT dinosaurs) "get it" about embedding communication and social context in long-running transactions, or
• Will the web 2.0 guys (the IT plankton) "get it" about business processes being the purpose of enterprise community and communication?

A possible synthesis that satisfies both the backward view from excellence and the forward view from architecture is a way for work and interaction that builds both business processes and communication. This is not quixotic. Knowledge flows are the foundation of both. The need then is the grammar for knowledge flows so IT can present a compelling language to the user to build collaboration.

Will this grammar come from the pure technology approach that the IT fraternity is bent on pursuing? Only they term the intelligent energy required by society as frictionless working. Frictionless here implies an energy source. To some extent IT has given up the chase by accepting dependence on incentives, viz., personnel energy. It is more likely that the grammar shall come from a convergence between teamwork norms and IT. The norms shall be derived not from process behaviour but human behaviour for while there are multiple processes in play, the human progressing them is unchanging. Is IT willing to pursue this new direction or must a new industry take shape?