Workday: Forget ERP, start over

Workday: Forget ERP, start over

Summary: Every decade or two, the old generation of enterprise software 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 believes so.


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 logoWorkday, which today launches its on-demand Financials suite, believes it's time for ERP to ride off into the sunset. Its case has found encouragement in recent weeks from Cynthia Rettig's MIT Sloan Management Review article, Trouble with Enterprise Software, which fellow-ZDNet bloggers Dennis Howlett (The ERP mess we're in) and Joe McKendrick (Another view: Don't expect SOA to fix ERP quagmire) have both commented on.

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.

Topics: Apps, Enterprise Software

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Workday may be a good name

    They may last a little bit longer than that, but since many people have been saying since the early 1990s that OODBMS would replace RDBMS "real soon now" and no OODBMS vendor has ever gained any significant market share whatsoever, it is hard to see what is different about Workday in this context.

    Of course SQL-DBMSs are not inflexible at all, making changes is easy, it's changing all the application code sitting on top of it that is hard. There are steps you can take to ease this pain but going OO is not one of them (often quite the opposite in fact).
    • WorkDay is not a DBMS vendor "OO" or otherwise

      Workday is a SaaS (Software as a service) player, like (in the cloud). It would seem that part of there overall architecture falls under the category of NoSQL (just like that other non DBMS vendor (Google)). I can only imagine that their NoSQL component links to a SQL based tool, since their earliest job adds were for people who were fluent in MySQL (now owned by Oracle since their aquisition of Sun Microsystems (JAVA) back in 2005).
      As for PICK (Currently knows as OpenInsight), it is alive and well and under the covers of some of the most widely used software in the world, which I am sure is being used by 99.99999999% of the folks reading this article.
  • Anyone hear of PICK?

    The very same Problems the ERP faces was addressed back in the 1960's by Richard PICK. Multi Value database LEND themselves to being "tweaked" on the fly without affecting the underlying business logic.

    Perhaps it's time to "Go Back" top the future ?
    • Yes, and I am not convinced

      Multivalue, like other hierarchical approaches (among which I would include OODBMS) make it easy to access the data in certain application specific ways and very hard when you need to access the data in some unanticipated way.

      The one thing PICK had going for it was no distinction between variables in the database and variables in the programming language. There is no reason why this principle couldn't be extended to the relational model, thereby overcoming a lot of the supposed problems of inflexibility (which actually exist in the applications rather than in the DBMS).
    • The problem with PICK...

      and it's modern day equivalents of UniData and UniVerse, both owned by IBM, is that the database engine doesn't enforce those pesky little rules like data typing. To the database, a field is a field. It doesn't care if you try to plug someone's name into a quantity field. Sure, you can enforce data typing rules in your application, but what happens when someone else writes code that directly accesses the database without going through already written business logic? Because the database engine leaves all, and I do mean all, thinking to the application code the database is able to "outperform" most relational database management systems. As always though, there is a high price that comes with this performance. I've always thought that multi value databases were a good fit for XML, but not for anything that requires any kind of data integrity.
      • Thankyou

        I have no direct experience with Pick, I've only read about it, but this sounds like another very good reason for not resurrecting it.
      • Nobody else gets to write the code

        In the tech world of PeopleSoft (where Workday's progenitors come from), the PeopleSoft platform had to be agnostic. It had to be able to run on all of the major RDBMS vendor's platforms. Thus, data integrity, ect. was left to PeopleTools (the component processor.....running on an application server). In an off-premises Saas operation, you don't have to worry about running on multiple platforms, but you do have to take care of data integrity and their architects know how to do that. Nobody outside their core of developers codes their applications.
  • Use ERP but move on!

    I have already passed comment on ERP in Dennis Howlett?s excellent article (The ERP mess we?re in). Yes a costly mess but treated as a general ledger to keep the "bean counters" happy it does a job. Use your ERP investment but move on to build applications where it matters in the arena where People create information. I have followed Workday and whilst they undoubtedly have a smarter offering are they really moving on to offer business what they need? I do not think that is clear, as promoting a financial suite is hardly an operational business issue where the new imperative lies.

    What I have seen is not dissimilar in technology terms except the objects are oriented around work/task types ? there are only 10 work types needed to cover any business eventuality (including the user interface). Like Workday and all contained in memory in a data centric environment and includes today?s essentials such rules, workflow state and calculation engines and can build any application which just requires business knowledge to build by business analysts.

    At the application level there is no such thing as ?enterprise software? ? it is not how people work who are the source of all information and work individually or collectively (and now with external collaboration) in relatively small teams to achieve their goals. This is where the focus now lies ? quicker cheaper more agile applications that the business specifies how to run their business. Financial suites are recording history and do not need the same characteristics?

    What is for sure at last the old ways of inflexible boxed apps or unreliable ?tyranny? of block coding is coming to an end.
    David Chassels
    • Please point me to where the theoretical background can be found

      "What I have seen is not dissimilar in technology terms except the objects are oriented around work/task types ? there are only 10 work types needed to cover any business eventuality (including the user interface). "

      I assume you can support this assertion?

      And what is "block coding" by the way and why is it "tyrannous"?
      • Work/task types

        In fact we have used at sometime up to 13 but in reality most covered by use of less than 10. The fact is the deeper you go surprisingly the less "work" objects which become "generic" - if you step up it is inevitably going to take you to function objects which restricts flexibility. So what are these work tasks? Actually very simple too simple for IT to retain complexity and all business driven. In each case they are represented by buttons on a Graphical Designer that when added to a process - make the process of designer?s choice.

        A normal task
        A form task (web form)
        A calculation task
        A program task
        A pending task
        An event task
        A report task
        An import/export task
        A finish task
        A sub process task to a process (where libraries of frequently used function processes can be built up for re-use)

        Then link tasks true and false with rules capability

        Each has a tile to open and insert required information and it works - yes it may sound unbelievable but it true - no "code building" or compiling and driven by business analysts dispensing with the "tyranny" of over the wall to coders....Proven and with surprising results.

        Search my name see for yourself in my writings that have been published.
        David Chassels
  • Is Workday truly SaaS?

    I have been watching Workday over the past couple of months and I think they have a very exciting proposition in a rather staid 2 horse game (SAP and Oracle, Ok 3 if you want to count in Microsoft.

    But looking at their their cost model or even their website I get don't get the feel of a SaaS player they way I get when I see others like or even a much smaller player in the same HR space as Workday, Smiles ERM (

    Is it possible that the folks at Workday have not yet shaken their on-premise ERP baggage completely.
  • I'm a little skeptical

    So there are three tables, of which all the data is loaded into memory? Hmm, do these tables increase in size? I've seen one other OODMS and it worked well...for a while. IMHO the major move will be to application/data blocks that get stacked, racked, and packed. It would allow dynamic business rule isolation and synchronization.
  • PICK does not have to be resurrected. It never died

    If you use computers (you must if you are reading this), then you most likely use products everyday, which were constructed with the OpenInsight toolkit. They are in every corporation on earth. Don't worry about the "3 tables". That's a red herring. As for their business model, it's well thought out and beautifully executed. I only wish I could get a job at the company.