Concrete Cloud Computing

October 2nd, 2008

In the last entry I wrote a fairly abstract piece trying to define “Cloud computing.” This time, I’ll give a concrete example of what we’re thinking about.

Benefits administration is a headache for HR people, balancing the needs of the employee for great coverage with the needs of the organization to maintain a reasonable cost profile. To make things simpler, organizations often integrate the benefits provider’s online capabilities with their HRMS, eliminating some of the pain associated with keeping employee records accurate.

The tradeoff in the on-premise world is an IT cost — owning and managing the integration. Not only is there IT cost involved initially, any addition or change to that benefits provider requires a new integration. The result: massive upfront planning, an expensive integration and a lot of IT inertia when it comes to making business changes later.

What we can do is take that integration burden and move it up into the cloud. Workday Benefits Network is a good example. It provides a set of pre-built, hosted integrations to well known Healthcare and Financial Benefit providers.Benoit Lheureux of Gartner would call these “Packed Integrating Processes (PIPs) — a form of prebuilt integration.”

This means a couple of very valuable things for the customer.

  1. Workday takes care of electronically updating the Benefit Provider whenever an employee makes a change to their Benefit Plan or chooses another Benefit Provider.
  2. We can offload the integration itself by managing and maintaining it at our datacenter. In fact, it is simple enough that the customer can select from pre-integrated benefits providers in an online list. Point and click integration.

But how is this different from what can be achieved with an On-premise solution?

  1. A customer (or some consulting group) can certainly build a set of integrations to specific benefit providers. But in the on-premise world, that means it is your problem. Upgrades are an IT project and when something breaks, its yours to fix.
  2. It would nice to easily shop around for new Benefit Providers. Well, in the Cloud Computing world where those integration are delivered as a service, this is an easy thing to do — the IT cost of change is eliminated. In the On-premise world where you need to get someone to built those for you, it is a difficult and expensive task.
  3. We publish well defined public APIs to this Benefits Network, so that in theory, any Benefit Provider can plug into this network. This means that new and smaller Benefit Providers, can potentially gain access to new customers. It also means that if there is a particular Benefit Provider that we in Workday don’t support then they can plug in themselves. This is clearly something that is just plain impossible with an on-premise solution.
  4. Finally, it is not hard to imagine as both Workday and the Benefits network evolve, that in the not too distant future there will millions of employees under Workday management and hundreds of Benefits Providers plugged in. Instead of our customers having to build and rebuild the same integrations over and over, we can focus on new innovations. Imagine:
    • Analytics within the company looking at benefits usage patterns to help review what offerings are most used and most important for employees.
    • Analytics (with appropriate opt-ins) for benefits trends within industries

In the Cloud computing world, a whole new set of possibilities emerge.

Cloud Computing isn’t just about changing the technology so that costs and risks of ownership get transferred from the buyer to the provider. In the above example, points 1 and 2 speak clearly to how those costs and risks move from the customer to the vendor but are diminished through aggregation. Cost savings are good, especially in the current economic climate, but they are not transformative. What is transformative about Cloud computing is that it introduces new business model opportunities. Points 3 and 4 above outline how, with the right technology, a whole new business model around Benefit provision can emerge.

– annrai


Cloud Computing

September 4th, 2008
The term “Cloud Computing” is getting a lot of air play these days — it is the computing equivalent of a U.S. Presidential Election.  It has loads of twists and turns, plenty of eager participants, lots of money being spent on it and it gets to consume large amounts of the news cycle…often without a lot of new information.  So what exactly is “Cloud Computing”?  I’m gonna have a crack at answering that question and (as an encore) talk a little about where Workday stands in the whole Cloud Computing debate….

The Wikipedia definition of Cloud Computing provides a mainly technology focused narrative that outlines the core technical elements involved in computing that resides in the cloud — wherever that is!  My definiton is somewhat different.  I’ll propose that Cloud Computing is “the business model opportunities that emerge when applications delivered over the network are open, extensible and interoperable”.

Cloud Computing Taxonomy

