“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:
- 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.
- 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.
- 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.
