I had the privilege of leading a project to implement App Synth Monitor (“ASM”) for a major financial services organization. ASM is a complete cloud-based solution to monitor Web sites to ensure they provide a positive customer experience. This ASM implementation is my latest experience implementing a CA SaaS solution (my previous one was with DCIM, a PPM-based solution, but that was a few years ago and more of a hosted service than true SaaS). I want to take this opportunity to share some of my personal observations that apply to any SaaS solution in the enterprise, not just ASM.
I want to make sure to point out that I have no complaints with the ASM development, support, product management, services, sales and pre-sales teams. They all made a herculean effort to ensure the successful implementation of ASM for this customer. The teamwork the CA teams exhibited was incredible. This project truly was a manifestation of the CA DNA.
So, why am I writing this blog? We have a very ambitious (although I think achievable) goal of 50% of our revenue from SaaS in a few short years. This we can only do if we can convince many of our enterprise customers to move to SaaS solutions. And that means that while we understand the enterprise really well, we still can improve how we move the enterprise to the cloud.
So, without further ado, here are my key points and observations about SaaS in the enterprise.
When we write contracts, we are very focused on the technical aspects of the work. However, in SaaS even more than with on-prem work, our customers expect true consultative work. They want us to guide them to making good decisions.
Our approach should not be: “Tell us what you want us to do”. Rather, we need to explain to the customer best practices, how other customers approach the deployment and what the implications are of the decisions they make.
This means that our contracts need extra time for this kind of consultative work. It is quite possible that the actual consultative work takes much more time that the technical work. It may also mean that we need time to create and demonstrate multiple approaches so the customer can see the impact of these approaches and make an informed decision.
Over the years I have frequently been involved with first-time implementations to a large-scale enterprise of solutions we acquired.
In the case of previous ASM implementation, scale was not an issue when other customers deployed on a typical small to medium company size. This enterprise implementationridg was easily 10-15 times larger than the largest previous deployment. And each script showed levels of size and complexity we never encountered before.
What is complexity? Scripts are larger, are more intricate, are more customized, more special cases. Scripts were specific to internal browser versions that may no longer be considered modern or state-of-the-art. Scripts may take advantage of browser functionality that is not commonly used.
The other problem is that the environment may be highly customized and restricted (see issues with security below). In addition, processes may prescribe a level of restrictions we have to work around. Process constraints may be just as rigid as technical constraints and we need to take them equally serious.
In many enterprises, the IT standards are very rigid (much more so than we are used to at CA). Many of the companies I have been working with have their desktop tightly controlled. Installing special software on the desktop to accommodate our SaaS solution requires a lot of special permissions and is not practical for a larger user base.
This holds true especially for browsers. Therefore, it is imperative that our SaaS solution supports a wide variety of browsers. The comment “Just use a different browser” is not an acceptable response. Equally, changing browser settings (for example, for the proxy) is not easily accomplished as these settings may be locked down as well.
If our SaaS solution requires components to be installed within the enterprise (such as for integration with other systems or for data collection), it is critical that these locally-installed components can be hosted on a widely accepted platform. This should include, as a minimum, RedHat Linux and Microsoft Windows Server. Requiring a non-mainstream OS, such as Debian, causes significant problems.
Once a customer deploys any solution, it has to be turned over to Operations. This is a group of people responsible for the continuous operation of the solution. Look at this group as the people that take action when an event occurs. This is often different from administrators, who are responsible for the health and welfare of the solution.
The Operations group will perform routine tasks as the result of an event. That means that routine events and the required action need to be well documented.
The more events Operations can handle, the better. Any events that are outside the Operations cookbook approach to resolution (often called the runbook) have to be escalated to other groups, often leading to delays in response.
That means that CA needs to help the customer by providing a template runbook for routine events and recommended actions. The customer can then customize the actions for their specific operational requirements.
The customer expects full control over security. Both on the level of authentication and authorization. The enterprise customer expects granular, role-based security.
The enterprise security team does not like generic user or account names. They require to have special user accounts to have as little authority as possible. Requiring an “admin” account for our solution causes a lot of problems.
Another aspect of security is that communications into and out of the enterprise are tightly controlled. Firewall and proxy settings may require a lengthy review and approval process.
One challenge is that we must be able to support legacy systems, tools and environments. Legacy may also refer to older, out of support environments.
This is especially an issue with monitoring and similar solutions. The older a legacy solution, the more monitoring is required. Of course, in this case it may be hard to properly interact with the legacy solution.
The enterprise customer expects its applications to interact. In the case of ASM, it was just a starting point. The information is expected to flow through CA APM (Application Performance Management) as a centralized reporting platform on to Netcool to open tickets in the customer’s service desk solution.
This means that the customer needs full access to the data collected in the ASM application downstream.
In a generalized sense, enterprise customers expect to feed data into our SaaS application and expect to have downstream access to the data. Of course, one of the most important integration is LDAP to feed user access and authentication information into our SaaS application. I know we have this for some of our applications, but not all.
Customers expect to have multiple “lower” environments. I know of customers that have a DEV environment for development, a QA environment for testing, a UAT environment for user acceptance testing and, of course, a PROD environment. The rules for promotion from one environment to the next are well established. Detailed change control is required the closer you get to the PROD environment.
The customer expects a comparable setup for their SaaS application. In addition, they expect that configurations can be moved without reentering information from one environment to the next. This is critical to reduce the chance of introducing errors moving the configurations through the environments. Ideally, you have all the tools of DevOps available to manage transition through what the customers call promotion process.
And I think this is a reasonable expectation. We have multiple environments for some of the SaaS products we use, such as Salesforce or Concur.
Any time we make a change to our SaaS platform, there is the chance we introduce errors. This happened frequently with ASM over the last year. And the risk increases exponentially the more customizations and interfaces we or the customer developed.
In order to mitigate any risks, it is important to enable a customer to get a preview of the proposed upgrade with all their customizations and interfaces. I am not proposing to give them veto power over a release. But a couple of weeks should give them time to update their special work to ensure a smooth transition.
We all know that 100% uptime is not a realistic expectation. However, if we do not strive for it, we will fall well short. Unplanned outages should be a rarity, not something that happens several times a year. There should be redundancies built into our SaaS offerings, which reduce the chances for unplanned outages. We should be able to build an environment that allows even updates to the SaaS platform to not require an outage.
Just think of Twitter. Is Twitter really mission critical? Will there be financial harm to the users if there is a planned or unplanned outage to Twitter? Now think of our users. If you are a major financial institution and a Web site goes down unnoticed, that will cause financial and reputational harm to the company. And if our customer relies on our SaaS solution to notify them when they have an outage, our SaaS solution becomes mission critical to our customer.
When there is a planned outage, we need to provide proper notification. This must include
- Impact of outage … is it the whole solution or just a subset?
- Potential work-arounds … how can the customer obtain comparable functionality during the outage.
- Precise timeframe … this should be preferably during non-working hours. Granted, this can be a challenge for a world-wide solution. But at least is should be possible to perform the outage during the weekend. Just see how Salesforce or Medalia handle planed outages.
- Communication plan … as we get closer towards the outage, we need to reinforce the communications. Again, see how Salesforce or Medalia handle planed outages.
So, we all understand that 100% uptime is not a realistic expectation. But if our SaaS solution is down, our customer needs to know right away so they can manually perform the work they are paying CA to do automatically. Having automatic monitoring and escalation in case of an issue end-to-end is critical. So as a backup plan, there must be comprehensive monitoring of the CA SaaS solution and proactive notification of the customer should there be any outage or other problem. This must include any interfaces and customizations.
Let me rephrase this: Any unplanned outage of our SaaS solution is completely unacceptable. However, if it should occur, it is critical that the customer is properly notified.
Of course, replacing an existing solution has the typical challenge of “We want a new solution but it has to work exactly like the previous one”.
However, replacing an on-prem solution with a SaaS solution has the added challenge that the customer team we are working with does not really know themselves how to fit the SaaS concepts into existing processes and procedures. This makes it especially critical that we at CA offer consultative services. Unfortunately, we are still learning ourselves how to best guide a customer to make this transition.
In addition, I have noticed that there are more instances where we work with business teams instead of IT implementing a SaaS solution.
This is a pet peeve of mine and I feel obligate to point this out every opportunity I get. We at CA are a subscriber of Microsoft Office 365. Any time I am in an online Office application I have a consistent look and feel. Upper left gives me access to ALL my online office apps. I know what the sidebar does and how to show or hide it. There is a consistency between all the online versions of the applications. Same with Salesforce. I may be using a third-part plug-in but it still has the salesforce look and feel. For both examples, security is consistent … one login for each of the respective applications.
But then you look at CA solutions. There is just no consistency in user experience between applications. If you are lucky, your solution integrates with SSO. ASM does not. Just look at PPM, Agile Central and ASM (three products I am very familiar with). Who would think they are products from the same company? Looks like a bunch of point solutions. This does not represent the image of an integrated enterprise solution powerhouse.
In summary, a SaaS deployment in the enterprise has a lot of the same challenges a regular deployment has. However, fitting SaaS into an environment that has classically been used to on-prem exasperates many challenges that might otherwise be routine as we are all learning how to best guide our customer in the transition.
So, what are your thoughts? Please let me know by posting a comment below.