Let’s look at what’s out there.

The spectrum of offerings within Cloud Computing starts to the left, with providers of generic capabilities like hosting, moving across to Web-based development platforms and business-specific solutions. It is also useful to think of it as starting with infrastructure and technology and moving through to domain-specific application ecosystems.

The middle of this axis — commonly referred to as Platform-as-a-Service (PaaS) — has attracted a great deal of attention.  Companies like salesforce.com, coghead and bungee are working to create generic application development and deployment platforms.  These are designed to enable 3rd party developers to both build and deploy applications that reside in the cloud.  (Of course applications built for the Salesforce cloud won’t run on the Coghead cloud — and vice versa).

The business models and motivations for companies wanting to offer technologies and solutions at different points in the axis are clearly very different.  However, there are a number of observations that can be made:

  1. While it never lived up to the pre-bubble hype, hosting has become a real business.  Loads of companies are outsourcing some or all of their datacenters.  Even on-demand players look to datacenter specialists to take care of things like power, Internet connectivity and physical security.  It has also driven new standards and efficiencies as we shift from servers and switches being the products to uptime and bandwidth.
  2. For PaaS, there is a lot of historic precedent for the perspective that owning the most popular development platform is a strategic goal in and of itself.  (For those of you old enough to remember it is worth recalling the Steve Ballmer “develper, developer rant“).  You can argue whether Cloud Computing itself is the new platform, or just the infrastructure for PaaS providers.
  3. In the world of domain specific applications, connectivity has become table stakes.  (Salesforce talks to facebook talks to LinkedIn talks to Workday).  Not only it is imperative for these applications to expose APIs and to provide excellent tools for people to manipulate them, the connectivity between applications and services is rapidly moving to point-and-click.  Integrations that used to take a busload of consultants are now delivered more like a google mashup (albeit with enterprise-class security and availability).

It’s About Business

Each of these models and approaches is fundamentally dependent on the existence of the Cloud. I firmly believe that the most important part of Cloud Computing is around the new business models it engenders.  In the same way that Google and others have broken the mold in terms of business models for the Internet, I think that Cloud Computing is going to fundamentally change the rules in the Enterprise Application space — and i think we’re only beginning to understand the changes that are possible.  However, it stands to reason (at least to me), that when you tear down the walls that surround Enterprise Applications and you start making them interoperable and massively extensible, then new and unplanned things are going to happen.

And the encore…

Here at Workday, we are working on some very specific problems we want to solve with Cloud Computing, focused on what our customers need to run their businesses.  Right now, we are making it easy for key third parties such as Healthcare providers and Payroll providers to plug into our applications.  This enables us to create specific business value for our customers — our HR systems just work with their existing payroll and benefits providers.  No big integrations, no patches, no upgrades.  The connection is part of the service.

Over time, our strategy is to expose more and more of our application functionality as Web Services, and we are only just beginning to imagine what a true Cloud-based Enterprise Application can mean in terms of the new business model opportunities it will create.  What’s potentially most exciting, is that as we connect to more applications and expose more of our functionality, the community contributing ideas will expand well beyond our current ecosystem.  That may be the most important new business model of all.

– Annrai


Putting the Focus on People

July 28th, 2008

“So much of what we call management consists in making it difficult for people to work.”

– Peter Drucker

To steal a thought from Mr. Drucker, it seems to me that “So much of what we call ERP consists in making it difficult for people to work”.

Now, some of you out there may say that enterprise software solves complex problems and therefore it must be hard to use in order to accomplish its mission. But as Robert X. Cringely noted in a recent post, big enterprise software companies regularly made their software harder to use than it needs to be.

The core of the issue, to my mind, is the problem the application is designed to solve. The term “Enterprise Resource Planning” (ERP) grew out of the earlier “Manufacturing Resource Planning” (MRP II) and the even earlier (and confusingly abbreviated) Material Requirements Planning (MRP). All these systems were designed to automate the issues encountered in the manufacturing industry. At their heart, these systems are focused on managing the materials, plant, capital and inventory required to deliver products to market. ERP is great for manufacturing companies. But manufacturing companies only employ about 10% of the US workforce. The main type of employment for US workers (as well as for workers around the globe) is in the services sector.

