Decoupling data semantics from applications for agility

Image: Stan Swete Stan Swete of Workday discusses how the company enables agility in organizational and business process changes.

Interview conducted by Vinod Baya

Stan Swete is the chief technology officer at Workday and is responsible for overall technology strategy, direction, and execution.

Swete spent 10 years with PeopleSoft in key leadership roles. Most recently he headed the products and technology organization, which included more than 4,000 employees. He was also manager of tools development, general manager of the financial applications, and general manager of customer relationship management (CRM). Swete was responsible for the initial release of PeopleSoft’s Internet architecture.

In this interview, Swete shares how Workday is building flexibility in the next generation of enterprise applications by decoupling applications from the data structures in the relational database. He also describes the origins of the business intelligence industry and the benefits of built-in business intelligence.

PwC: Can you tell us a little bit about Workday?

SS: Workday is a three-and-a-half-year-old startup. We’re trying to build what we consider to be the next generation or an alternative to current ERP [enterprise resource planning] solutions. We think an alternative is needed because of some of the rigidity, complexity, and cost of ownership of current enterprise systems. We’re taking a clean-slate approach in three different ways: creating a new business model that includes SaaS [Software as a Service]; leveraging new technology; and writing applications from the ground up to make new core enterprise applications available.

PwC: You advocate agility as a value proposition of your solution. Can you please define agility and how it relates to your customers?

SS: Agility is an ability to change when you have to. So the two high-level things that need changing—either because of growth or a strategy change—are your organization and your internal business processes. Agility is the ability to do that just as quickly as your strategy changes or if growth changes your business.

PwC: How do your products allow your customers to be agile?

SS: Workday provides the enterprise core. We want to be an organization’s main system of record for people, organizations, projects, financial results, etc.—that’s what we mean when we say core. We put a lot of effort into making sure that the systems we deliver are not only feature rich but also are flexible. There are very good examples of that in human capital management, and it starts with people in organizations. We’ve done a lot of work to really give flexibility to how you can map your organizations. For example, we have a supervisory structure as well as a cost center structure. We also have more ad hoc organizations, and you can model your people in all these ways and translate between all these ways for rolling up both people and costs. There’s a certain bit of flexibility just right there.

Second, we make it very easy to change those structures, and I think that’s unique to Workday. If companies are constantly organizing and reorganizing, one aspect of enterprise systems that’s too rigid is the inability to restructure an organization quickly in the system. Say you change from a line of business to functional areas; many companies seem to be constantly oscillating between those things. We’ll make it easy to do that kind of a change and not have you waiting weeks for your systems to catch up to you. Organizational change is a key area where we’ve put in the flexibility.

We do the same thing with business processes. We deliver predefined business processes, but we also deliver a tool that allows customers—without coding—to configure changes to the business process so that they can make the process fit their organization. As the process changes over time, they can add steps into a process, take steps out, change routing rules, and change approval structures.

Both of these things—how you change organizations and how you change business processes—are done by configuring the service we deliver. You don’t have to hire a programmer or call a Workday consultant to do that. It’s just another business transaction to change the organization structure or the business process.

PwC: How is what you are doing at Workday different from what you developed before? What technical leaps are you making?

SS: Part of it is the technology, and part of it is how the product is written. I think we’ve put a lot more thought into how we’re going to monitor organizations at the product level, but the technology is different, too. We’re replacing what I’ll just term client/server technology. To me, client/server technology is simplistically but accurately represented as millions of lines of code having a complex SQL conversation with a complex relational structure that generally has thousands of tables in it. The applications that are built on that complexity gain a certain amount of rigidity in both business process and organization. It’s difficult to split a supervisory organization in an enterprise software company. You have to handle all the restructuring that might entail at both the application logic layer and the database layer, and then typically you have a separate security structure that you need to update.

That is not agile. With Workday when you restructure, it’s done without coding or database restructuring, and all the security aspects are tied into the change you make. It’s not like you just push a button, but you can manage the process more quickly.

PwC: How do you deal with the link to the database now? Is it different?

SS: We take a very different approach to the use of a database. At the base of Workday is a relational database, but it’s not used in the classically relational sense. It’s an unchanging schema that is used just to persist the metadata definitions we have, the changes to them, and then the changes to the application data. No developer ever thinks of the structure of that database. They don’t code to it, and when we make changes to the metadata structures, those changes are made at the logic layer above that.

The database really is there just to persist changes to the application data. We have divorced all the logic into an object model that is a part of our logic layer, and we’re able to perform operations on that object model, such as restructuring and organization structure. When those changes are made to that model, a set of updates stream down to the database, but no database restructuring occurs.
That’s very different from client/server. We’ve really decoupled the database’s role in giving any kind of data model to the application. The data model is held and encapsulated with the application logic.

PwC: Does such a decoupling allow you to use the data that you store in multiple ways, giving more flexibility in what functionality you can add without disruption?

SS: Actually, what gives you the flexibility is the encapsulation of the data with the logic that manages it. I think a big part of the client/server problem is that you not only have these complex logic and database layers, but different applications are able to integrate directly to both. That just locks everything up. If you want to make a change that’s fundamental to those things, you’re blocked off from making the change.

