The fundamental principles of E2.0 can be applied in a variety of ways to radically improve everything we do in business. Challenged by simply getting businesses to see beyond a focus on the simplist of tools (e.g. blogs, wikis), let alone embrace the thinking that goes along with simplifying business effort, it’s difficult to rush into a vision of the total breadth of possibilities.

While I’ve always purported changing everything we know about software development, I was thrilled to see an old name appear again recently suggesting the same. Reflecting on the influence Tom DeMarco had on me via his book Peopleware (first published in 1987), I recalled that he’s likely the first author to focus on issues beyond the technology itself (esp. culture and context). His opening chapter stated (bear in mind these words were first written over 20 years ago):

“Since the days when computers first came into common use, there must have been tens of thousands of accounts receivables programs written. There are probably a dozen or more accounts receivables projects underway as you read these words. And somewhere today one of them is failing.”

“Suppose that at the end of one of these debacles, you were called upon to perform an autopsy. (It would never happen, of course; there is an inviolable industry standard that prohibits examining our failures.)…One thing you would not find is that the technology had sunk the project.”

In a more recent piece “Software Engineering: An Idea Whose Time Has Come and Gone?“, DeMarco reflects back on an even earlier book of his from 1982:

“In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no. The book for me is a curious combination of generally true things written on every page but combined into an overall message that’s wrong.”

“I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.

Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.”

Most tools labeled Enterprise 2.0 just scratch the surface of enabling people to change the way they work, but not necessarily change the work itself. Indeed as John Tropea (@johnt) suggests the greatest natural adoption of these tools is using them to work around existing business processes. Creating Enterprise 2.0-class software that can fundamentally change business models and operations is a whole different beast.

I don’t think I truly appreciated or was willing to embrace all of what Sameer Patel (@SameerPatel) purported in a couple of pieces, perhaps for concern that it would muddy the already murky waters. In his piece “Don’t Confuse Enterprise 2.0 With Social Computing Concepts“, it took me a while to recognize that he was suggesting in his first diagram that the list did not EQUAL Enterprise 2.0 (as is the tendency for most to suggest), but was indeed part of it.

Sameer also begins to suggest the tackling of major portions of enterprise operations — I believe I got hung up while looking at his original list because of their Web2.0 implications (many of them have both Web 2.0 and Enterprise 2.0 perspectives and focuses). His recent coverage of a more specific example (supply chain), adds significant depth to his earlier points. I also believe there are broader implications for functional-area-focuses like supply chain. Without any intent for the term to be adopted, it simply makes a point, that these are in themselves industries of practice that transcend the enterprise. The term Industry 2.0 helped me then differentiate what the larger potential of a shift in productivity tools would look like if we could speedily replace the ERPs of today.

For me, it was the Tom DeMarco reminders that helped add clarity to it all. And in the end, I have to confess that ALL of this (exposure to the recent DeMarco piece, continued dialog with great practitioners like John Tropea and Sameer Patel) is only possible because of the enabling channel of exchange Twitter provides.

It seems to me that there is an issue greater than adoption at play here: hesitation to recognize the breadth and depth of adaptation that needs to occur across the entire enterprise and every aspect of the business model.

I do know one thing: we’re not going back.