In the last few posts I wrote mainly about the technology that underpins Workday and how that makes us different. Changing tack, it is worthwhile talking a bit about the philosophy that underpins the Workday application suite. Again, we have taken a radically different approach to the ERP vendors. In fact, our take about the business applications that will replace ERP are all centered on one simple thing: people.

The philosophy behind Workday is all around managing the people and the knowledge capital that is at the heart of the services economy.

Naturally, the first part of Workday that we built out was around Human Capital Management. But now as we start to add financial and business management capabilities, they are driven from the point of view of the person rather than the materials or the plant. Our procurement is all about making it easy to provision and manage things like laptops and cell phones and Salesforce.com accounts to people – the tools they need to get work done.

So, the Workday goal is not just to reinvent the technology behind ERP but to reinvent what ERP means. By putting the focus on people rather than things, we hope to help cure some of the problems that Peter Drucker was referring to. We hope to make it easy (or easier) to manage people.

–Annrai


Change Can be a Good Thing

July 3rd, 2008

“If you want to make enemies, try to change something.”

– Woodrow Wilson

So as the resident ERP outsider, I have been fascinated to dig into the whole topic of “change” in the ERP world.

A lot of the debate about “change” in ERP gets focused on the database. For a whole set of very obvious reasons, the relational database, has a crucial role in any business software system. Upon first encountering ERP, many of my smart friends would tell me that that the big source of system complexity is the thousands of database tables. Indeed, a colleague of mine from a very large bank told me they spent $50m a year to keep a global, single instance of a traditional ERP system running. This seems like a lot of money just to manage a few thousand tables!
ERP systems have had a very database-centric application development approach since they were first imagined about 20 years ago. In fact, the ERP design process begins by visualizing how the application will be represented in the database, then moves to how you manage that data, its effective dates, how it is archived and encrypted, etc. In short, ERP development imposes a heavy burden on how applications are developed before you even think about business user functionality. And complex to build means even more complex to change. ERP development cycles have continued to balloon from 18 months to multiple years as vendors (and customers) try to deal with the complexity, much less getting the actual functionality they need. As Jim Gray argued in his excellent paper in 2005, the historical division between code and data has brought us down a technology dead end.
In contrast, the developers who write applications in Workday start at a very different place. Put simply, they start with the people, things and activities that individuals and organizations want to track and manage across the business instead of starting with the underlying data structure. Workday developers essentially deal in application metadata, not in the data itself. There is no way, nor any need for a Workday application developer to even begin to think about how an application will be represented in the database. In fact, developers use the application itself to build the applications. Our developers log onto the system in the exact same way as a customer, they just happen to have an additional permission level that enables them to modify the application meta-data, thus changing the application functionality.
The net result of all this is three things:
  1. It is possible for developers to become enormously productive. We can change the application to modify it or add new functionality very rapidly. Developers just don’t have to worry about any of the complexities such as effective dating, encryption or archiving. It is all done for them.
  2. We can manage that change in a very structured manner. We not only manage the metadata but also all the changes to the metadata. It is therefore easy for us to do an impact analysis to see how a given change will not only effect another application inside the Workday cloud, but also another application that we integrate with.
  3. There is no disconnect between the development world and the deployment world. They are the same thing and as such eliminate huge swaths of traditional R&D which, in the ERP days, was spent on hardware and software support, etc. Workday are not the only people to be shouting about the extraordinary value of this approach to customers and to solution providers. There is a long tradition stretching back from Smalltalk to Ruby that has been pretty vocal on this topic too.

But the bottom line is, how does this really help customers? It means two very important things:

First, we can deliver rapid innovation on the Workday platform in a way that is transparent to customers. They get new capabilities every 90 days simply and easily — no upgrades. Second, they can configure and reconfigure the system based on their business needs and those changes are maintained (as metadata) even as Workday delivers updates to our solutions.

