Washington Post CTO Yuvi Kochar Wants Cloud Vendors to Give Him an Exit Strategy
No-Size-Fits-All! An Application-Down Approach for Your Cloud Transformation REGISTER >
With a solid track record of anticipating what cloud vendors need to do next, Yuvinder (Yuvi) Kochar seems content to be a patient prod for the industry. Kochar is VP-Technology and CTO for the multi-headed media giant Washington Post Co.
Three years ago, he talked in an interview with CIO Insight about the need for coherent price and license schemes for cloud services. As the company's first few multi-year licenses have come up for renewal, Kochar now tells CIO Insight's Jim Nash that he is concerned about getting contract provisions that help ease his company's migration to other vendors who may have new and innovative service provisions.
Kochar also describes the cloud picture for his firm, which publishes newspapers, magazines and Web sites; programs TV and cable content; and innovates in Internet marketing and advertising. Far from a one-size-for-all approach, he says Washington Post Co. stays out of cloud decisions (as well as other IT matters) involving individual business units. The units know what they need, Kochar says, and there's little leverage for corporate.
He directly manages Washington Post Co.'s 20-person Shared IT Services department and a heavily outsourced managed-infrastructure and application-management team. Kochar says the core needs serviced by his team are prime territory for cloud implementations.
Perhaps symptomatic of cloud being a relatively recent development, he says the company doesn't have a cloud-specific ROI calculator. All cloud projects are handled within the normal IT governance processes.
SaaS is present in several point solutions in Human Resources, Finance (too a lesser extent), Sales and e-mail. Some or all R&D/new products, analytics and online media-site hosting functions are delivered via infrastructure-as-a-service contracts.
In fact, he says, he'd consider putting almost anything there in the cloud if it made sense.
CIO Insight: In a 2009 interview, you were a clear-eyed skeptic while your peers tended either to dismiss the idea of a pervasive cloud future or to echo marketing hype. You said you foresaw significant early market problems being resolved as the industry matured. How do you feel now?
Kochar: Cloud computing is here, and there's a broad opportunity to leverage it. Cloud enables agility and provides a variable, expense-based IT costing model. Given the current business climate, business customers like that a lot because it allows us to be much more flexible than we have ever been able to be in the past.
There still are risks to cloud computing. How critical is it to what Washington Post Co. does?
You have to keep your eyes open with new technology and be selective. There are certain things that we are very hesitant to get into because of the risks, but the cloud has clearly proven itself. We have a lot of experience with it -- and when I say cloud, I include software as a service. We're leveraging cloud services both at the SaaS level and the infrastructure-as-a-service level.
At the end of the 2000s, major cloud concerns were security, privacy, response time and up time. Those will never go away. Are there other concerns today?
One of the concerns is vendor lock-in. It's very easy to get in [to a vendor relationship] and very hard to leave.
The migration path concerns me a lot. As solutions in the market mature and new solutions become available, vendors have no incentive to make it easier for us to leave. Some of our first multi-year contracts have come up for renewal, and some we've renewed readily. Others, the service wasn't terrible and leaving would be have been hard, so it became a matter of, 'why not just stay?'
What about the inevitability of industry consolidation?
That's where I go back to the importance of building solutions and architectures and plans that factor in the changing vendor landscape and vendor posturing. We need the freedom to make moves.
I actually don't mind consolidation of the marketplace so much because then I have fewer vendors to deal with, and I have more spend with each of them, which provides leverage. Still, I like to spread my budget across multiple vendors because it keeps everybody honest.
The way I hedge against this situation [consolidation] is by having two areas that I don't outsource. One is business analysis and the other is functional knowledge of how we leverage a solution to solve a problem. In addition, we internally provide strong Project Management and Service Operations oversight.
Based on the function a system supports, we're trying to reduce our involvement in the deeper technology. When it comes to corporate shared services for back-office functions, we have an IT team without technologists.
Let's talk about Washington Post Co. for a moment. How would you describe cloud use there? Is it a uniform operational layer, like an overcast day, or is it more like a cloud here, a cloud there?
More the latter. Our company's businesses are making selective decisions, and at times it's hard to change the status quo.
Meaning, some units don't want to change how they operate?
Kochar: Yes. But also, the company is very sensitive to spending. At this point, due to a decline in revenues, the organization is very cost-sensitive. Therefore, we are looking for relatively quick ROI on any cloud projects.
Let's say I want to acquire 50 servers in the cloud, and the rate is a dollar per server per month. For that number, $50 per month, to be viable and if this is a replacement or I have to shut down 50 servers, then I have to come up with $50 of savings concurrently. IT is not integrated in the same fashion that we are buying cloud. IT departments have skill sets across servers and applications -- DBAs managing printing apps or sys admins or OS folks -- who are managing broad ranges of infrastructure.
So, we're actually transforming our purchase from a broadly functionally distributed team to a vertically integrated solution. And it's very difficult to take the costs out until you do a broad-scale migration, where, say, we're getting out of all of our servers.
And not all of our application portfolio is cloud-ready. A lot of our application portfolio is antiquated and, at times, doesn't even run on the virtual machines available in the cloud. That's why migration to cloud is slower when it comes to existing products and faster for new things that we do.
For example, we've got a labs group coming up with new models and services [for the News operation]. The labs people are very heavily into cloud usage because they are already building new things from the ground up on the cloud. But our core Web site, [www.washingtonpost.com], running on a monolithic CMS and several large home-grown applications, is far from cloud-ready. As it's currently installed, washingtonpost.com as a whole would be much harder to pick up and put on a cloud.
Now that you mention it, will washingtonpost.com ever be served from the cloud?
It's interesting. We sold newsweek.com, and that site was on the cloud and using technology that was very cloud friendly.
We need to migrate toward that situation. We are working on migrating portions of the site to the cloud.
We have so much other work to do around innovation, finding new business models and trying out new channels. Across our businesses, there's hardly any stomach for a large-scale migration project of existing technology to the cloud. That's unlikely to change until doing so is a differentiating point.
It would almost seem that you could use chief cloud officer! How do you manage all the services?
We don't try to get deep into each unit's business. There's nothing for us to leverage. When it comes to common things like Finance and HR, we are way involved, and we're driving that heavily.
But even at the level of core operations, there has to be a high degree of duplication, if nothing else.
I've architected the back office as hub and spokes. Most of the cloud offerings are spokes. We're seriously evaluating if we can take the hub itself into the cloud, but the architecture [of centralization] would still remain essentially the same.
We try to manage data within the hub, and manage transactions and processing in the spokes. Integration of two cloud providers is easier this way because you traverse it through the hub, which keeps you flexible. And you don't have to get two competitors to work with each other to build that integration.
Do you see a day when you will need greater centralized control?
I do get engaged at least at a review level, but I don't have any one person dealing just with cloud contracts. I do have an operations officer dealing with the SLAs and all the service offerings of my vendors.
And my legal group, obviously, is quite educated about security and privacy and the warrantees and indemnities that go with protecting our data. We've done so many of these contracts -- 15 or 20 now -- I think our legal group is savvy about what's important and what isn't important.
Let's look at that. What's it like dealing with cloud vendors. You've spoken a good bit about contracts, which seem to be the last thing that most people talk about when it comes to any new product or service. Yet inevitably, there are surprises.
I'm very engaged with all the contracting that we do. Closely following contracts allows us to level with the vendor about what we will do and what we want them to do. We still get surprised, but because we pay careful attention to contracts, we have some context when surprises come up. I also try hard to let my vendors -- my partners -- know what my goals are.
Not to focus too much on contract exits, but is it at the top of your mind every time a contract comes across your desk?
Well, I think about it. Unfortunately, vendors are not investing a lot in that space. A lot of them say, 'We'll be happy to give you your data, and you will be happy to move forward.' Google is saying, 'We'll support you if you want to exit." Now, that remains to be seen.
The whole idea that vendors have to earn their paychecks over a certain period is sinking in for cloud. The business models are changing to support that behavior.
Is negotiating with cloud vendors different from haggling with software vendors?
It has less to do with the contracts being for a cloud service. It's how vendors posture.
Oracle and SAP and Microsoft are very large organizations, and have their policies and procedures, which are very hard to alter. Google is more flexible, but that's where they are in their evolution.
Do you see cloud being strategic three or five years from now?
Business is strategic, not technology. Clearly, you have to keep up with the times to remain competitive. And cloud technology will continue to change how businesses are put together and run. Three years from now, we'll still be going down the path of leveraging cloud.
At one point, local-area networking was strategic. Now it's just what you use.
Cloud computing can provide some strategic differentiation, [but] in three years it'll just be what everyone will be using.
Is there a graphic that maps cloud use throughout Washington Post Co.?
There is no broad companywide diagram. We have a chart that puts all our technology on a page, and there are cloud parts and non-cloud parts. More tech components are going into the cloud.
If I were to look only at shared services, where we have a significant SaaS offering integrated with our core PeopleSoft HR system, I'd have a very nice chart [showing broad cloud use].
You were quoted last year saying, 'Am I ready to put my ERP system in a public cloud environment with whatever promise Amazon might give me? Probably not.' Of course, you were speaking not about Amazon but of cloud providers generally, but is that sentiment still valid for you?
I'm open to working with a SaaS provider, given the right contractual guarantees to manage even an ERP-class functionality. I don't know if I want my team to essentially run my ERP in a cloud environment and build all that custom security just for me. I would rather a vendor create it for 100 of my competitors and present me with something that's well-baked.