Workday: Forget ERP, start over
Ever since businesses first started using computers to automate their operations, they've had to compromise within the limitations of the technology. Each fresh generation of technology has brought some new freedoms, but never as much as its proponents originally hoped. And so every decade or two, the old generation is pushed aside to make way for a promising new contender. Is it now time to for ERP to cede to a new generation?
Workday's argument is that ERP is flawed because its core design is centered around the needs of beancounters. ERP provides all the metrics required to report financials for a business, but it misses out so much more information that the people actually running the business need at their fingertips. "Accounting is a requirement of business, but it's not the reason for doing business," says Workday's recently appointed VP of applications Mark Nittler. "Business is about commerce."
So Workday makes the sweeping claim that its application suite automates the whole of a business, not just the beancounters' view, or any other narrow angle. What's more, for a business with $500 million to $2 billion annual revenues, it expects to do that for an annual subscription fee of around $100k per year. Delivered on-demand, there's no additional license fee and the cost of professional services to tailor the application falls within the relatively low bounds typical of the on-demand environment. It all adds up to a game-changing proposition. Too good to be true?
Workday points out that it has been able to take advantage of next-generation technologies that simply weren't around when ERP was first devised. "Things are different today," says Nittler. "We have the opportunity of a green field." Or as one of Workday's marketing slogans puts it, it's the first new business management solution to come to market "since the Web turned 2.0, Sarbanes met Oxley and the world became flat."
At the core of those new technologies is an object-oriented approach that severs the dependence on SQL database tables at the heart of much of the brittleness of current ERP software. Back in the early 1990s, I worked for a small business owner that wanted to harness the new-found power of SQL query language and 4GL programming languages to build his company's business systems. The company was a PC reseller, so it wanted to manage customers, orders, sales commissions, suppliers. The first step was to decide in advance how to structure the data: there had to be a table called 'orgs' that identified each business the company deal with; and then various tables of the different kinds of business could be joined to the 'orgs' table — suppliers, customers and so on.
At the time, this was a breathtakingly elegant and powerful way to map a business's data. Yet I couldn't help wondering what would happen if some business need came along that required a table you hadn't defined into the original SQL database structure. Surely you were building in a significant hostage to fortune?
Workday's product managers describe this conundrum as the 'challenge of the code block'. Personally, I think they're being kind. I would have used the word 'tyrrany' in place of 'challenge'. They point to the hacks and workarounds that ERP systems have had to turn to when incorporating extra requirements such as security, audit logs and other newly-discovered business needs. Actually, of course, these needs have always existed, but (rather like subprime mortgage risk) they've had to be acknowledged and accepted before they were acted on. The 'code block' is an artefact of the way ERP systems, founded on SQL database systems, are built. There are certain super-entities, such as 'account', 'department', 'region' that are the master-definitions that every other entity has to be defined in relation to. Those choices, once made, cannot be undone; they can only be worked around. While it's true that there are some highly sophisticated workarounds available these days, each one that's added brings further complexity to the system.
The breakthrough that Workday achieves is to move away from a fixed database structure. The SQL database in a traditional business management application defines the meaning of data into the table structure, and that is its achilles' heel. Workday's database tables reflect the needs of the object-oriented application architecture — there are just three tables, for 'instances', attributes' and 'references' — and the data and definitions stored in the table are instantiated only when the application runs. The definitions are therefore as easy to change as the data.
When I use terms like 'instantiated' I'm slipping into the language of object management. At the heart of Workday is an object management server (OMS) — 30,000 lines of Java code that runs as an Apache Tomcat process, entirely in memory. When the Workday application runs, it scoops up all the data and definitions stored in that three-table database and turns them into meaningful data that can be accessed and manipulated. Changing the business logic — even at a very fundamental level — is simply a matter of changing a few definitions and re-running the application. Workday's favorite demonstration of this capability is showing how it's possible to reorganize the structure of your business on the fly, without recoding. In fact, Workday's application developers never write code. They simply work with the 40 or so object types that have been built into the application, and define and instantiate them as required.
Workday talk as if this is all new but it's really just a new way of implementing a vision that's always been there. Back in the days when people wanted mainframes to do more than simply run calculations, they came up with COBOL, a programming language that promised to encapsulate business logic and make business automation effortless. COBOL was elegant for its time, partly because of the way that it mingled application logic with data. But that very strength became a weakness, as later on it became increasingly difficult to extract the data for use in other scenarios the original programmers had failed to imagine. In one sense, Workday goes back to that original vision of co-mingling data and logic, but with the huge advance that, instead of hard-coding the logic, the relationships only come into existence when the application is instantiated into memory. If the logic has to be redefined, then it's simply a matter of rewriting the definition and re-instantiating the revised application back into memory.
Although Workday came into being as a company just a couple of years ago, work on its application started seven years ago, when John Malatesta, formerly the principal architect of PeopleSoft's application tools, decided to use the emerging technologies of the new century to create a hosted financials suite for the midmarket. If anyone is qualified to know what to do if you had to throw out ERP and start again from scratch, it ought to be Malatesta and the team of former Peoplesoft colleagues that has now come together to bring Workday to life. The application architecture certainly has enough depth to it to qualify as a potential new contender. Whether it really provides the flexible business automation that has been the so far never-ending quest of enterprise software, its early customers will be the first to discover.