In just five short years (since its founding in 2005), Workday Inc. has grown to almost 500 employees and 150 customers and has established itself as the leader in enterprise-class Human Resources, Financial, and Payroll solutions delivered via Software-as-a-Service (SaaS) and operating in the cloud. Recently, Workday was named the best business application by the San Francisco Business Times and has also earned a spot as one of the Best Places to Work in the Bay Area for the past three consecutive years.
As Vice President of Development at Workday Inc., Petros Dermetzis manages the company’s Tools and Technology team. His responsibilities encompass the design and development of the technology and tools infrastructure upon which Workday builds and deploys business application services. This includes the core technology platforms that support the core transactional systems, security, product updates, integration, devices and mobility, performance, and user experience behavior of Workday’s solutions.
Workday’s modern standards-based SaaS technology offers a quantum leap in ease-of-use, extensibility, and integration capability compared with legacy systems and has, in no small measure, contributed to the rapid and incredible success of the company.
I spoke with Petros about the drivers behind the evolution of the SaaS model and about how Workday is addressing the customer pain points with SaaS and the cloud. Petros describes the characteristics of a “true” SaaS product and shares valuable insights he has gained from real-world experience in architecting and building a successful on-demand software service.
Here are some excerpts from the conversation:
SandHill.com: What were the driving factors behind the evolution of the SaaS industry for enterprise business applications?
Petros Dermetzis: Well, first off, I think that “evolution” isn’t the right word. SaaS and Cloud computing are transformative shifts in the technology landscape. They change the topology at three critical levels: the infrastructure of enterprise technology, the application layer, and — just as importantly — the user experience.
At the infrastructure level, I have personally experienced three Enterprise IT shifts over the past three decades, starting with mainframes, through to client-server, and finally to the Web. These architectures each got bigger and more complex and I have seen firsthand how companies struggled with their maintenance costs. With each cycle, IT organizations came to the point of saying: “It’s working, leave it alone.” They wouldn’t take fixes or patches because the maintenance and upgrade path was expensive and riddled with unexpected side effects. That in turn impacts the vendors because they can’t easily sell new functionality.
Early business systems were transaction oriented and were designed from the inside out; meaning they were very good for record keeping but not much else. Workflow was added to these systems as an afterthought, again from the inside out, to help make it easier to capture data, not necessarily to facilitate actual work. But coordinating business workflows turned out to be a complicated task because the various systems in a typical IT shop were built on different technology stacks.
We then watched this craze around Service-Oriented-Architecture (SOA) circa 2003 along with the emergence of Web Services and a whole slew of middleware technologies and tools: Websphere, Weblogic, Netweaver, and so on. What they were all trying to do was manage business workflows across disparate systems. This time around they were trying to add workflow from the “outside-in” perspective — applying workflow on top of existing applications.
Next, we saw yet another set of technologies called enterprise portals that were designed to help with management of all this complexity from an end user perspective followed by the last big initiative in the apps layer: the growth of analytics. Traditional relational models that underpin transactional systems were not designed to provide real-time information to business people, much less allow the types of drill-down and drill-around exploration of data that organizations wanted. That problem created a whole new industry called Business Intelligence which included Business Objects, Cognos, Hyperion, and so on.
Ultimately, all this technology and application evolution looks very much like an onion: layers and layers and layers of complexity that costs customers a fortune. The more they peeled back the onion, the more they cried! Customers were spending more and more money, time, and effort not on their own R&D and innovation, but in running and maintaining these inefficient IT systems — systems that were designed for an entirely different set of problems from what they were ultimately being used to solve.
SH.com: How is Workday addressing these customer pain points and where does the on-demand model fit in?
Petros Dermetzis: In 2005, Salesforce.com was already blazing a trail with a successful SaaS business in Customer Relationship Management (CRM).
We took on the task of developing a solution which included helping many mission-critical business applications from the ground-up — rethinking what was traditionally referred to as Enterprise resource planning (ERP) instead of buying companies that had parts of the solution and trying to weave it all together. We weren’t building it for the sake of building it again; we saw the customer pain points that had grown as those layers of technologies piled up in the prior generation of software, along with indications at that time that there was a market for “on-demand” or “Software-as-a-Service” offerings, and thought, “we can do this better.”
Our main premise was that we’d make the biggest impact if we could bring together transactions and analytics in the same place. These are what managers and employees need from the system in order to get work done. Understand that this is a very different starting point from legacy systems, which started out with the premise of more efficiently capturing, storing and processing data — better bookkeeping. We started with a clean slate to build a highly user-oriented, functional system with workflows, transactions, and analytics all tied together cohesively.
Then we asked ourselves how we could take on maintenance and upgrades of these systems ourselves and free our customers to focus on their businesses; this is the model of the consumer Internet, so why not the enterprise? We also wanted to provide seamless upgrades on a 90-day cycle. Why do customers have to wait from 12 months to 18 months to get new features and functions? These were some of the reasons why we started from the ground-up and chose to build using the SaaS model.
SH.com: What characteristics and architecture constitute a “true” SaaS offering? How can customers distinguish between a real and a fake SaaS product?
Petros Dermetzis: I don’t know how you can get the tag of “SaaS” or “cloud” if you don’t have some core concepts and approaches built into your offering. The following are some of the key factors that differentiate true cloud offerings from look-alikes, and why they’re important:
1. Multi-tenancy Multi-tenancy defines a true SaaS product, and it is arguably the most important technology advancement of this current wave. To put it simply, it means that the software vendor has multiple customers running on a single instance of software. This is how Amazon, Google, Salesforce.com, and NetSuite, as well as the other leaders in the Cloud, run their systems. It provides phenomenal economies of scale in terms of the raw infrastructure, but more importantly it focuses the innovation engine within the software company.
At Workday, our development team is focused 100 percent on new capabilities. We’re not supporting patches or connections to obscure “dot-versions” or old code; we’re focused on the future. That means customers get more innovative capabilities faster, it means all our customers are on the best solution we have to offer, and it means that we don’t divert resources to shoring up legacy systems.
One of the biggest areas the old software vendors throw FUD about is data security and data privacy in a multi-tenant environment. Obviously this is something that we thought about from the start, and built carefully as we architected our system. We use a database for persistence (long-term data storage) and the data we persist in the DB is fully encrypted and each customer has their own DB instance, which is isolated from other customer DB instances. Not only did we think about privacy and security, we think about computing resources too. We designed the processes of each tenant such that they do not hog resources from other tenants, which could cause performance or resource-starving problems. Customers should ask any enterprise software vendor about multi-tenancy. They have a right to know if they are getting a modern, state-of-the-art, scalable, extensible multi-tenanted architecture that will serve them well over the next 15-20 years.
2. Personalization, configuration and extensibility Companies almost always have unique organization structures or business processes developed over years of doing business. While it would be nice to have a one-size-fits-all software product, some flexibility is always required. That level of “fitting” a solution to a company used to require custom software code — one of the most costly and burdensome components of legacy software projects.
Instead, we provide a set of pre-configured business processes for customers. More importantly, we’ve taken those business processes and broken them into their component steps and actions. Customers can configure them and change these a million different ways to match their requirements.
There are several levels of this: there is personalization, configuration, and then extensibility. Traditional systems were not easily configurable; they had tools built-in to make such changes but needed expensive system integrators to come and do the “customization”. A true SaaS service should be designed from the ground up to be highly and easily configurable.
Then there is a related concept called extensibility — the ability to add new attributes and fields to the system that is specific to our customers’ industry or business. Some of these we take on, and some customers should add. We have an active community of customers who give us feedback and requests for new features/functions that are common across all customers in which we prioritize, build, and then roll out in the next update.
3. Standard-based integration Traditional systems are built around the transactions, the database, the business logic, and around making the UI look sexier, more interactive, more intuitive, and so on. And for all the integration and migration work, customers often had to buy third party integration tools or use ETL tooling to help them with those integration interactions and loads. The business logic and the architecture have always been built with integration as an afterthought.
Integration is one of the core concepts of Workday — we are designed from the outset to be a hub system for other enterprise applications and to operate, natively, in the cloud. Core to Workday is an Enterprise Service Bus (ESB) that allows us to do all our integrations, transformations, and format conversions. This means we can maintain modern standards within and around Workday while still easily connecting to virtually any legacy application. Workday’s open Web Services stay consistent, so our connectivity to other applications is maintained over time — update after update. This is so obviously fundamental that no one else actually does it!
4. Disaster recovery and backup Every SaaS offering must have a complete disaster recovery (DR) solution in place. DR comes in different flavors. One is for dealing with what I call the “asteroid hit.” You need to have a mirror — a complete copy of systems and data — in an entirely different geographic location. When the asteroid hits one location and takes your data center out, you can immediately bring your systems back online using your mirrored replica from a different location. We have that capability with our offering and we invest heavily for it. The second flavor is to also have redundancy and resilience built-within each data center; so when parts fail (and they do), the system can seamlessly bring stand-by systems online.
SH.com: How does the Total Cost of Ownership (TCO) of SaaS applications compare with the on-premise solutions?
Petros Dermetzis: One of the most fascinating things to consider after 30+ years of enterprise software is how little IT leaders and pundits actually know about the true cost of these systems. We went around to all the analyst firms a couple of years ago and asked them for an analysis of the true cost of on-premise deployments. We got back statements like, “the rule of thumb is four-times license fees, but never use a rule of thumb because it will always cost more.”
So there are three important factors in the total cost of ownership of SaaS vs. on-premise systems:
The first one is that it is just simply cheaper — by as much as 50 percent in some cases — to use a shared infrastructure with the cost advantages of multi-tenancy. The list of things customers don’t have to buy is long: servers, operating systems, databases, etc., as well as all the associated IT operations cost.
The second one is that it is accountable and predictable. Customers can easily assess the true cost of ownership for a SaaS solution in the form of a monthly or annual bill.
Lastly — and this is something that I think the industry is just awakening to — SaaS delivers continually improving functionality and capability while eliminating the cost of upgrades. So customers get more capability and value out of their solution — in the case of Workday, three times a year — and we’ve eliminated one of the biggest downstream costs of on-premise ownership: that upgrade five years down the road that costs as much as the original implementation.
SH.com: Any final thoughts or advice for other vendors on how to successful with the SaaS model?
Petros Dermetzis: My advice to on-premise vendors: Figure out a way to open a company across the street that is independently managed. Challenge them to do all the things we talked about today about starting from scratch. If they don’t start from scratch, there are not going to make it. Don’t try to convert the existing systems and fool yourselves into thinking this is an evolutionary process because you will not be able to match the pace of innovation, much less the cost-efficiencies of your competition in the cloud.
Kamesh Pemmaraju heads cloud research at Sand Hill Group. Follow him on Twitter @kpemmaraju.