IN SUMMARY:
WHO: Norm Fjeldheim, SVP and CIO, Qualcomm
WHAT: Sharing his views on Qualcomm’s approach to “everything as a service” (XaaS) for its 21,000 employees worldwide
WHERE: San Diego
WHY: To provide CIOs and other IT leaders with actionable advice and insights about how to optimize the complex infrastructure of today’s IT organizations
Norm Fjeldheim, SVP and CIO of Qualcomm, the $15 billion maker of communication equipment, has had an unusually long tenure as CIO, having taken on that role in early 1999.
A 24-year veteran of the company, Fjeldheim has overseen significant changes to Qualcomm’s IT infrastructure. Roughly 1,400 of Qualcomm’s 21,000 worldwide employees report to Fjeldheim.
San Diego-based Qualcomm, which operates 200 offices worldwide, is engaged in the development, design, manufacture and marketing of digital wireless telecommunications products and services. Its divisions include Qualcomm CDMA Technologies, Qualcomm Enterprise Services and Qualcomm Government Technologies.
In January 2012, the company was named one of Fortune’s 100 Best Companies to Work For.
In this one-on-one Q&A, Fjeldheim tells CIO Insight’s Peter High about Qualcomm’s approach to “everything as a service” (XaaS), the rationale for choosing this approach, the challenges he met along the wayand the value he has garnered for his company.
CIO Insight: Norm, you first dipped your toe in the water on cloud computing and the SPI model [software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS)] before those terms were well known or widely used eight or nine years ago. What was the impetus for delving into virtualization?
Norm Fjeldheim: We began a little less than a decade ago when members of my team approached me and indicated that they thought virtualizing would add tremendous value to our operations. They indicated that it would render our operation more efficient, and that it would lead to significant cost savings. I asked the team what they needed to begin this journey. They said they needed a modest financial commitment to get started: a couple of hundred thousand dollars. I challenged them, saying that if virtualization was to be such a cost saver, we should expect that these activities would be self-funding after this initial seed investment.
The team began with Windows-and rather conservatively. (In retrospect, I wish I had pursued Windows and Unix together, so that it would not have looked like a Windows-specific effort in the beginning.) However, the efforts quickly built momentum. In the end, the team required significantly less than the initial commitment before these efforts became self-funding.
Our biggest foray into SaaS came by happenstance. We were a big user of Siebel for our CRM solutions. In 2005, a new business unit of ours was ramping up, and as the unit members planned the deployment of their first product, the software requirements did not include any mention of a need to ramp up Siebel in the process. As we found out about this six weeks prior to the launch of this new business unit’s first product, this led to a short time frame to get the functionality up and running and therefore [ramping up Siebel became] a pressing need. We realized we were not going to meet their needs, and it led us to think about alternatives
We pursued Salesforce.com potentially as a one-off instance for us, but discovered that it had as much functionality, more flexibility, and could be implemented and ramped up in a fraction of the time of our solution. We ended up migrating to Salesforce.com completely, and saved 50 to 60 percent in costs as a result, with improved functionality.
You run IT for a very engineering-centric organization. Engineering-led organizations tend to be challenging environments for CIOs, since many people outside of IT think they can do the CIO’s job better than the CIO can. Were there cultural hurdles to get over when you announced you would enact this change?
Fjeldheim: The biggest hurdle was cultural, actually. There was a general bias among engineers-in our company and beyond-to have physical equipment optimally under one’s desk. We asked them to change the model rather significantly. The challenge we had in selling this was to ensure that our engineers would either get the same value at a lower cost by putting more of what they used in the cloud, or better value at the same cost. That was another challenge we as an IT department put on ourselves, and I’m happy to say that we’ve been able to consistently deliver against that.
What other issues did you face in those early days?
Fjeldheim: The other major issue, frankly, was that demand for cloud computing and the SPI model grew so fast that we had trouble keeping up with it. As I said, we were able to deliver against the value-to-cost challenge that we gave ourselves. Once we did, cloud computing and the SPI model took off and built a momentum of its own. That was the right problem to have in the early stages of this transformational journey, but it was a problem nevertheless. We had to play catch-up on the automation as a result.
The key at that stage was pausing and thinking about the new fundamentals we needed to have in place to ensure that we could build out the cloud, but do so responsibly. We ended up investing in management tools, monitoring tools and ITIL. We invested in processes and the automation of those processes. We used ITIL as the process framework and then bought and built tools to manage and monitor our infrastructure. As much as possible, we deployed the same processes and automation across our entire environment, virtual and physical. We went from managing 400 virtual servers to managing 4,000 of them. A tenfold increase required that we think about things significantly differently. This laid the appropriate groundwork that has sustained us through the subsequent years.
When we transitioned more of our software to the cloud, leveraging the SaaS model, we had to find solutions that would also work with our customers. In some cases, we partnered with our customers to transition together. This meant proving the benefits to our customers so that they would see this as a valuable change in their organization. We benefited by transitioning to SaaS earlier than many of our customers and had our own business cases to present as a result.
For our virtualization efforts, a lot of the tools didn’t exist, so we had to build them ourselves. This slowed us down a bit and made the virtual environment much more complex. We had to keep our top engineers on the system to support it and troubleshoot problems. Later, as better tools came out, we were able to reduce that requirement, and we now have much of the system supported by more junior engineers.
For SaaS, the biggest problem was integration. The integration tools were not very good initially, so that was a big barrier to using SaaS applications, specifically SalesForce.com. SalesForce.com improved the integration tools several releases ago, and that made a huge difference. We were able to pull and push data in and out of Salesforce.com much more easily, which enabled us to use that product much more broadly [than previously possible].
