A decade ago, Marc Andreessen coined the phrase “software is eating the world.” At Thoughtworks, we certainly recognize the truth of this — at the heart of every business strategy there must be a strong technology and software strategy. But how does that play out for a ‘hardware’ company? This article examines Lenovo’s journey as a software company: the complexities, tradeoffs and detours along the way; and the critical role that platform building has played.
Lenovo is renowned as one of the world’s largest computer hardware companies, synonymous with PCs, laptops, tablets and servers. And it’s been a massive success: today Lenovo boasts more than $60 billion in annual revenues. But the real story is how it’s been building its software business. I asked Girish Hoogar, executive director for global cloud and software development with Lenovo, how this started out.
A platform to drive software revenue growth
“In 2019, Lenovo set ourselves an audacious goal: to drive 30–40% of our revenue from software and services within five years,” Girish tells me. “Now just two years later, Lenovo’s software and services revenue has been growing steadily, increasing 36% year on year and contributing more than 8.1% of group revenue.”
Similar to other organizations undergoing a transformation, Lenovo used software as a rallying cry to galvanize their people into action. They used Vantage — an app that comes pre-installed on Lenovo devices — as a driver for their software services. “Vantage is different from most manufacturers’ bundled software,” Girish notes with a grin, “because users actually keep this one installed!” Vantage is valuable because it helps users ensure their device is up to date, has the latest drivers and is performing at its best. It even offers predictive maintenance features, warning users of an impending issue. This is useful both for device users and corporate IT, reducing IT workload while keeping employees’ laptops running. Vantage’s front end is deployed to devices, with the back end running on Lenovo’s Users Devices Services (UDS) cloud platform. Vantage provides the user interface, UDS provides the device-specific intelligence.
What is a digital platform?
Before going any further, we should define what we mean by a platform and what makes them useful and desirable. In the past I’ve described platforms as ‘catalysts’ — they help to accelerate another aspect of the organization.
Evan Bottcher describes a digital platform as “a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product.” When thinking about the platform as a product, it benefits many different internal customers:
It’s easier and quicker to build software and get it into production, which benefits developers
The platform provides consistent deployment infrastructure, as well as security and access management, which makes it easier for operations
Over time, the platform provides reusable components that encapsulate business capabilities, which makes it easier to mix and match to create new kinds of customer value, which benefits the business and product owners.
Platform building is an industry-wide trend, with organizations looking to accelerate products to market and to increase their development teams’ productivity. At Thoughtworks, we often help clients use platform building as a transformation catalyst within their engineering organization, and it can lead to better team organization, communication and processes, not just a specific technology platform.
“Vantage benefits from a personalization service called UPE — User Profile Engine — offered through UDS,” Hoogar continues, “UPE uses machine learning algorithms to achieve better content targeting and user engagement.” One example was a targeted audience content campaign run for the game League of Legends. Because Vantage is able to deliver data-driven, gamer-oriented content, Lenovo tripled user engagement from 14.9% to 45.7%.
Another collaboration between the Vantage team and UDS platform brought to market a new survey UX in Vantage, which was extremely effective in driving responses. “We attracted roughly 130,000 unique users across nine geographies over a two-month period,” Hoogar adds. “The data modeling analysis of the survey data conducted by the UPE team gave our Consumer PC Portfolio Management team valuable insights correlating users’ feedback with various device models.”
After this initial success for the platform, UDS began adding use cases such as a personalized recommendation engine, predictive analytics, and auto-provisioning of applications on a device. Today, the platform supports three million active devices at any given time, across 93 countries, and is doubling its capacity every six months, with an eventual goal of supporting one billion devices by 2023.
“Despite being a software platform, UDS is really actually about both software and hardware,” Hoogar reveals, “It accelerates getting new hardware into production, enabling the hardware business to launch new products faster.”
As Lenovo began to build UDS and achieve successes, it became increasingly obvious that there were opportunities for reuse of UDS capabilities — device management, OTA (over the air) updates, remote management and so on — across multiple end-user solutions. For example, ThinkSystem SE350 Edge servers contain sensors to detect unusual movement or if the cover of the server has been opened. If these sensors are tripped, the SE350 goes into “lockdown” mode, encrypting all the data on its SSD and preventing the host system from powering up. If an SE350 is locked down, offsite admins or edge users can unlock the system using a UDS-hosted Key Vault Portal or a mobile management app. These are the same tools that customers use to unlock new devices from the factory, since they are also encrypted for security during shipping. Leveraging UDS’ common core services like Device Management, User and Account Management, Asset Management, Token Verification, and OTA updates creates both highly secured devices and a streamlined customer experience for device activation. The SE350 powers the Ducati motorbike championship and won an award for “IoT Edge Product of the Year” with at least a little help from the UDS platform.
Organizing to build the platform became critical
UDS is built by three core platform teams: two horizontal ‘capabilities’ teams for DevOps and infrastructure, and one unified ‘platform’ team creating services on top. Feature teams — AR/VR, Device Intelligence, and so on — build on top of what the three core teams produce. The core platform teams remain one step ahead of the feature teams, building the things needed “just in time” when requirements are known, rather than speculatively way ahead of demand.
This strategy is one that Thoughtworks sees gaining traction in the industry, that we call platform engineering product teams. These internal teams create and support platforms, which are then used by teams across an organization to accelerate application development, reduce operational complexity, and improve time to market.
“A good example of this acceleration is how we delivered VR Classroom solutions in three months by reusing all of the services we’d previously created for AR solutions,” notes Hoogar, “If the services didn’t exist the solution would have taken at least an additional three months to launch to market.”
A second use case is a collaboration with the Lenovo Android Tablet team. They’re creating the ability to smart message users through an app similar to Vantage, based on their usage and behavior. This will help create a meaningful engagement thus increasing the active use of the app on the Android tablet. Without the UDS this smart messaging solution would take at least three to four months to build.
But not everything has been plain sailing. Building at this scale is difficult, and the challenge increases within an organization that has traditionally been all about hardware but is trying to learn to be a software company too. One thing that is notoriously difficult regarding platforms is whether to treat all possible users of the platform equally and build features to support them all, or whether to favor particular streams of development.
“To solve this,” Hoogar explains, “I said to the teams: we’re going to cheat a bit. While it’s a good goal to build an ‘ideal’ platform, the reality is business has expectations and some use cases are going to be more important than others. So while my teams have a mandate to build for the long term, they do bend the rules a little and favor those valuable use cases that can build business success and support for the UDS platform. An overall governance process ensures that bending the rules doesn’t create a negative situation for other consumers of the platform.”
Platforms as products
Building an effective platform is a goal for most organizations, but can sometimes be difficult to achieve. REA Group is a long-term client of Thoughtworks and has been on a decade-long platform building journey. At one point they realized they were stuck — they felt as they scaled out, they spent more on technology but weren’t getting any faster. The CEO wanted to understand why, so they performed a platform assessment to try to understand their own maturity.
REA found that although they had reasonable platform maturity and reuse at the infrastructure level, they had very little at the user experience level. They had no “UX Platform.” This was counter-intuitive because most of their teams were deployed at the UX layer, they had significant investment there, but were getting the least leverage.
They looked at why reuse is so hard. It turns out that when you have squads close to the customer, solving customer problems, the teams are not really incentivized to solve global problems. As Tom Varsavsky, REA’s chief engineer puts it, “The teams have good intentions around reuse, but when the pressure comes on or when the project slips, those good intentions go out the window.” An example would be a team intending to create a reusable API for some capability, but then skipping that step when faced with schedule pressures.
It seems odd that a well-intentioned team would do something like that, but as Tom points out “The cost of not creating a reusable thing is not borne by the team that fails to create the reusable thing. They still deliver, but they inadvertently make it harder for other teams.” Worst of all, it’s hard to measure the cost of not having something such as an API, because that cost is distributed across the organization.
Tom’s team did find examples where they had very good leverage. One of these is “Shipper” — a deployment tool — that over the course of two years grew to support deployment of over 600 systems. Why was it a success? Shipper solved a real problem that almost all teams have. It was easy to use and teams wanted to use it. It had a strong vision around what it should do (and not do) as a tool. It had ongoing investment. It had a dedicated product person who was the product manager on the team. The team provided internal training for their product and they had a destination on Slack and their intranet so users could learn more about it and get support.
REA realized that these success factors are in fact about product management: Shipper delighted customers and used product management techniques to succeed. They went on to make a key insight: products, even internal ones, need a brand. As they invested further in their internal platform, they created an associated ‘Colab’ brand for it including a logo, product hierarchy, marketing and go-to-market strategies, merchandise and so on. The idea was to create an internal platform brand that teams would want to be a part of.
REA is very happy with the outcomes they’ve achieved through the “product thinking” mindset. Across the company, staff are using the platform and products to communicate their strategy and intentions and to organize and make investments. Tom says that internal brands and product thinking have really helped people focus on internal products an efficiency. He says “the conversation is changing at all levels, from product managers to the executive table, and even for technology teams who are now excited about things like product and customer service.” Critically, REA has improved their efficiency through product thinking without eroding customer proximity or team autonomy.
Platforms are a key piece of organizational strategy when it comes to building software. But our industry is discovering they can also be a catalyst for further change.
“What we’ve come to realize is that UDS isn’t just a platform — it’s the heart of an ecosystem,” explains Hoogar, “As a platform, UDS is something Lenovo builds in-house. But as an ecosystem it becomes something beyond just what we build: it includes many parts of the Lenovo business and also external partners and customers themselves. Here’s an example: UDS ‘remote expert’ services were built purely for augmented reality: aerospace engineers sitting on other sides of the planet wanted to work on an engine together, and were able to do so by wearing AR glasses, powered by UDS services.
“As a one-off solution, that was pretty sweet. But we realized there was an opportunity to go much further: we could provide remote experts for any industry. The service is reusable, and exposed by the platform. Today, remote experts can be utilized even on the consumer side, at home fixing an AC unit.”
Lenovo’s goals with the UDS cloud platform continue to be ambitious. They plan to increase monthly active users to 75 million and scale the number of active devices to more than 100 million. As a platform and an open ecosystem of service-led solutions, Hoogar and his team will add reusable services to address ever larger and more diverse customer needs. Platform building is a goal for many organizations, and we hope the story of Lenovo’s success is both inspiring and instructional for those of you grappling with your own platform journeys.
This article benefited greatly from review and feedback from Ashok Subramanian, Chris Ford, Martin Fowler, Patrick Sarnacke, Selvakumar Natesan and Shree Prakash Damani.
