Transcript of a sponsored BriefingsDirect podcast on moving beyond relational databases and relying on services-based architectures.

1. Architecture is Destiny: Why the Revolution in Business
Interactions Can't Work on Conventional Databases
Transcript of a sponsored BriefingsDirect podcast on moving beyond relational databases and
relying on services-based architectures.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor:
Workday
Dana Gardner: Hi. This is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're
listening to BriefingsDirect.
Thanks for joining this sponsored podcast discussion on how IT architectures for
software-as-a-service (SaaS) providers offer significant advantages over
traditional enterprise IT architectures.
We will look at how one SaaS provider, Workday, has from the very beginning
moved beyond relational databases and distributed architectures that date to the mid-1990s.
Instead, to better accommodate business needs, Workday has designed its architecture to provide
secure transactions, wider integrations, and deep analysis off of the same data source.
The advantages of the modern services architecture can be passed on to the end users and across
the ecosystem of business process partners and all 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, but not be increasingly
limited by how IT has operated.
So please join me now in welcoming Petros Dermetzis. He is the 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.

2. 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
problem, rather than working many problems, those being 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, appearing who try to solve those problems.
What we try to do at Workday is understand holistically what the current problems are today, and
saying, "This is a golden opportunity," as opposed to find all existing technologies, cobble them
all together, and try 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.
Obviously, they were solving the problem incrementally, as they are 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 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

3. 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 which are 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 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 today, 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.
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
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

4. 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, another industry was
created and it was bolted back onto the database level, which is the 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 that 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 have you, and immediately, although you
are doing that to the central application, you, in effect, have alienated and broken these third-
party bolt-ons.
IT shops have hundreds and hundreds of integrations hanging over this thing. 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, 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 product.

5. 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 transaction, 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.
The same treatment
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, 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.

6. 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.
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.
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.

7. 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. 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 iFile 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 forwards 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 backwards 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. 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.

8. Gardner: The architecture you've been describing at Workday not only benefits the end users,
not only provides the forwards and backwards 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?
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. All we're looking at is one single code
line that we have to maintain and secure continuously. 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.

9. 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.
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
backend 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 backend ERP system. Where the future there is that
they will interact with the backend, without even knowing it’s there, via mobile devices.
The trick here is, how can you 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.

10. 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 a 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. He is the 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.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor:
Workday

11. 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:
• Delivering Data Analytics Through Workday SaaS ERP Applications Empowers Business
Managers at Actual Decision Points
• HCM SaaS Provider Workday's Advanced Architecture Brings New Business Agility
Benefits to Enterprises
• Workday's Aneel Bhusri on Advancement of SaaS and Cloud Models for Improved ERP