The Cultural Implications of ‘Technology Enablement’

It’s hard to talk about IT-related topics like “services oriented architectures” or how they are delivered “over the cloud”, etc. etc., without sounding like a complete geek. And admittedly, occasionally descending into the Land of Geek is fun, especially for people like me who once made a decent living writing code. But the technology industry (and RSR) knows that the business world is sick to death of geek-talk, and so some pretty geeky concepts are couched in “nice” words. For example, there’s a lot of talk nowadays about “technology enablement”. It sounds nice and non-threatening, certainly a lot less threatening than yesteryear’s bugaboo buzzword, “automation”. But the new phrase isn’t just a replacement for the word “automation”.
The differences between the notions of “technology enablement” and “automation” are subtle but significant.
Prior generations of technology implementations were all about using machines to perform rote tasks. That necessarily meant streamlining a business process to the point where variations were kept to a minimum – then getting automation to perform most the process, while humans dealt with the exceptions. Another way to look at this notion is that human activities were wrapped around the automation.
But “technology enablement” implies just the opposite- that the automation wraps itself around the human activity. That’s an important distinction. Whereas “automation” necessitates that a process be fairly rigid, “technology enablement” assumes variability.
Implications to the IT Culture
There are a lot of very good reasons for technology companies to promote- and retail companies to adopt- “technology enablement” as an imperative. To summarize them all: mere “automation” just isn’t enough – business models aren’t static, and so the technologies that support them can’t be static either. It’s taken a long time for retailers to recognize this as they have continued to squeeze every penny of value from their legacy portfolios of IT applications. Regardless, based on our research in the last several years, it is RSR’s view that:

· Conventional retail IT portfolios have become a bottleneck, limiting retailers’ ability to both offer new services and lower costs;
· Cross-channel shopping is here to stay, and needs to be enabled by consistent data and business rules across all selling channels (stores, catalog, web, and mobile), with seamless integration between those channels.
· The need for consistent information and business rules across all selling channels necessitates a move towards ‘network-centric’ computing
· Lack of an effective enterprise governance structure for IT and a poor “business process” orientation within the company are top inhibitors to roadmapping the transition to more effective IT value delivery.
In short – IT value delivery in retail needs to change.
What’s Good for the Goose
IT’ers are fond nowadays of reminding their business counterparts that “it’s not about the technology, it’s about enablement”. “Enablement” in turn is enabled by new IT architectural concepts (eg. SOA) and new delivery models (eg. “cloud”). But what’s good for the goose is good for the gander. Just as new ways of delivering technology force businesses to embrace the notion that their business models are fluid and require “agility”, the IT department needs to embrace more agile ways of developing and delivering that technology enablement. That means that old rigid ways of developing and delivering systems are no longer appropriate.
There hasn’t been a lot of talk about what this means in retail IT departments, but tech industry thought leaders have uncovered important inhibitors that need to be adequately addressed by companies as they adopt the new concepts:
A top inhibitor to successful adoption of new architectures and delivery models is as old as IT itself: a tendency to think of it as a new set of tools, and not a new set of processes. But a move to new architectures and delivery models causes ownership of the technology to shift from IT to the business, and that in turn necessitates that IT and the business work much more closely together – and that means that the “hierarchical” methodologies of old don’t work anymore.
Another key inhibitor frequently overlooked is related to the “ownership” issue mentioned above. In the old way, projects are typically individually funded, managed individually, and each project tends to have its own set of interests and objectives (conflicting objectives have to be solved by a project management office – PMO). But SOA development efforts are often many and small – in fact the collective effort can be pretty chaotic (it’s perhaps ironic that one SOA development methodology used today is called a scrum). To resolve this, some experts recommend an “SOA competency center”, funded by the company separately from individually funded projects. The function of this organization is to deliver infrastructure and middleware, as well as make generic, reusable, services available to the individual project teams.
A third inhibitor is all too common in retail generally: under-investment in training. Somehow IT’ers are supposed to “get” the new development tools and processes, as if by magic. But just as businesses have found out that organizational change management is an essential ingredient for realizing the ROI of any newly technology-enabled business process, so also must the IT organizational changes that new architectures and delivery models create be addressed.
Upcoming Research
The challenges and opportunities associated with new systems architectures and IT value delivery models are coming into focus as retailers turn their attention to omni-channel retailing. New technologies such as “smart” mobile devices create the need for visibility into the corporation’s digital assets far beyond the traditional perimeter of the “four walls” of retail. This in turn has profound implications not only on IT architectures and governance processes, but also the culture of traditional IT organizations.

Source