Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: Workday.
Additional resources:
The Real SaaS Manifesto (whitepaper)
Things Large Enterprises Need to Know About SaaS
Strength from the Core: Why Bolted-On BI Doesn't Work for HR
Built-In Business Intelligence
Real Saas
Notes from Workday's Technology Summit
Thanks for joining this sponsored podcast discussion on how IT architectures at software-
as-a-service (SaaS) providers provide significant advantages over traditional enterprise IT architectures.We will look at how one human resources management (HRM), financial management and payroll SaaS provider, Workday, has from the very beginning moved beyond relational databases and distributed architectures that date to the mid-1990s. Instead, Workday has designed its architecture to provide secure transactions, wider integrations, and deep analysis off of the same data source -- all to better serve business needs.
The advantages of these modern services-based architecture can be passed on to the end users -- and across the ecosystem of business process partners -- at significantly lower cost than conventional IT.
I'm here now with a technology executive from Workday to explore how architecting properly provides the means to adapt and extend how businesses need to operate, and not be limited by how IT has operated.
So please join me now in welcoming Petros Dermetzis, Vice President of Development at Workday. Welcome to BriefingsDirect, Petros.
Petros Dermetzis: Hello, Dana. How are you?
Gardner: Very good. What is it that is different about a Workday stack versus a traditional enterprise IT stack?
Dermetzis: The luxury that Workday had at the very beginning was to start with an absolutely
clean slate. Enterprise resource planning (ERP) solutions evolved over time and started adding technology solutions as problems occurred.We have a unique opportunity to stand back and see what history and evolution provided over the past 20 years and say, "Okay, how can we provide one technology stack that starts addressing all those individual problems that started appearing over time?"
Gardner: It sounds as if a SaaS provider like Workday almost has the luxury of working the main architecture problem, rather than working many problems from what was already in place. Tell me about this clean slate. How important is that? How big of an advantage is that?
Climbing a ladder
Dermetzis: It’s a huge advantage. Look at most ERP vendors, for example. They started with a
need to report data and very quickly realized it was like climbing a ladder of hierarchic needs. When you get your basic reporting right, you need to start analyzing data.The technologies at the time, around the relational models, don’t actually address that very well. Then, you find other industries, like business intelligence (BI) vendors, appeared who tried to solve those problems.
What we try to do at Workday is understand holistically what the current problems are today, and say, "This is a golden opportunity." This is opposed to finding all existing technologies, cobbling them all together, and trying to solve the problems exactly the same way.
Is there a totally different innovative approach to addressing those problems?
Gardner: I have to imagine too that the requirements are different. Back when ERP was just coming into the mainstream, it was about just getting a handle on processes. Now, we're at the point of refining and extending processes. It’s a different set of requirements.
Dermetzis: If you go back in time to when mainframes started appearing, it was about transactions, capturing transactions, and safeguarding those transactions. IT was the center of the universe and they called the shots. As it evolved over time, IT began to realize that departments wanted their own solutions. They try to extract the data and take them into areas, such as spreadsheets and what have you, for further analysis.
We want to take it more to an area which is business interactions, and interactions can happen from humans or machines.
Obviously, they were solving the problem incrementally, as they were going along. What we tried to do was address it all in the same place. Where we are right now is what I would describe as very business transaction-centric in what I define as legacy applications. Then, we want to take it more to an area which is business interactions, and interactions can happen from humans or machines.
Gardner: Just for the edification of our listeners, Workday is focused on human resources management (HRM) and other employment-related issues, but also increasingly moving into a larger ERP and the business applications set. The important fact here is that in human resources you need to relate to outside entities. Maybe it’s payroll, maybe it’s insurance or healthcare. This puts you in an interesting position of mastering the integrations, something that’s probably going to become more important with cloud computing and other aspects of business over the coming years.
Dermetzis: That’s correct. If you think of the majority of the systems out there, the way we describe them is that they were built from the ground up as islands. It was really very data centric. The whole idea was that the ERP system gave all the solutions, which in reality isn't true.
If you're managing any system with HRM systems, you need to communicate with other systems, be it for background checks, for providing information to benefit providers, connecting to third-party payrolls, or what have you.
Adopting new standards
Right now, the state of the art is hardwiring most of these central solutions to these third-party solutions, and that basically doesn't scale. That’s where technology kicks in and you have to adopt new open standard and web services standards.
Gardner: Let's drill down a bit into existing legacy architecture. It was the right architecture for the job, but the job has changed. What can be done? As you mentioned earlier, people have incrementally added on over the years more and more. They have a sort of bolt-on mentality. What's wrong with that, and what can be done to move in a new direction?
Dermetzis: I would describe it more like an onion. We keep on adding more and more and more layers of vendors, and the more the poor enterprise IT customers are trying to peel it, the more they start crying -- crying in terms of maintenance and maintenance dollars.
Just to introduce the basic concept of how applications are being built, they are being built with the idea of storing, managing, and safeguarding the transactions.
Applications are built on top of relational databases today, and then they are being designed thinking about the end-user, sitting in front of a browser, interacting with the system. But, really they were designed around capturing the transaction and being able to report straight-off that transaction.
However, all the business logic, all the security, and the whole data structure that hangs together, is known by the application and not by the database.
The idea of integrating with third parties was an afterthought. Being an afterthought, what happened was that you find this new industry emerging, which is around extract, transform and load (ETL) tools and integration tools. It was a realization that we have to coexist within the many systems.
What happened was that they bolted on these integration third-party systems straight onto the database. That sounds very good. However, all the business logic, all the security, and the whole data structure that hangs together is known by the application -- and not by the database. When you bolt-on an integration technology on the side, you lose all that. You have to recreate it in the third-party technology.
Similarly, when it comes to reporting, relational technology does a phenomenal job with the use of SQL and producing reports, which I will define as two-dimensional reports, for producing lists, matrix reports, and summary reports. But, eventually, as business evolves, you need to analyze data and you have to create this idea of dimensionality. Well, yet another industry was created -- and it was bolted back onto the database level, which is the [BI] analytics, and this created cubes.
In fact, what they used were object-oriented technologies and in-memory solutions for reasons of performance to be able to analyze data. This is currently the state of the art.
Gardner: And this is fairly expensive. When you have to buy the bolt-on, you have to manage the integrations yourselves. You have to troubleshoot where it's going to break and where it's brittle. Then, of course, you have to add what you can for security and maintenance over time to keep up that needed level of security. We're talking about some significant cost.
Why don't we address that? Why is this bolt-on approach not just problematic technologically, but also very expensive?
Things are never stable
Dermetzis: That’s absolutely true. In fact, if you think about it, you can actually buy something. You can buy an older application, a legacy application and you can bolt-these integrations and analytics components onto it. You can get it up and running, and everyone is happy.
But then, things are never stable. Vendors update things, change things. They upgrade, they apply fixes and patches, change their data models. And what you have done is, in effect, you have alienated and broken these third-party bolt-ons.
IT shops have hundreds and hundreds of integrations hanging over this all. And, the times comes when they don't want to accept anything, not even a bug fix from a vendor, because they know they're going to break their integrations. That’s just maintainability, and that’s just dollars and dollars and dollars that you need to spend to maintain things.
And you can't get new functionality, new innovative solutions, because as soon as you go back and start changing things downstream, well ... the costs are huge.
Gardner: So, with Workday, or any SaaS provider that’s architecting for the future, you're able to address some of these issues for your architecture, but you're also able to add new technology based on the architecture, not as an adjunct or an additional bolt-on product.
The reality around ERP systems is actually making all this work together.
This is happening behind the scenes. You're able to improve your security, keep up any patches that you need to do, while at the same time increasing the frequency through which these end users can enjoy these improvements.
So, we've got, I think, two benefits here. One is the initial architecture, and two is the fact that you're managing all that maintenance. Please tell me why these two aspects are important and what you did to make it improved over the past systems.
Dermetzis: The way things evolved, you started with an application, and integrations were an afterthought; they got bolted on. Analytics was an afterthought, and that got bolted on.
What we tried to do at Workday was start from a complete white sheet of paper. The reality around ERP systems is actually making all this work together. You want your transactions, you want your validations, you want to secure your data, and at the same time you want access to that data and to be able to analyze it. So, that’s the problem we set out to do.
What drove our technology architecture was first, we have a very simple mentality. You have a central system that stores transactions, and you make sure that it's safe, secure, encrypted, and all these great words. At the same time, we appreciate that systems, as well as humans, interact with this central transactional system. So we treat them not as an afterthought, but as equal citizens.
Additional resources:
The Real SaaS Manifesto (whitepaper)
Things Large Enterprises Need to Know About SaaS
Strength from the Core: Why Bolted-On BI Doesn't Work for HR
Built-In Business Intelligence
Real Saas
Notes from Workday's Technology Summit
Any request that comes into our system, be it from a UI or from a third-party system by integrations, we treat exactly the same way. They go through exactly the same functional application security. It knows exactly what the structure of your object model is. It gets evaluated exactly the same way and then it serves back the answer. So that fundamental principle solves most of our integration problems.
On the integration side, we just work off open standards. The only way that you can talk with a third-party system with Workday is through web services, and those services are contracts that we spec to the outside world. We may change things internally, but that’s our problem.
We're a SaaS vendor, and we do modify things and we add things, but those external contracts, which are the Web services talking to third-party systems, we respect and we don’t change. So, in effect, we do not break the integrations.
The next one is about analyzing data. As I said, there are a lot of technologies out there that do a very good job at lists and matrix reporting. Eventually, most of these things end up in spreadsheets, where people do further analysis.
But the dream that we are aiming for continuously is: when you are looking at a screen, you see a number. That number could be an accumulation of counts that you'd be really interested in clicking on and finding out what those counts are -- name of applicants, name of positions, number of assets that you have. Or, it's an accumulation. You look at the balance sheet. You look at the big number. You want to click and figure out what comprises that number.
To do that, you have to have that analytical component and your transactional component all in the same place. You can't afford what I call I/Os. It's a huge penalty to go back and forth through a relational database on a disk. So, that forces you to bring everything into memory, because people expect to click something and within earth time get a response.
The technology solutions that we opted for was this totally in-memory object model that allows us to do the basic embedded analytics, taking action on everything you see on the screen.
When you are traversing, you come to a number in a balance sheet, and as you're drilling around, what you are really doing in effect is traversing an object model underneath, and you should be able to get that for nothing.
The technology solutions that we opted for was this totally in-memory object model that allows us to do the basic embedded analytics, taking action on everything you see on the screen.
Gardner: And that common approach with the juxtaposition of the logic and the data also allows you to update your system without worrying about all of those bolted-on aspects breaking, which gets us back to that ability to update, refresh, and deliver new benefits fairly rapidly.
One code line
Dermetzis: That’s absolutely true as well. As soon as you can have the luxury of maintaining one system, let's call it one code line, and you're hanging our customers, our tenants, off that one single code line, it allows you to do very, very frequent upgrades or updates or new releases, if you wish, to that central code line, because you only have to maintain one thing.
And, there is another bit of technology that you add to that. We're a totally metadata-driven technology stack. Right now, we put out what we describe as updates three times a year. You put new applications, new features, and new innovations into the hands of your customers, and being in only one central place, we get immediate feedback on the usage, which we can enhance. And, we just keep on going on and keep on adding and adding more and more and more.
This is something that was an absolute luxury in your legacy stack, to take a complete release. You have to live through all the breakages that we mentioned before around integrations and the analytical component.
Gardner: Could you explain about that persistence layer? You started to get into it a bit with the metadata. Explain that a bit more in more detail if you would.
Dermetzis: The persistence layer is really forced by the analytical components. When you're analyzing information, it has to perform extremely fast. You only have one option, and that is memory. So, you have to bring everything up in-memory.
What you used to use in legacy system was putting things on tape for safety and archiving reasons. We use disk, and we actually believe, if you look at the future, that nearly everything will be done exclusively in-memory.
We do use a relational component, but not as a relational database. We use a relational database, which is what it’s really good at securing your data, encrypting your data, backing up your data, restoring it, replicating it, and all these great utilities the database gives you, but we don’t use a relational model. We use an object model, which is all in-memory.
But, you need to store things somewhere. In fact, we have a belief at Workday that the disk, which is more the relational component, is the future tape. What you used to use in legacy system was putting things on tape for safety and archiving reasons. We use disk, and we actually believe, if you look at the future, that nearly everything will be done exclusively in-memory.
Gardner: So, the architecture is destiny and we can see the architecture is shifting. I wonder about if I'm an enterprise IT individual. I really understand the architecture, and I enjoy your position of being able to do it the right way from your vantage point. But I can’t, as this IT leader. I have other restrictions. I have this large installed base that I need to maintain. How is it that these can coexist? How is it that a SaaS provider like Workday integrates to enterprise XYZ with a lot of legacy ERP? What’s the connection point there?
Dermetzis: The main connections that you have with systems are when you want to start creating applications or sharing information from other systems. As I mentioned before, when it comes to integrations, the only way you talk to Workday is via web services.
We still have systems that require a flat file, a comma-delimited file, that we need to send to them. That’s the point where we have a technology around our enterprise service plus our integration server that actually talks the language that we do, standards web service based. At the same time, it's able to transform any bit of that information to whatever the receiving component wants, whether it’s banking, the various formats, or whatever is out there.
We put the technology into the hands of our customers to be able to ratchet down the latest technology to whatever other files structures that they currently have. We provide that to our customers, so they can connect them to the card-scanning systems, security systems, badging systems, or even their own financial systems that they may have in house.
Gardner: I suppose the point there is that you're forward-compatible, based on our earlier discussion points about being able to move to the future, bring in new technologies, and keep up-to-date with security and other best practices, but you are also backward-compatible, based on your architecture for integration.
Straightforward approach
Dermetzis: That’s correct. In fact, it's the beauty of working with forward-thinking companies. I'll use an example of Salesforce.com. Our integration with Salesforce is totally web services talking to web services -- straightforward. We have a contract called web service. They have a similar contract. It just works, whatever we do or whatever they do. We don’t break each other.
It’s a whole different conversation, when you are trying to integrate some of our payroll output into one of our customers who has an SAP financial system. So, we are going to have to ratchet that down all the way to whatever file format that party vendor has. But we can do it, and we have the technology to put it in the hands of our customers.
Gardner: The architecture you've been describing at Workday not only benefits the end users, not only provides the forward- and backward-compatibility, but you have also architected for your own business model, I assume, which involves the need for multi-tenancy. You want to provide the lowest cost services for your own business model, but that I suppose also has architectural benefits. Tell me how the architecture relates to multi-tenancy and why that’s important for you as an organization.
Dermetzis: Multi-tenancy is one of the core ingredients, if you want to become a SaaS vendor. Now, I'm not an advocate of saying multi-tenancy A is better than multi-tenancy B. There are different ways you can solve the multi-tenancy problems. You can do it at the database level, the application level, or the hardware level. There’s no right or wrong one. The main difference is, what does it cost?
All we're looking at is one single code line that we have to maintain and secure continuously.
We believe in one single code line, and multiple tenants are sharing that single code line. That reduces all our efforts around revving it and updating it. That does result in cost savings for the vendor, in other words, ourselves.
And as far back as I can remember, when humans realized that you take time and material, package that for a profit, and send it to your end-market, as soon as you can reduce your cost of the time or the material, you can either pocket the difference, or move that cost saving onto your customers.
We believe that multi-tenancy is one of the key ingredients of reducing the cost of maintenance that we have internally. At the same time, it allows us to rev new innovative applications out to the market very quickly, get feedback for it, and pass that cost savings on to our customers, which then they can take that and invest in whatever they do -- making carpets, yogurt, or electric motors.
Gardner: This architectural approach, with its benefits around analytics, integration, the single source code, and the multi-tenancy values, the ability to adapt quickly and pass those updates along without disruption, all points to almost a revolution in how IT is conducted.
What does that mean for organizations that don’t take the plunge, whether they do this on their own architectures or they start to use more of the outside providers? It almost sounds like there is going to be a sort of a haves or have-nots split in the market in terms of how people adapt to these new IT economics?
Dermetzis: We're living through, or we're creating a revolution in the ERP industry. As always, you have early adopters. At the other end of the bell-shaped curve, you've got the laggards. When you're talking to forward thinking, modern thinking, profit-oriented, innovative companies, they very quickly appreciate that the way to go is SaaS.
Security questions
Now, they've got a bunch of questions, and most of the questions are around security -- "Is my data safe?" We have a huge variety of ways of assuring our customers that these are actually probably safer in our environment than on premise.
Some customers wait, and some will just jump in the pool with everyone else. We are in our fifth year of existence, and it’s very interesting to see how our customers are scaling from the small, lower end, to huge companies and corporations that are running on Workday.
Gardner: What can we look to in the future? If we go back to that future-proofing benefit, the architecture that you are using, the benefits and value that you are able to pass along in terms of functional improvements, more rapidly adopted, and these economic benefits, what’s next?
Is there a benefit to going into the mobile tier? Are there benefits of adopting other source applications, cloud computing or third-party ecosystems? By doing this architecture properly, what can we expect as new trends in IT and business unfold?
Dermetzis: The thing that moves incredibly fast in the market is where humans interact. If you think way back when, there were green screens, and then we moved to client server, where everything was based on a Windows-based machine. Then, you move into the Internet, so you are actually touching more and more and more users. Right now, I think the next revolution is around mobile devices.
The trick here is how you can provide similar functionality that you have on a browser-based system onto the devices very simply and quickly.
There are two types of users normally in an enterprise. First, are the users who are the administrative users, the HR partners, the procurement clerks, everyone who actually needs the back-end system, and there’s one way to address that. They normally sit in front of their computers and browsers most of the day.
Then, you have the other population, the real population of a company, which is the operational side. They don’t even care if they have a back-end ERP system. Where the future there is that they will interact with the back-end, without even knowing it’s there, via mobile devices.
The trick here is how you can provide similar functionality that you have on a browser-based system onto the devices very simply and quickly. By the way, the device world is changing continuously. The interaction that you get from an iPhone is very different than what you will get from an Android, or what you will get from a BlackBerry. So that comes back to the vendor. The way you should be architecting your product should be end-user or end-device agnostic, as much as possible.
That’s where the future is. For devices that come out of Apple, you have to go native, because people expect a certain user behavior. The better job we do there, they don’t even have to care if Workday is on the back-end. They can do their expenses, their time reporting, and their approvals.
The other devices, which are more browser-based, require something more like an HTML technology to be able to provide the solutions for those devices. So, your back-end technology must be able to be versatile enough to keep up with that growing device evolution that’s going on right now.
Gardner: So it sounds like we are back to that conundrum of the onion, where we have got yet another layer now, managing how the mobile tier and various devices within that mobile environment relate back to the logic and the data. For IT, this is not a minor, trivial issue, but a SaaS provider is going to work this through. They have to, and they probably are well on their way to doing it.
Back to technology
Dermetzis: That’s exactly right. It comes back to technology, again. What we have on the back-end, the way we build our business logic, the business logic is agnostic. If the request comes in from a user or a system, the people who actually build the business logic themselves have got no control over what it looks like.
Now, what does that mean? From a technology point of view, they focus on the business logic and the validation in that behavior, and the tool will take care of rendering it on a browser or on a mobile device.
So, today, we're an Adobe Flex-based front end browser. Tomorrow it’s Silverlight, HTML5, whatever it is. The way you architect your product, you should be able to always be on the latest and greatest technology out there, without having to rewrite your application.
Gardner: Well, great. I am afraid we will have to leave it there. We've been discussing the advantages of modern services architecture and how those benefits can be passed on to users and extend both in terms of forwards compatibility and also legacy or backwards compatibility. We've been comparing and contrasting this to what a lot of enterprises have as a vestige of the 1990s in terms of their IT.
I want to thank our guest. We've been talking about this with Petros Dermetzis, Vice President of Development at Workday. Thank you, Petros.
Dermetzis: Dana, thank you for your time.
Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.
Additional resources:
The Real SaaS Manifesto (whitepaper)
Things Large Enterprises Need to Know About SaaS
Strength from the Core: Why Bolted-On BI Doesn't Work for HR
Built-In Business Intelligence
Real Saas
Notes from Workday's Technology Summit
Transcript of a sponsored BriefingsDirect podcast on moving beyond relational databases and relying on services-based architectures. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.
You may also be interested in:
