Pace layering: the glue between E2.0 and ERP?

Having had a few days to reflect upon Enterprise 2.0, gather alternative perspectives and, purely by coincidence, attend and participate at SAP Inside Track London, some important pennies have started to drop into place. These center around the notion of pace layering, a topic I knew nothing about before reading James Governor and Thomas Otter's pieces back in 2007, but which has largely disappeared off the public radar in the intervening years.

It seems the consensus among the thinking classes as opposed to the handwavers and tech pimps is that Enterprise 2010 represented something of a watershed. Rather than bang on about the introduction of rogue apps from the bottom up or adoption as an exercise in hand wringing, those who truly understand the challenges of introducing technology into the enterprise landscape have made important connections.

Sameer Patel eloquently captures much of what was said and unsaid but ultimately skids off track as he continues to promote the themes of Enterprise 2.0 as though it represents some sort of springboard for a collaborative Valhalla. I don't mean that disrespectfully since I know Sameer is a deep thinker on the topic and this was part one of a two-parter. But like all evangelists, there's always the danger of believing your own BS to the exclusion of other possibilities, even if it is only for the attention span that a blog post can command. Even so, his first pass assessment and analysis provide solid learnings for those who follow this technology strain

Oliver Marks, Sameer's business partner and ZDNet blogger took a different position. While generally supporting the notion of collaboration, Oliver speaks to the reality:

While we can make mistakes and experiment on our own terms in our own time, there’s a lot at stake gambling with your career and company fortunes by trying new ways of interacting and collaborating together.

While some individuals are a terrific fit as collaborative ‘Swiss Army Knives’, adept, intuitive and facile at multitasking with modern 2.0 tools, most work at a slower, less intuitive pace within safe, familiar boundaries.

[My emphasis added]

I'm guessing that the days of credit card tech acquisition are largely over and that now comes the serious work of figuring out what all this 'stuff' means for the enterprise going forward.

For my part I was genuinely surprised at how many people agreed with some of my more strident remarks around building business cases, handling change management issues and understanding the nature of value once these topics are elevated to the C-suite. At a conference of that kind, I expect to be given a tough time by the evangelists.

Instead, folk like Lee Bryant of Headshift/Dachis, with whom I rarely agree, was gracious enough to come up and tell me after our joint panel session: "You'd be surprised at how closely aligned we are in many areas." Lee is by far the best marketer I know on these topics who combines that skill with incisive insights into the human condition - an absolute pre-requisite to understanding how new tech gets successfully introduced. I guess I am the rough diamond who slaps people in the face with what I see as obvious common sense errors of judgment. Where we most strongly disagree is with the use of 'social anything' and in particular what I see as a loathsome concept: 'social business design.'

It was with some sense of curiosity that I listened in on and recorded Lee Provoost's presentation at SAP Inside Track. (an edited version appears at the top of this post.) Lee is ex-Cap Gemini and a senior Headshift/Dachis consultant. He talked about the disconnect between the needs of business to be agile while IT wants stability. For Enterprise 2.0, he substituted the term 'interactive' and for ERP he used 'transactional.' In my mind these provide better representations of what the technology landscape is telling us.

He said that for interactive, we could presume that most of the technologies would involve people. I take that to include both E2.0 and some SaaS elements like talent management and surround SaaS strategies for companies opening small subsidiaries and needing agile implementations for systems of record but which can be linked back to the core.

Lee made the point that transactional systems run at a slower pace than interactive - which makes sense - and that is a significant factor in adapting systems architectures and landscapes. His solution is very similar to the pace layering idea where apps are layered but mediated through common services such as identity management and security policies and protocols.

From my perch, this represents an interesting way of driving value while at the same time maintaining an ever hardening core of transactional systems. The difference is that Lee brought the topic to my level of business understanding without having to get into the guts of the technology requirements. That has been the missing link in my understanding. If it's been missing for me then it has been missing for a lot of people I know who take tech buying decisions.

Is that a slam dunk? Of course not. Tom Wailgum notes that rogue apps are alive and well. Maybe pace layering could be a solution. Some of those attending SAP Inside Track pointed out that as the agile systems mature and inevitably become subsumed into the core, then wouldn't the overall cost be a dis-incentive as core apps are re-engineered? Lee came back with an answer I can definitely buy: "But in the meantime the business has derived considerable value, perhaps over several years from those agile applications so would you perpetuate the problem of waiting months or years for a constrained IT department?"

It is too early to say whether those trade offs will weigh heavily enough to encourage business to be more adventurous in its adoption of E2.0. I suspect that once again, we need to see the proofs, if not the ROI calculations.

In the background however, vendors like Salesforce.com and SuccessFactors are figuring out how to embed social computing applications beyond the superficial Twitter feed directly into the processes they manage. FinancialForce (disclosure: FF is a client) is already working at developing a string of practical business use case examples where this makes sense. I see those scenarios as far easier sales than a standalone blog, wiki or similar aggregated feature laden application.

It cannot be long before SAP, Oracle, IBM, Google, Cisco and Microsoft wake up and do similar things. When they do then as Oliver implies, ownership of the discussion will shift away from the many smaller players while allowing the big vendors to offer a genuine pace layered vision of their own.

And finally, if you need any further convincing, then it is worth watching the sixth part of a BBC series called How Buildings Learn. In that film, Stewart Brand, the author of the book of the same title makes the point that the best buildings are those that don't fulfill the architects dream of something that makes an enduring statement but those that adapt over time. In the film, which is subtitled Shearing Layers there is a segment showing how a particular building was added to over time but maintained its original integrity dating back to the 18th century. It is interesting to note that it wasn't building architects that latched onto the book that predates the film series but technology architects. That was back in 1994. I suppose you can argue that pace layering has been with us a long time but perhaps more invisible than many realize. My view is it represents the right argument for developing ideas around how E2.0 can be introduced to the enterprise in a way that doesn't hurt IT. Couple that with 'interactions' and it shifts the compass in a positive way.

My thanks go to Jeremiah Stone for pointing me in that direction albeit for different reasons.