Should a retailer act like a technology company?
Given the rise of digital technologies throughout the retail environment, should a retailer adopt the software development processes used by a technology company?
Retailers’ software development activity is seen as slow and expensive, with large IT teams stuck in sluggish implementation projects and enhancement iterations that deliver poor quality outcomes.
On the other hand, technology companies (given software development is their core competence) are assumed to have best practice processes and are therefore a rich source of inspiration for retailers looking to re-engineer and reinvigorate their own processes.
A retailer’s technology applications are measured against those of the young technology giants.
A retailer, in common with other consumer sector businesses, has a specific problem when planning technology. Consumers measure a retailer’s web and mobile applications against the rich, well-designed and well-executed standards of comparatively young technology giants such as Google, Facebook and Twitter. Yet a retailer must deliver its technology into a messy internal environment that has evolved over decades of investment in core enterprise retail systems, physical store infrastructure, and diverse supply channels.
Retailers do not replace their entire technology stack to suit the new digital age; the disruption would be too far-reaching and the risk and cost astronomical. Instead two approaches are taken, namely large technology replacement programmes and smaller scale continuous improvement. Neither is proving ideal. Big programmes often see multi-year delays, budget overruns, and adverse results, and continuous development is delivering too frequently a slow rate of change and poor quality code at high cost.
Something is fundamentally broken in many retailers’ application development processes.
Many of the changes in process being tested are well-documented. These include implementing cloud and SaaS solutions to reduce the complexity of IT, bringing in external partners to increase development capacity, co-locating business and IT resources to improve communication, use of services architectures and APIs to encourage application re-use, avoiding customisation by implementing packages in their vanilla form, making developers responsible for supporting their code so they are motivated to deliver quality, and finally re-engineering the IT function to act more like a technology company.
Each of these approaches can deliver benefit, but we find very specific circumstances in which each is successful. For example, implementing a package in its vanilla form can only work if there is a strong commitment from the business to adopt the processes inherent in that package and the compromise on function is accepted as the trade-off for reduced project complexity and cost.
The most recent attempt to spark productivity in IT development is to adopt principles from the software engineering industry.
The aim is to deliver robust code quality at speed. Some very specific software development techniques are normally meant when retailers adopt software engineering principles, such as test-driven development, automated testing, continuous integration and code refactoring.
However, many retailers will find their core packages do not support many of these practices. Test-driven development and continuous integration, for example, are rarely supported by mainstream commercial packages and can therefore only be used in limited circumstances, such as a custom application, user-interface or integration layer. Automated testing is more widely supported and can improve development speed, but the trade-off is the effort required to set this up, maintain it and enforce it. Code refactoring is always possible and is a healthy practice to increase code quality, albeit with a short-term productivity drop in return for long-term speed of development.
What has received less attention, but is definitely a core competence of a software company, is the concept of product management.
This is the process of managing the evolution of a software product by understanding business demand for change and producing a coherent development roadmap, while mediating conflicting interests. If a retailer’s website is the software product, then a product manager is responsible for ensuring both consumer and business user interests are reflected in the roadmap, dependencies are understood, competing initiatives are prioritised and the roadmap takes account of any concurrent changes being made in wider middle and back office systems such as Product Information Management and Order Management.
The question, as a retailer, to ask is not, “Should I become a technology company”, but, “What are the specific challenges I am trying to address, what are their root causes and which of many techniques will work best in my environment and culture?” For many this is not a simple question to answer, but it is the right question to ask.