Kris Cowles on Why Running a SaaS Environment Isn’t Always Easy

Today we share a recent conversation with Kris Cowles, Vice President, Global Applications IT at Topcon Positioning Systems, a 2,000-person division of Japanese company Topcon. Previously, Kris worked as the Director of Engineering Operations at Cisco. She discusses some of the growing pains of working with SaaS vendors and how she’s making it work.

OpsRamp: Describe Topcon’s IT infrastructure profile and how it’s evolving?

KC: Our core manufacturing sites are standard on-prem and most everything else is in the cloud, so we have a hybrid setup. We have a critical footprint of SAP technologies, but also Salesforce, Zuora, Adobe, WorkDay, NetSuite and a variety of other apps.  Topcon is like a lot of other companies in that our complexity comes from both organic growth and a number of acquisitions. We’re in the process of ERP consolidation, but that’s going to be a multi-year thing.

OpsRamp: How does running a lot of SaaS apps affect your team, for instance around shared responsibility for the work and the outcomes?

KC: The whole transition to the cloud for executives is much more than financial. People focus on the soundbite of, we can move faster, consume innovation, gain talent and expertise and security. All of this is true. We have been able to rapidly deploy standardized solutions at project speeds that used to be impossible. Also, like many companies trying to cope with the cybersecurity landscape, part of our strategy is to use secure cloud applications backed by amazing technology partners. But it is also a cultural change for the extended leadership team that is used to hands on, direct control. The age-old perspective that if something goes wrong, you go and stare laser eyes at IT until it gets fixed? Well now we are more of an intermediary. I am dependent on another company and they may not tell me exactly what’s going on or they may not tell me how significant it is and their estimates for business restore may be …. opaque.   I understand many of the reasons why they can’t give specifics, but this can leave customers in a difficult position.

OpsRamp: That sounds pretty frustrating.

KC: The loss of control is very difficult for traditional execs in my role and in the C-Suite to accept. Sometimes the vendor says the app is up, but our business is still down. It’s an emerging discussion in the industry for a business process to have an SLA in SaaS markets; that’s an evolution that is active but not actualized yet. When there is an outage, our first step is trying to identify if it is us, the vendor or any other intermediary. If it is just one customer, or different customers are affected to different levels of severity, then you calibrate on the severity of the issue, followed by an escalation process. The big problem is there’s not a monitor on their side alerting that your business process is down. The vendor might make small changes that seem minor but all of a sudden my connection between two systems is down because one upgraded and the integration is not backward compatible. The vendor will say, we don’t take responsibility for backwards compatibility with interfaces. IT organizations grew up with the concept that the change management, the communications, and the commitment to operations excellence is not at the application level. It’s at the process level. The SaaS vendors are still working to make that transition.  

OpsRamp: Can you do anything at the contract level to prevent this situation?

KC:  I have not yet seen SaaS companies that will put an SLA around a process. And with 20,000 or 50,000 customers, it’s challenging.  I also understand that it’s not simple to identify if a customer has changed anything on their side which would impact a process SLA. In that scenario, there is a tangible reason why a vendor would *not* provide a process SLA, because the customer may have modified things beyond the vendor control.   The flip side is, if it’s a standard process, it should work and survive upgrades and changes. If they can’t perform their core process for whatever reason, the business is down even if the application is up. This is not typically covered by SaaS contracts.   

OpsRamp: How about data issues from having many SaaS partners?

KC: All the data models are different. We’re only starting to see nascent conversations between vendors on things like industry standards for customer naming conventions. Doing something like that is really hard. Can you find some companies that aren’t competing with each other and have enough of the market and get them to work together? This is not different from running on-prem applications, with the exception that if we build a custom integration for an on-prem system, then we decide when and how to change it. When you are on a SaaS vendor upgrade schedule, your bias is to use standard interfaces which are not constantly needing testing and modifications.

OpsRamp: So what’s the upside?

KC: I don’t have the traditional coupling between applications and the infrastructure and that provides a lot of flexibility and gives us speed. Because it’s primarily on demand you just turn it on and when you’re ready, and the best practices are there to consume. It is critical that every company evaluate if they can use standard business practices. That gives you enormous ability to scale with cloud. In this model, we don’t do traditional requirements gathering or ask: “what do you want?” We say: “this is how it works, so tell us what does or does not fit.” We can build templates that are simply adjusted for minor differences and deploy.

One potential review point is this: we assume the value in SaaS is the constant innovation, but I don’t know many large organizations that want their processes changed two or three times a year. The assumption about how much change the business can tolerate varies per size and type of company. If a company is on a slower change cycle, they may defer the “innovation” in an update and then someone comes with a contract renewal with a standard price increase for “all the innovation” that was in fact, not implemented.

OpsRamp: I guess you’re going to pay for it now or later?

KC: Yes. Innovation is there for when you want to adopt it and there is value from a best-practices point of view. We can templatize rollouts and move through it so much faster than before. Also, for career IT people to no longer have end-to-end 24/7 P1 ops responsibility is excellent.  We can trust that some truly terrific companies are doing multiple layers of the stack—compute, database, security, storage—at a scale we cannot do ourselves. Additionally, there’s great value in SaaS as companies get smarter about how they engineer apps. There’s a difference between purpose-built cloud systems containerized properly and those that are a legacy code stack and happen to be available in the cloud. Sometimes I talk to vendors about how SaaS is treated like on-prem software. Don’t send me all the release notes. It’s SaaS. You should know what I am running. Only send me the notes I need and tell me what I should test. Most SaaS companies are not yet delivering upgrade information in the application itself. It could be massively personalized and there’s a big opportunity there.

OpsRamp: What’s your strategy then moving forward, to thrive in the SaaS world?

KC: We have to be integration specialists, cloud specialists and process specialists. You end up with data people and much more complex skills. I really need people who can run integration architecture across APIs, more so than Java or C+. You still need to have strategic conversations with the vendors and keep advocating because the goal of any company is to be successful in the cloud. We can help them differentiate from competitors. And in the meantime, you try and solve the issues yourself. But if we keep solving all the problems ourselves, we won’t get our money’s worth. We are still doing a lot of innovative things and capitalizing on everything we can and seeing a huge amount of benefit. But cloud is way more complex than it would seem to be. The grass is not greener—just different.

OpsRamp: In closing, I’d like to address diversity. Have you ever experienced significant challenges being a female in a male-dominated environment?

KC: Sure, I do encounter that, but in some ways tech is a normalizing sector to be in. If you have the right type of tech and strategy execution, nobody cares. But there are still challenges with traditional business relationships and social interactions. A customer appreciation event that features activities that tend to be preferred by men may feel non-inclusive. But you also get an occasional uplift where people ask for your opinion because you are the female. Hopefully that goes away as more and more women not only achieve success but also are visible in industry. Having said that, I’m careful to not follow the path of tokenism. In any field that is male-dominated, women must have a level of personal resilience that protects our potential exposure to these biases. Ignoring most of it tends to make it go away or else, you can take a very diplomatic but firm stance at the beginning. Establish your role, don’t conform and don’t get upset.  Be the leader you know you can be. Sometimes I push myself to do things I wouldn’t normally want to do like speak at events, because attendees want to see diversity in the speakers and more choice of people they can relate to. My goal is not in self-promotion, but I do feel I have a brand to represent for my department and my company.

Next Steps:

• 451 Research Review of the OpsRamp Winter Release.
• Read our previous interview on Solving the IT Talent Crisis.
• Subscribe to the OpsRamp Blog!