Our developers think about applications as an object model. There’s a class structure, and classes have relationships to other classes. The developer does not need to map to any other kind of a structure. It’s persisted independently of how we actually turn transactions into SQL updates. That’s all done in the tools.

So, when you change a relationship to point from one class to another class, you are changing a bit of metadata. That change is not linked to some corresponding, underlying table structure. When you make that change in the metadata layer, we’re able to update the system without a data restructuring. We can do changes as business transactions rather than coding exercises and database restructurings, and that leads to massive improvements in agility for the customers and in speed of development for us.

PwC: How should your customers think of enterprise applications in enabling change?

SS: You want to make sure your applications enable you to pursue necessary changes and not get in your way. Today, applications get high marks for consistency and reliability and low marks for allowing you to change when you have to. That’s the problem we’re working on. We’re trying to make it so that the decision about whether you change is a business decision, not an issue of can you afford to change your applications. Right now the applications play too prevalent a role in saying we’re not going to make that change because we couldn’t afford to change the app. That needs to
be eliminated.

PwC: What role does a Software-as-a-Service [SaaS] model play in agility? Are there benefits because of the different delivery model vis-à-vis on-premises software?

SS: I think SaaS on its own doesn’t make you any more flexible than anyone else. It’s all about what you deliver. SaaS gives you the benefit of the right people doing the right work. It is unusual to think about writing an application, selling it to someone, and then having them maintain it. That’s one of the real logical things about SaaS. You let the people who write the application do all the upgrading and patching and everything else. The other benefit is better cost of ownership for both the customer and the SaaS vendor. The lower TCO for customers is discussed frequently. But there are savings on the vendor side as well. We spend a lot less time having to document, explain, and debug our install, patch, and upgrade processes for our customers. These kinds of things consume a lot of time and effort for vendors of on-premises solutions.

In addition to these primary benefits, I think SaaS can be an enabler of flexibility when it comes to integration, but there’s a bit of a story to tell there. I think we’re on a journey toward more interoperable applications, and the first step on that journey is embracing SOA [service-oriented architecture].

If you and I are application providers who both commit to SOA, integration between our applications will happen more easily, but that integration won’t necessarily deliver more flexibility to customers. Now, if you and I are also both SaaS vendors, you start to get flexibility. We can work to support and, if necessary, refine the integration completely in the cloud and without the concern of the impact on the customer’s environment. If one or both of us produces an on-premises solution, we lose control of the ability to manage the integration (and manage changes to it)—and the customer loses flexibility. The combination of SOA design and SaaS deployment should really raise the interoperability of future applications.

PwC: One of the value propositions you promote is the integration of business intelligence [BI] into your applications. What value does that create?

SS: It’s yet another thing that we feel the previous generation of enterprise systems didn’t get right. The data models for these systems were built to do a specific kind of reporting. In HR, it was regulatory reporting for the human capital management specialist who had to get out all these government-required reports. Financial systems were built to produce required financial reports. So you build a data model that allows you to produce those reports, and you gather transactions that feed the data model. There’s nothing wrong with that, except that the kinds of reporting you can produce tend to be limited. These systems aren’t able to produce a lot of basic business operations reporting—the things managers might want to know. I would claim that building ERPs for back-office reporting needs helped create the business intelligence industry. Basically, BI vendors said, “Let’s try to extract the data and massage it in a way that makes sense to an operational manager.”

As we look at building new applications, we think there’s an opportunity to do a much better job of producing basic information out of systems in a way that not only accomplishes the regulatory reporting, but also helps the manager a little bit more. A constant design goal for our systems is to make sure that we’re not constrained to a specific data model. For example, we have an HR system, but it also understands cost centers and the cost center hierarchy. So you get your head count reporting and cost rollups how you want them and synced up.

We try to have a lot of information around that’s relevant to people who aren’t just back-office HR folks. Our philosophy is if you do a good job of generally collecting all the information that comes from the business events that happen, then you can be an HR system that does HR regulatory reporting, but you also can provide a richer set of reports to managers who care about people movement and things like that.

We think that should be built in. When it comes to BI, if the data for the report you’re envisioning is managed primarily by the transaction system, then the transaction system ought to render it, and you should not need a third-party tool that reports on data that’s generated solely by you. Third-party tools are really for aggregation and more sophisticated analysis or consolidation. You absolutely have to have them for that, but there’s no reason transaction systems can’t become more intelligent. Built-in business intelligence is a big differentiator that we talk about.

PwC: You have had a role in creating both the on-premises generation of solutions and the SaaS generation of solutions. What are some of the challenges that you had to overcome? Did you have to unlearn some old habits?

SS: There has been a constant effort of relearning or unlearning here. I mentioned that our technology is less reliant on relational databases. We have to continually emphasize to developers that all data access happens via Web services accessing our business logic and not via direct database access. We need to unlearn other things from our ex-ERP lives.

Another example is in the area of user interface design. As ex-ERP folks we have a good understanding of the underlying complexity of the applications we build. That’s fine, but we’re too inclined to demonstrate this understanding by dumping all that complexity out in front of users instead of buffering them from it. This is another bad habit that we have to fight constantly here.