Now change is built in on the customer’s terms. And change, finally, can be a good thing.

–Annrai


ERP: Outside In

July 3rd, 2008

So this is how it starts. Here you have a guy with absolutely no ERP or application experience, co-writing a blog about ERP applications. It’s great!

First off, let me introduce the blog — welcome to A2, the Workday blog co-written by Aneel Bhusri (who does know a thing or two about the applications world) and myself, Annrai O’Toole. I have spent the last 20 years of my professional career exclusively involved in middleware and distributed computing. We’re hoping to use this blog to share a few thoughts (and maybe provoke a few) on the state of the applications industry. We hope these are entertaining and useful. So without further ado, let’s dig in …

We can’t solve problems by using the same kind of thinking we used when we created them.

This quote from Albert Einstein seems an appropriate phrase to get going on. Here at Workday, we are undertaking the substantial task of remaking the ERP world. This may sound audacious, but it seems a fair reflection of what’s going inside the company. Clearly, we are providing an On-Demand solution, which has the large and obvious benefit that our customers don’t have to install our software on their premises. However, if all we end up doing is re-inventing the same old ERP applications with the same old relational database architecture then we’re not really addressing the problem. We don’t simply want to “multi-tenant” an old ERP application. Just doing that we’d just be using old thinking to solve new problems.

So, what are some of these new problems?

  1. No application is an island: The last wave of ERP has proven that. There is just no way any single company can provide all the application functionality you want in one package — no matter how many companies they acquire.
  2. Change is constant: ERP applications need to be better able to respond to that change. Ask any customer of a traditional ERP application and they will attest to the fact that changing them is damn hard. Too damn hard.

For the purpose of this article, I’m just going to take on issue number 1.

Application Networks

Here at Workday we are putting integration technologies in the heart of our application. Want to know exactly what we mean by that? We’ll let’s look at a recent announcement from a brand new customer, Flextronics. There are many reasons why Flextronics chose Workday, probably top of them is that they believed that a partnership with with us would not only be good business but a lot of fun too. However, in the 3rd paragraph of the above article David Smoley talks about one of specific reasons they chose Workday: he tells us it was because of “Integrations”. One of the things that we build with our Integrations is a “Network” of connections to third party applications. In this specific case, it is a set of integrations that we built (and maintain) to healthcare benefit providers such as Blue Cross Blue Shield or United Healthcare.

But step back a second and think about what is going on here. One of the key features for Flextronics is not a feature that we built ourselves — it’s a feature we integrate with. But the great thing from the customer point of view is that they can’t tell the difference. A feature is a feature, whether it exists in “our Cloud” or in someone else’s “Cloud”. When we first joined Workday from Cape Clear, the vision was to blur the line between what’s an “Integration” and what’s an “Application”. This quote from a great customer is testament to how successful we’ve been in making that a reality.

But we’ve only started. One of the profound things that happens when you put integration into the heart of the application architecture is that you start to see things from a very “outside-in” perspective. The traditional ERP worldview is that everything is siloed. HR apps live in one silo, financial apps live in other silo and the integrations are in yet another silo. At Workday, we see all these things as part of a cohesive whole: applications and integrations share the same world; they are the yin and yang of a new application architecture. David Smoley’s remark above tells me that what customers want is not an application island, rather they want an application network. We are now at the point where the underlying technology in Web Services has matured enough where this is a reality. Today in Workday we are delivering over 20 pre-built integrations to 3rd parties in our application network. We believe that this will be closer to 100 within 12 months.

Another key feature we want to offer our customers is a whole new way of integrating between their existing on-premise applications and all the information that lives in the application network. By solving this problem in a new way we can make a massive contribution towards solving the second of the big problems we list above: how to enable constant change, even change on-demand!

However, for that piece of wisdom from the non-ERP guy, you’re going to have to wait for the next installment. Hopefully, this piece was useful and gets you thinking that there is more to On Demand ERP than simply being “multi-tenanted”. To really change ERP, we need to think in a very different way. If you have comments on this, then please join the conversation….

–Annrai