Architecture is destiny: Why the revolution in business apps can't work on conventional stacks
How do IT architectures at software-as-a-service (SaaS) providers provide significant advantages over traditional enterprise IT architectures?
We answer that "Architecture is Destiny" question by looking 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.
Workday has designed its architecture to provide secure transactions,
wider integrations, and deep analysis off of the same optimized 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
Joining us here is a technology executive from Workday, Petros Dermetzis,
Vice President of Development there, 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 to operate. The discussion is moderated by BriefingsDirect's Dana Gardner, Principal Analyst at Interarbor Solutions.
Here are some excerpts:
Dermetzis: 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
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
enterprise resource planning (ERP) system gave all the solutions, which in reality isn't true.
we tried to do at Workday was start from a completely 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
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.
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.
solutions evolved over time and started adding technology solutions as
problems occurred. 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
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.
way things evolved, you started with an application, and integrations
were an afterthought; they got bolted on. ... They kept 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.
Old approach won't scale
now, the state of the art is hard-wiring 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.
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.
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.
Obviously, [traditional ERP vendors] 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.
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.
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
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
A blast from the past
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
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.
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.
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.
The same treatment
Conversely, 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
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.
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 file 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.
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.
Best way to access data
next architectural benefit 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.
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.
So 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.
do use a relational component, but not as a relational database. We
use a relational database, which is 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.
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 systems 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.
Make way for metadata
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.
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.
also 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.
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.
Listen to the podcast. Find it on iTunes/iPod. Read a full transcript or download a copy.