This periodic discussion and dissection of IT infrastructure related news and events, with a panel of industry analysts and guests, comes to you with the help of our charter sponsor, Active Endpoints, maker of the ActiveVOS, visual orchestration system. We also come to you through the support of TIBCO Software.

We are going to look at open source in the context of economics, complexity, competition, and the disruption of the shifting business models in software, away from traditional per-processor licenses, to the pay-as-you-go and ongoing support and maintenance models.

The major question we want to answer is, does using open-source software pay off in a total sense, compared to commercial offerings? Furthermore, how will this change over the coming several years?

Here to help us dig into the changing world of IT and how open source fits into all of that are our analyst guests this week. We're joined by Tony Baer, senior analyst at Ovum. Hey, Tony.

Gardner: Great. Let's dig right in. JP, let's start with you. You mentioned in a past show that you detected some downside to free open source and open-source software, particularly in the implementation in the real world. I wonder if you could take the opportunity now to fill out what it is about open source that, from your perspective, provides risk.

Short-term thinking

Morgenthal: Sure, Dana. The issue, as I've been following it, is one of unexpected consequences. I don't believe we're accounting for more of the short-term thinking that has placed us in the situation we're in now in the United States or even probably worldwide, and less of the long-term thinking about how things impact everything else.

For the record, so that I don't end up Slashdot fodder, let me say that I believe that open source and noncommercial licensing is a good thing and has been very positive for the industry as a whole.

My concern is for the proliferation of free software, that is, the commercial software that businesses use without paying any license and, optionally, only have to pay maintenance for to run their business. They earn their profit using that software to run their business, and yet nothing is given back to the software industry.

In my opinion, it's like a flower that's not getting fed through its roots, and eventually that flower will wither and die. To me, it’s almost parasitic, in that there are good parasites and bad parasites. Right now, it's proving itself to be a little bit on the good parasite side, but with a slight permutation, this thing can turn around and kill the host.

Gardner: So, your concern is that there might be short-term gain, but in the long term, without a good commercial, viable, vibrant commercial software market and industry, innovation and ultimately the capabilities of software will deteriorate.

Morgenthal: Exactly.

Gardner: Let’s take that over to Jim Kobielus. Jim, you've been tracking software for many years. Do you share concerns that commercial industry will wither and die as a result of open source?

Kobielus: I have to respectfully disagree with JP on that. What's important is to sustain innovation in the software world, and open source has accelerated innovation. The whole open-source phenomenon across all market segments, where open source has invaded parasitically, has stepped up competition, stepped up innovation, and expanded the range of options for enterprise customers -- options in terms of software components to address a broader range of requirements.

Also, there's a broader range of options for the buyer in terms of how they can acquire this functionality through open-source or commercial licenses, appliances, cloud, and so forth.

So, it's been a good parasite. I agree with JP, though, that the issue is that the open-source phenomenon is causing a hollowing out of all the traditional software solution providers' business models. It's causing a deconstruction and a destruction of formerly viable companies all across the board.

What's happening though is that as more organizations license open-source programs, and with or without premium maintenance, a lot of the understanding of the guts of this software is now migrating to the user organizations. The user themselves understand the guts of these open-source packages, as well or better than the vendors who are supporting them. So, the expertise in software is being privatized out to both the IT groups within enterprises and also out to the world of open-source devotees.

So, innovation is going like gangbusters, but the business model of being a pure software vendor based on pure commercial licensing is dying out.

It seems like just at the time we are concerned that enterprises won't be buying software commercially and therefore reducing the innovation in the field, they might, at the same time, be going to outside hosts that can, in fact, really focus on the software combination of commercial and open source and offer services, rather than software. How do these two things fit together?

Baer: I was just running down a couple of things during Jim's response and during what JP was talking about with the hollowing out. In terms of dealing with the cloud, it’s part of a larger trend toward commoditizing -- I'm going to sound very redundant here -- the commodity aspects of the software market.

Part of this is, "I'm not necessarily in the business of trying to provide myself, as a business, unlimited computing capacity. Therefore, I'll rely on the cloud for that." The other side of the coin is that, in general, there's been a commoditization as a result of several factors.

Part of it is open source, but you have to take into context what's been going on in this decade. There was a popping of the IT bubble back around the 2000-2001 time frame. It's been called dot-com, but it also happened the same time that everybody got finished with their Y2K work. At that time IT could no longer just demand infinite pay rates.

That happened along with the globalization of IT, where we had offshore, which provided much cheaper alternative. SaaS, with its subscription model, changed the business model for software companies. Forget about open source for a moment. Just consider the fact that subscription was a major disruption to any existing software company whose business model was predicated on licenses.

Cloud is just one of many commoditizing factors. I just concluded a study for Ovum on application lifecycle management (ALM) tools and looked at which tools seemed to be best suited for the cloud. The fact is, and I will say the same thing with regard to open source, certain areas are better suited for the cloud and certain areas are better suited for open source than others.

In terms of just ALM, I found that collaborative tools are well suited, whereas tools that required lots of maintenance of intellectual property, such as coding, you really didn't see in the cloud. There's a new Mozilla project that just came out, but that doesn't necessarily disprove the theory.

With regard to open source, I agree with Jim that it has hollowed out the enterprise software market. On the other hand, where open source has made its maximal impact is in areas that are commodity, for example open operating systems. Where Unix was supposed to be open, Linux made it very open.

Look at content management. Unless your content management is part of an enterprise middleware platform, chances are you're using open-source content management. Anything that does not require extensive domain expertise is fair game for open source.

Gardner: Let's go to Miko. Miko, we're hearing that the enterprise software business is hollowed out. The last time I looked, some of the major players in enterprise software were holding up quite well. They're actually growing in the last quarter of recorded earnings and results, even though there is a recession. You're at a software company that's commercially viable and is happy to sell software. What gives? Is open source really hurting the big vendors like Software AG?

The power of complexity

Matsumura: Well, Software AG is characterized as being a medium-sized vendor. We just crossed $1 billion in revenue, and we're growing at a pretty healthy clip.

There's a thing that's interesting from our side. You mentioned a real interesting word, complexity. Complexity is a really powerful force in the economy and in enterprise software in general. One of the things that open source is doing is helping to simplify some of the infrastructural components and to decrease the overall condition of heterogeneity.

As people contract from the downturn, they start buying other companies and this creates heterogeneity in the local enterprise. It's what people in complexity theory would call a hold-on. Then, the notion that there is complexity within that local domain is just the function of consolidation. As soon as you start to see economic expansion, then you start to see more heterogeneity in terms of things like business process and the opportunity to capture information.

Sure, there is commoditization in the IT platform, which is advanced by open source. Contrary to what JP was saying, one of the great things about open source is that it forces IT organizations like Software AG to selectively pick where they make their investment. They will put their investments in at the leading edge of complexity, as opposed to where things have slowed down and are not changing quite as fast.

Gardner: Paul Fremantle, you've seen this progression. We've seen a lot of use of open source earlier on with Linux and Apache Web Server, and it's progressed into databases, middleware, and SOA infrastructure. Do you see this as a progression, and how far does open-source software move up the stack before it does what JP fears, which is to undercut a commercial software marketplace?

Fremantle: This is a really interesting subject and it's something I think about a lot, obviously, running an open-source company. One of our main questions is, how many people will pay us for what they use of our technology that we spend a lot of money and effort writing?

There's a change in the marketplace, if you look back to the traditional open-source model. A traditional open-source model is to come along with something that doesn't exist in open-source and costs a lot. Build an open-source version of it. Be the first of a kind. Therefore, everyone who wants an open-source version downloads your software, uses it, and you get a very small monetization out of that.

It was typical in early open-source projects like MySQL and so forth to have incredibly small percentages of people paying you for that software, but to have such a large volume that it still worked out.

That's not how I see the open-source model moving. What I see is what you might call "managed commoditization." In a way we've had commoditization of all sorts of things. No one pays money for the TCP/IP stack. That's a piece of open-source software that has now become ubiquitous. It's not of interest to anyone. It's just a commodity that's free.

It comes with every operating system and it works. I don't think we need innovation in that space. Yes, there were some companies that were trying to make money out of TCP/IP stacks 20 years ago, and those companies aren't making money out of it. That's tough luck. They have to find something more interesting today.

Interesting and innovative

My experience with customers is that, if you do something interesting and innovative, whether you are open source or not, if you partner with your customers and really add value, then they will pay you, whether or not your license forces them.

The license is a blunt instrument. It's a blunt way of getting people to pay you for stuff you've written. To me, that's something that was abused by software companies for many years. What open source is doing is sorting the wheat from the chaff. It's sorting out, is this something that is a commodity that I don't want to pay for, or is this something that has real value and is innovative, and that I need the support, the subscription, and the help of this company to help me implement?

Gardner: Okay, Richard Seibt. Now, we've heard from some of the analysts the fear that innovation will suffer because of open source, and we have heard from some commercial software people that say, "We'll be happy to go to that bleeding edge of where the complexity is. We'll add value there and we will be able to charge appropriately for it." You are an innovator at the board level in several software companies. Isn't the ability to innovate also quite rich within startups that are focused on an open-source model?

Seibt: It's absolutely true that open-source companies are very innovative. If you look at SaaS or even cloud computing, there are many startups that probably lead the way. For open source, we look at that market from a customer perspective. They use the software because of its innovation, its quality, and its cost, and they wouldn't use it for any other reason. It is the innovation, quality, and cost.

I agree with some of the people who talked before. Open source is moving up the stack and has reached the SOA level. For example, large corporations are using open-source SOA frameworks, because they want to be fully independent from any vendor. They trust themselves to develop this piece of software together with the bigger community, which becomes a community of enterprises.

Therefore, innovation is not only from startups, but it's from large corporations, as well. They jump on the wagon and start to involve themselves in open-source projects, especially as being part of the Eclipse Foundation.

Seibt: Yes, it's absolutely right. This is a perfect example. The CIO of Deutsche Post mentioned, when he opened the conference, that large software vendors and the IT system integration companies can't help them anymore, because they don't understand their business as they should. Therefore, they have to do much more from a software development perspective on themselves. They have now joined many logistic companies and are doing a joint effort as part of the Eclipse Foundation, and this is the project, Swordfish.

Gardner: David A. Kelly, we heard that innovation could or couldn't be positively or negatively impacted -- business models also. What gives? What's going on now?

It seems that a lot of the reasons for open source was to prevent lock-in or overly powerful pricing in the market by commercial vendors. In a sense, that's been mitigated, but now we are in a recession where cost becomes even more important. We're also looking at this idea of increasingly having applications and services acquired as a service.

Does that mean that we are now looking at not so much being concerned about lock-in at the code level, but perhaps lock-in at the service-provider level? We also saw this week the announcement of an Open Cloud Manifesto, still rather loose in terms of its details, but which purports to try to keep the cloud from being another abstraction of lock-in.

The most efficient will win

Kelly: I'm not sure that cloud computing necessarily opens up the field for open-source computing. To some extent, it almost shuts it down, because it then becomes cloud as a series of application programming interfaces (APIs) or a series of standardized connections or services out there that could be supported by anything. Open source is one solution. The one that's going to win is going to be the most efficient one, rather than the lowest cost one, which may or may not be open source.

To some extent, as you look at cloud computing, some of the initiative that we saw with original open-source roll out over the past ten years has been almost mitigated from my perspective. The original open-source roll out leveled the table as you said. It mitigated that price difference in terms of the traditional, proprietary software vendors and software models.

It said, "Okay, maybe there isn't as much value in some of that software, whether its TCP/IP software, basic operating system functions, or Web servers, as the large software companies are suggesting there is." That really did help enormously on innovation, but it takes the lower 10 percent or 20 percent of the software infrastructure off the table.

My question really is how far the open-source innovation can go. As organizations move into business processes and business-driven value, all the executives that I talk to don't want to focus on the lower-level infrastructure. They want to focus on what value this software is giving to me as a company in terms of supporting my business processes. They're not allowing me to compete more effectively. They don't want to be in the software-development business, for the most part.

So, how far can open source go up that stack to the business process to support custom applications, or is it always going to be this kind of really lower-level infrastructure component? That's the question that I think about.

Gardner: We'll take that to JP Morgenthal. You've heard a little bit of the back and forth. Dave Kelly's point is that the new era of competition is at the business-process and API level, regardless of how it's supported. We would assume that organizations, be they Amazon, Google, Yahoo, or Microsoft, will be providing services, but with economics in mind, and they might be utilizing open source as best they can. We know that Google, Amazon, and Yahoo already do.

Is that right? Are we talking about a dead horse here? Do we not really need to be concerned about open source, but focus more at the API and business-process level?

Morgenthal: Dave is absolutely correct with regard to the cloud. The cloud actually hides a whole other layer of the "what and the how" from the user and the consumer, which could work in favor of open source or it could work against open source. Nobody really cares. As long as that thing works, it's reliable, and can be proven reliable, it can be put together with chewing gum and toothpicks and no one would know the difference.

Gardner: Well, wouldn't that really be a good thing for open source?

Morgenthal: In what way?

Gardner: Well, if people could choose between free software, were building a data center, had the skills on hand, and knew what their requirements were for the cloud infrastructure, they'd be able to do that and probably focus on the open-source alternative.

Coming full circle

Morgenthal: Again, it takes us full circle back to my initial premise, this concept of free software. There's no such thing as free software. What I see happening is this belief that software should be free. It's actually penetrating the market on many levels. I see that there is a whole concept outside of IT people, who actually understand what it takes to deliver.

Let's take Twitter, for example. What does it take to deliver Twitter infrastructurally, as that thing begins to grow? An IT person understands about scalability and billing, pub-sub engines that have to pump out a single message from a hub to 20,000 spokes, which equate to followers. The amount of infrastructure required to make that happen grows daily.

Not to mention that, there's no plan behind it for monetization right now. It's completely venture backed. It has built this huge community, and it could go away tomorrow, leaving a complete vacuum. There is no free lunch. The value of software, and software delivered as a service, extends this even further and diminishes in the eyes of the consumer, when they don't have to pay for something.

Anytime you have a model where something is given away for free, and, at some point, the free stops, it's very difficult to monetize going forth, because every buy is a buyer's remorse. "I could have had that for free."

Today, it happens very easily with software, because it's intangible. We have vendor lock-in in a lot of other industries. If you drive a Toyota, there are proprietary parts in there. The auto parts market didn't say, "Hey, with your oil change, we'll replace all these proprietary parts for you, because we don't want vendor lock in." Your vacuum cleaner has a proprietary bag. A market didn't pop up that says, "Hey, if you let us service your vacuum cleaner, we'll give you a lifetime supply of vacuum bags free."

Gardner: Isn't software different? Software is published. Software is code. Software is something you can change, if you have the permission. It's not the same as a physical part or a wheel?

Morgenthal: Well, a product is a product. Now, you're going on to the edge of the industry that wants to say, "This isn't something I can touch. It's not real, so it doesn't deserve the same protection at the same level of credibility in the marketplace. It's not something that I can physically touch and feel."

I'm not placing judgment on that. Maybe that's the case, or maybe it's not. I'm just pointing out what you said is the opinion a lot of people in the marketplace have, which is, because it's not tangible, because I can't touch it, it doesn't deserve the same level of respect.

What's going to happen with e-books versus physical books? I can't go into Borders and steal a book. Hey, should I pass around that PDF? I can't go into Borders and steal a CD, but hey, can I give that MP3 to my friend? We feel a change in the market.

My only point here is economically long-term, I don't believe anybody has thought about where these changes stop and what they end up cannibalizing. Maybe we end up with a great market, and maybe we don't. I'd just love to see some attention paid to detail before people just willy-nilly go do these things. What is the long-term impact here?

Looking at risk

Gardner: JP brings up an interesting issue. It's about risk. If I go down a fully open-source path as an enterprise or as a service provider, is that going to lead me into a high-risk situation, where I can't get support and innovation? Is it less risky to go in a commercial direction? Perhaps, the best alternative is a hedged approach, where there is a hybrid, where I go commercial with some products and I go open source with others, and I have more choice over time.

Let's go back to Miko. Miko, is that the way the world is shaping up, that we are going to have a hybrid? We're going to have a hybrid of commercial and open source? We are also going to have a hybrid of on-premises and as-a-service or cloud base. Does that make sense?

Matsumura: Absolutely. Frankly, we're already beginning to hybridize. Even with customers who are acquiring our technology, our technology takes advantage of a lot of open-source technologies, and we have built components. As I said, we're very selective about how we choose to make our investments.

We're investing in areas that obviously are not as commoditized, just because a rolling stone doesn't gather any moss. The big sections of the market, where things have cooled off a lot, where open source can kind of create pavement, is somewhat irreversible.

What makes me hopeful for the industry is in, once again, turning to the notion of the fractal component model. Imagine a fractal image. You've got the major portions in the operating system. That whole thing has been commoditized. The thing that's unique is that while a fractal image occupies a finite amount of volume, which you could see as kind of a market share, it has an infinite surface area. As you diversify, the forces of consolidation are mirrored by the forces of competition.

Our customers need to be able to successfully compete in the market, not just on the basis of lowering the cost of operations through free stuff, but really to be able to differentiate themselves and pull away from the pack. There is always going to be a leading edge of competitive capability through technology. Companies that don't invest in that are going to be left behind in an uptick.

Gardner: Suffice it to say that we are really still in the early stages of IT and that there is always going to be for the foreseeable future a great deal of innovation and change, and therefore a growing pie for those companies that are at that adoption edge.

Let's go to Paul Fremantle. Paul, if what we are describing is accepted as the premise -- that we're going to have hybrids of commercial and open source and that we're going to have hybrids of self-supported, on-premises IT functionality, as well as service acquired -- it seems to me that the real differentiator for enterprises is how well you choose.

It's how well you decide. Should you stay with commercial? What should go with open source? What should you keep on-premises, and what should you go to a cloud for? How are those decisions being made now and how should they be made?

Opportunity for frameworks

Fremantle: It's not just how you choose, but what framework you apply to that. There is an opportunity here to build frameworks that really scale out.

For example, you may have an internal cloud based on Eucalyptus and an external cloud based on Amazon. You can scale seamlessly between those two, and you can scale up within your internal cloud till you hit that point. Open-source software offers a more flexible approach to that.

I just want to come back to something about the use of the term "free software." Most open-source software is not free. If you want the same things that you get from a proprietary vendor -- which is support, bug fixes, patches, service packs, those kind of things -- then you pay for them, just as you do with a proprietary vendor. The difference is in the partnerships that you have with that company.

What a lot of this has missed is the partnership you have in an open-source project is not just about code. It's about the roadmap. It's about sharing user stories more openly. It's about sharing the development plan more openly. It's a whole ecosystem of partnership, which is very different from that which you have with a standard commercial vendor.

Gardner: Let's go back to Tony Baer. As we think about what choices to make in terms of how we provision and acquire technology, we might consider a lower risk in terms of what Paul was describing, in being a member of a community of development, rather than just as a customer of technology. How do you view that?

Baer: First, I do agree with Paul, but I want to make a careful differentiation here, which is, there is a difference between an open source, if I am consuming the software and being an active member of the community or being a customer who is basically buying commodity software.

A good example of that is the difference between the Red Hat Enterprise Linux base and the Fedora base. The Red Hat Enterprise Linux customer base is not looking to get on the latest bleeding edge distros or anything like that. They want stable, supported software. They'll pay for that, and there is a viable business model for that as commodity software.

If you're in the Fedora base, that's where you want to be. That's where basically you don't have a life, you work at 3 a.m., and you're working on trying to improve the distro or trying to mess around with it.

Therefore, in terms of the level of risk, if I'm a commercial customer, I'm going to want software that is essentially release supported. I'll want to lower my risk. Where I'm willing to take risks is the same as I would do with normal commercial software. I'll take, let's say, an early beta release or take some of the community technology previews and I'll have some of my developers work with it in a sandbox. So, I don't think it really changes that equation at all.

I agree with Paul and I disagree with JP. I don't think that open source will be the death of the commercial software market, because the other thing that open source requires to be viable is skill. You need enough of a developer base, enough of a community, to innovate the software. Otherwise, the whole model crashes down.

By definition, what that will not include will be software that is not commodity. It may be, as I said before, where that requires domain knowledge or where there is a huge cost of switching.

I don't think you're going to see any enterprise customers pull out their SAP systems tomorrow for an open-source equivalent. That's just not going to happen. On the other hand, they might move their SAP systems to Linux instead of Unix. So, you need to take this whole question about risk in context.

Monetizing in a different way

Gardner: Jim Kobielus, we're talking about how code, intellectual property, and research and development get developed, monetized, and then brought back into a market. We have these powerful cloud providers, and they monetize in an entirely different way. They sell advertising, subscription services, or retail goods and have a margin. They can monetize their infrastructure in another way.

If they use open source and contribute back to the community, then in fact we have a richer monetization ecology of how software is developed. How do you view that? Look at Yahoo and Hadoop, as an example, where a MapReduce technology has been brought to the open-source environment because it was cultivated at a company that makes money from advertising. [UPDATE: Amazon gets on the MapReduce bandwagen.]

Kobielus: That's a very interesting observation, Dana. Basically, everything you said is exactly right. The whole cloud community, the public cloud provider, is attempting to build their business models based on subscription revenues. It's not so much from advertising. It's the monthly charge for access to the Google or the Amazon cloud. To a great degree, many of them are relying on various open-source components to build up their infrastructure.

To the degree that the cloud providers are active participants in open-source communities and essentially contributing their personnel's time to further develop and extend open-source software that's then available for free, essentially that is the whole open-source community being funded or subsidized by the cloud community.

In many ways, the cloud community, as it grows and establishes itself as a viable business model, will increasingly be funding and subsidizing various open-source efforts that we probably haven't even put on the drawing board yet. That will be in a lot of areas, such as possibly an open-source distribution of a shared-nothing, massively parallel processing, data warehousing platform for example. Things like that are absolutely critical for the ongoing development of a scale for cloud architecture.

If there is going to be a truly universal cloud, there is going to have to be a truly universal open-source scale-out of software.

Gardner: Let me pause you there. Let's take that to Richard Seibt. Richard, you mentioned that it's a very rich and fertile way for software to get developed when a large enterprise like Deutsche Post does work and then contributes it back to the community. Wouldn't the same be the case for large cloud providers, such as Yahoo, Amazon, and Google?

Lack of contributions

Seibt: I think it would help, but I don't believe that they want to do that. They see themselves as a kind of proprietary open-source development shops, and, as you know, they don't contribute back a lot.

But, from a large enterprise perspective, it would absolutely make sense to do a lot of contributions, to be able to move their application and their complex infrastructure to the cloud, because you have to solve cloud security, cloud storage, and cloud systems management, and this is not available yet. This needs to be developed to solve their issues. This is possible in a cooperation between open-source projects or commercial open-source companies and large enterprises, and I am sure they will do it, because they get the value out of it.

As one of my colleagues just said, it's about how you work together, and this is the value of open source. You have influence on the roadmap. You have influence to get what you need, and this makes you agile and more flexible. At the end of the day, software is too important, because all of your business is running on software. Every part is running on software, and that's the reason people want to use software that is open and can be influenced. It's not only about cost.

Morgenthal: Dana, do I get one counterpoint, since somebody said that they don't agree with JP that it's going to be the death of the commercial vendors. I never said that. I just want to clarify. I never claimed that it was the death of commercial. I think you summarized it well with the risk factor. All I pointed out is that there is a long-term risk potential here that nobody is talking about.

One of the rationales that was theorized for that was that Sun has a great deal of open-source software that could be used to create a cloud, an on-premises cloud infrastructure of some sort. That could for IBM be an opportunity to enter that market more quickly, or it could be an opportunity for IBM to stop development in that direction in order to preserve its own ideas about how a private cloud might be constructed -- perhaps of a System Z mainframe platform.

So what do you think JP? Is this whole potential for an on-premises cloud market a new battleground for commercial versus open source?

Morgenthal: I see it more as breathing new life into platforms that were getting harder and harder to justify, because you had commoditization. Commoditization is a real market thing that we've got to deal with. We've had commoditization in hardware to the point where it is relatively inexpensive to get very powerful server architectures, and that reduces the need for some of the larger processing machines that are offered by the likes of IBM and Sun.

So for them, it's being able to target some of this existing investment into a new direction, to build some sort of coherence around how this makes sense to a buy-side community, in building out this compute infrastructure that is easily oriented towards different applications and different uses, allowing for scalable demand, taking advantage of things that they've already built and never really had a model for selling. It actually puts the ball back into their court where its been taken away for them for so long.

Gardner: Okay. So, from your vantage point, the notion of an on-premises cloud infrastructure is great news for commercial providers.

Morgenthal: I think so.

Gardner: David Kelly, how do you see it? Do you see that the open-source versus commercial risk continuum is now being placed at this on-premises cloud market that's just only very nascent? It's really not even off the ground. How do you see that tension?

Services not hardware

Kelly: Just talking about the IBM-Sun deal is great for a services company, which is where IBM is making a huge amount of money -- services. They don't care so much about the hardware anymore. This plays right into the direction that they want to go, because open source is all about the services. There is no revenue in the upfront. So, there is opportunity there.

I don't know how fast that market, in terms of on-premises cloud, is going to develop. That's where my hesitation would be. But, it makes sense from that shifting traditional software model that was pushed off the cliff perhaps 10 years ago by this kind of change that we are seeing across the economy. But, organizations still need services. They need the software. We're just going to be paying for the services and the software as we go forward.

Kobielus: I want to add a quick comment here. In terms of the risk for software vendors from the whole cloud phenomenon, the issue on business models is, what is the razor and what are the blades in the old Gillette model? Well, the razor and blades used to be just the commercial software licenses themselves, and then primarily the razor has always been the maintenance and support service, as well.

Open source has made that the dominant revenue model for a growing range of software vendors. But now, professional services are, in many ways in this new world, becoming the blades.

Professional services are now able to deploy like a global services organization to help customers put together their private clouds, leverage all the SOA and the virtualization technologies, and to really pour deep business domain content into building custom services. That's becoming, in many ways, the blades in this new world. The risk factor for vendors is that we don't have that.

Gardner: Hold on, Jim. If that's the case, what about these external cloud services, where the APIs and the business process are the differentiator? The blades and the razors are really about not professional services involved with creating the infrastructure, but with, how you leverage these business processes in innovative new ways across markets, across ecologies of participants, cutting your IT costs while improving your ability to develop products without upfront capital and without professional services.

Isn't there another side to this, which is the shift from the concern about creating infrastructure into, how do I leverage someone else's infrastructure?

Kobielus: It comes down to either you, as a vendor, bring your professional services to bear on integrating all of that, or you bring your partner ecosystem in to handle that integration and tweak those business processes. So, in many ways, you rely on your partner ecosystem to build the blades.

Gardner: Miko, let's take this to you. It seems to me that if you're building complex event-processing infrastructures and you're creating fabrics of SOA support, you might want to create the enticement of the business-process benefits, while at the same time, monetizing around the infrastructure. Is that a viable go-to market in this new year?

Matsumura: Absolutely. The areas that you describe are the areas where the stones are rolling and there is not a lot of moss. If you look at the rolling stone gathering no moss theory, IBM services would be the moss, in a way. They are just trying to grow over anything that's kind of stabilized and cooled off sufficiently to build their own ecosystems.

The 'uncommons'

It's the thing that I see happening with the Sun acquisition. It's kind of funny. Sun actually had a lot of fairly speculative ventures in different kinds of models for leadership, standards, and open source -- things like JCP, NetBeans, these hybridized models and complexities. The thing I think IBM is trying to prove with this acquisition is basically that professional services are the way that they provide what I would call the "uncommons."

One of the things that I've seen as a pattern in open source is that open source tends to be driven by the needs of the commons, in the sense that the more community, the more common infrastructure, one has, the more you can drive towards an open-source model.

The remaining question for commercial providers is, where are the uncommons? What are the forces that drive organizations to differentiate? Where can you find those differentiation points? The IBM answer to that is, pour in a bunch of consultants. There is plenty of room for other models.

Kobielus: The uncommons is actually the solution provider's ongoing relationship with the customer, the ongoing engagements whereby the solution provider has the expertise to solve the customer's problems and continues to bring that expertise to bear in engagement after engagement after engagement. That is the lock-in. You know your customer better than any other potential provider.

Baer: It's all about relationships.

Kobielus: Yeah, relationships.

Gardner: Paul Fremantle, how about that last word on relationships versus code? You were talking about the community. Isn't that, in effect, a different kind of relationship, perhaps even a lower risk relationship member of a community than simply a buyer from a large seller?

Fremantle: I hate to use jargon, but if you look at where the free and open-source business model is going, if you were going to have a 2.0 business model, it would be all about relationships, and no longer about just being the only open-source project in a space and then everyone jumping on it.

The community is the key to that. The key to using open source to be more powerful than a proprietary model is completely about building a community in which your customers participate. At WSO2, we have some amazing customers, who really participate in the roadmap of the products, in helping out other customers, in working together and building a shared community. That is what's powerful, and that's what's much harder to do as a proprietary vendor. You own the source code, and that ownership is kind of a weapon against your customers. In open-source models, that isn't true.

Gardner: We'll have to leave it there. We're out of time. I want to thank our panel. I also want to thank our charter sponsor for the BriefingsDirect Analyst Insights Edition Podcast series, and that's Active Endpoints, maker of the ActiveVOS, visual orchestration system. We also want to thank TIBCO Software.

This is Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening and come back next time.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, we present a sponsored podcast discussion on the virtues and paybacks from designing a strong IT architecture.

We'll examine how such architectural benefits promote business agility as a service while lowering total cost for both the deliverer -- and the receiver -- of pure application services. This perspective looks at IT architecture with a new twist, not just in terms of developing architectures on-premises, but ... for architectures that support the providers of services.

We'll take a look at how IT architectural best practices at a software-as-a-service (SaaS) provider help not only that provider's operations. We'll show how the users, the receivers, of those services can benefit in new ways as well.

Here to help provide an in-depth look at how proper architecture allows the SaaS delivery model and business agility to come together, we're joined by Stan Swete, CTO of Workday. Welcome back to the show, Stan.

Stan Swete: Hi, Dana. How are you doing?

Gardner: I'm doing well. Workday has had an advantage in that you knew what your goals and objectives were when you started your architectural journey. You knew that you were going to go out as a service and you knew that there were some new modern technologies, approaches, and best practices to take advantage of.

That's a little different from a lot of enterprises that have, in many cases, had decades of IT to adjust and, in a sense, drag along with them. Let's first hear about the level set. When you started out from green field, what things went through your mind, and how was that refreshing, given that you were starting from scratch?

Swete: First, it definitely was refreshing to get the opportunity to start from scratch. I'm sure that if you talk to a lot of IT professionals, they'd all want that chance. At Workday, we had that chance and we started our company with a lot of background in what had gone before in terms of architectures to support enterprise resource planning (ERP).

We had that backlog of information, a list of what worked and what didn't work so well with previous client-server architectures. As you said, just like everyone else, we definitely had an appreciation for all the new developments in technology that make different approaches possible today.

Gardner: Today, enterprises are faced with a number of challenges. They're trying to adjust quickly for very dynamic business environments. They have to watch their costs. They'd like to modernize, but there's a significant time lag between how and when they can take advantage of these modern concepts and when they can't.

Do SaaS providers like yourself allow them to leapfrog by taking advantage of what you've been able to do and then bring those benefits into their business practice?

Complex environments

Swete: We absolutely think it does. You're right. In IT today, people are in a difficult spot. They have complex environments. The complexity has grown for a variety of reasons. Everyone sees the opportunity to modernize and to improve efficiencies, but how do you do that in the midst of a complex environment that is constraining just how aggressive you can be?

That's where SaaS can come in. If you've got a provider like Workday, or someone who's able to take a clean approach, there might be the opportunity to take the right portion of a certain set of your applications and, instead of having to deal with the complexity of managing all the multiple instances and different architectures you might have, use the unified SaaS service as a way to achieve some integration and a way to drive against cost. Today, it's all about cost.

A lot of the discussion around cost has driven IT to look at a variety of dimensions. Just the consolidation of some of the complexities and different instances of architectures that large companies all have is one area where they see opportunity, but they are bound by having to support where they have in place.

Gardner: What intrigues me, Stan, about what you're doing at Workday is that you have gone beyond the concept of just delivering an application or set of applications. You're positioning yourself as a partner for these businesses and how they can then relate to the outside world. You're extending the enterprise boundaries for them, and this notion of business agility as a service kicks in.

Explain for our audience what you mean by extending your value, not just as a provider of applications, but as an extension to enterprise architecture.

Swete: The space we're in is HCM, trying to be the core system that captures all the information about the workforce -- how it's organized, how it's compensated, and what work is actually done.

If you're trying to play that role at an enterprise, you can't be standalone and independent of the enterprise. You're going to have many, many ties into other things that the enterprise has going. You're going to have to be agile, in terms of how your solution can fit into different instances of different enterprises, because everyone has a slightly different picture and puzzle.

What that means to us is that there's a demand on the solutions to be agile, to be able to change shape and to be able to integrate to the variety of different scenarios you have. Otherwise, SaaS doesn't become a productive option for the IT professional to look at, if it's just one-size-fits-all and take-it-or-leave-it. They're going to have to make some trade offs that they can make.

So for us, if we can be viewed as just a solution that can meld itself to fit into whatever else it has got going on and to be an effective core that we can handle in the cloud for them. That's the best way for us to engage.

Gardner: You're also becoming sort of an adjunct and maybe even an accelerant to service-oriented architecture (SOA). If organizations have begun their journey toward SOA, you can provide a catalyst to that as a go-between, a services exchange, if you will, with a number of other providers.

Maybe it's payroll, maybe it's healthcare and insurance benefits, perhaps it's reaching out to partner with other organizations and the labor resources that they have. Do you see it that way -- that this is, in a sense, SOA but as a service?

Embracing Web services

Swete: Absolutely. You mentioned before about us having the ability to look at new and emerging technologies and approaches to architecture. Certainly, we've got the religion of SOA and firmly believe that the right way for us to tie into other systems in the cloud and other systems on-premise of our customers is via SOA and an embrace of Web services.

We embrace that and we think to some extent that it can accelerate SOA adoption within enterprises. Enterprises we talk to all see the technology the same way we do. They all see the appeal of newer SOA architectures, but I go back to the fact that they have the same issue. They have the whole other set of architectures that they've got to be concerned about maintaining.

So, if they can see a segment of their application stack -- in our case, the governance and control of the global workforce -- that absolutely can be an SOA project that we can jointly embrace and can get them down the road toward this new architectural style.

Gardner: For those of our listeners who might not be familiar, Workday is relatively young. You are only few years old. You're based in Pleasanton, CA. You’re focused on HCM, but why don't you fill that out a little bit. Then, let's also talk about the philosophy that you embraced when you started building out your services. Finally, we'll try to take a look under the hood. So, first, a little bit about Workday and then what you have got supporting your architectures?

Swete: I'm happy to introduce the company a little bit. Workday is about a four-year-old startup, as you said, based in Pleasanton. The company was founded by Dave Duffield, former founder of PeopleSoft, and co-founded by Aneel Bhusri. Basically, the company got together four years ago and began development of its products. We launched publicly in November of 2006 and then we had our first version of our HCM business services and two production customers.

Since then, we've grown the customer base up to north of 75 customers, with more than half of them in production. The idea behind Workday, in addition to being a SaaS company and in addition to focusing on HCM, was to focus on enterprises in a space that we define as the upper mid-market and we started with a focus on companies with between 1,000 and 5,000 employees.

In the past two years, we've had great success in selling not only to that target market, but we've been able to move up market and attract larger customers. Today, the average customer we're engaging is probably closer to 10,000 employees than 1,000. So, we'd say that we service companies in a range between 1,000 employees and 20,000-30,000 employees.

We've even attracted larger customers. Flextronics is the example of our largest customer. There are over 200,000 employees, and have selected Workday as a way to consolidate a number of HR instances that they have around the world.

Gardner: Given the fact that you needed to be modern, you needed to be flexible, but you also needed to scale, what were some of your requirements, and what did you end up with in general terms to make this possible?

Success at a high cost

Swete: Let me back up a little bit and just say the other bit of information to toss in about what was motivating us to start the company was just taking a look at the enterprise solution space and starting to identify some of the complexities of owning and implementing these applications.

It's our belief that enterprise applications have driven a lot of success and a lot of value in enterprises, but that success and value has come at a very, very high cost. Essentially the systems come down to being very hard to use, hard to change, and hard to integrate. Those were three thoughts in our heads as we started Workday. We wanted to go after the same space, which is a complex space. There are complex processing requirements and hence, the need to have a solution that’s going to scale.

So, it was taken as a given that we were going to have feature-rich applications that needed to scale to support large work forces, but we wanted to achieve that, while also attacking the issues of being hard to use, hard to change, and hard to integrate.

That's what led us to evaluate the new technologies in terms of how could we take an approach that would allow us to progress against those issues, while still being able to satisfy the enterprise-class functionality that you have to have to play in this game.

Gardner: And what did you decide on?

Swete: The approach we ended up taking, as we took it to the next level down, was that we started to investigate where some of these complexities and difficulties of use came from. As we evaluated the prevalent architecture enterprise systems, that of client-server, there were a couple of dimensions that we looked at.

From the point of view of being hard to use, the user experience for those applications typically was, first of all, designed for a highly trained back-office user and was deployed as a menu-driven application with tons of fields on each particular screen. Then, that user experience was migrated to the Web. So, these were not native Web applications. They're applications that found their way into the browser, but retained their old complexity and difficulty of use.

From the beginning at Workday, we knew we wanted another approach. Rich Internet application (RIA) experiences were emerging and supported by new technologies. We committed ourselves to being an application that was built first and foremost for the browser and one that was also built to consider the needs of not just the back-office, but the rest of the workforce. So, we started to look at technologies like Adobe Flex to give us an ability to be in the browser but to still deliver some of the rich experience that customers expect.

On the side of being hard to integrate, we took a look at the client-server architectures. The way these applications were written was to think about regulatory information that was required. Design a data model to meet that regulatory information and then build the transactions to feed the data model. That gave you a monolithic application that could generate the reporting you needed to satisfy your regulatory reporting, HCM, and financial management.

The integration of other systems to feed data into those systems or to get data out of those systems was left as an afterthought. Integration was not thought about upfront. Integration was not thought about in terms of the new Internet standards we have in the form of Web services, or the new architectural forms and approaches we have in SOA.

From the beginning, we thought about a system that would be able to deal natively with producing Web services to get data out of and back into the application and would treat the conversation with other systems as a first-class conversation, just like the conversation with individual users.

Turning to the ESB

We began an investigation of tools that could help us do that and really looked into the SOA space. We thought that what future state enterprise business applications needed was to embed some of the technologies you find in enterprise service bus (ESB) technologies. So, we've gone ahead and done that.

We do have some of the transformational and delivery options in multiple formats available to us in our data-center, so that the Workday applications can generate Web services. Beyond that, we can transform those Web services into other data formats that might be more meaningful to legacy applications or the other applications we need to tie to. We did a lot of work in that area and came up with the need to embrace Web services and embed in an ESB in our case.

Swete: That comes from the third area of these applications as being hard to change or just the general theme of this discussion today, which is this whole issue of agility. How do you make complex applications configurable, not only when you're initially implementing them but postproduction.

As you move forward, it's not like your business stops changing after you initially implement the enterprise application. Your business is constantly changing, and client-server based applications have shown a real inability to keep up with changing at the pace of anyone's business changes. They've shown a real high cost to be able to change to incorporate new functionality postproduction.

In working on that problem, we took a look at client-server architectures. It's our view that there's a lot of the rigidity in these architectures, and rigidity is what leads to a lack of agility. We think the rigidity in these architectures comes from the fact that you've got a complex logic layer.

Typically, it's multiple languages, but you have an executable that's built out of a lot of lines of program code. Millions of lines of code, in most cases, are backing the logic layer of enterprise systems. That layer has a complex conversation with the relational database, which also has its own complex structure -- typically thousands of relational tables to model all of the data.

Bringing change to that environment is difficult, because changes to the logic layer have to be synched up with corresponding changes to the data layer, and both layers are constantly changing. We decided to take an entirely new approach in this area and embrace an approach that leveraged the concept of encapsulating data with some of the logic into an object.

At Workday, the primary logic server is what we call our Object Management Server. It's a transaction processing system, but it's entirely based on an object graph, and that is just a class structure that represents not only the application and its data, but also the methods that process on that data.

The important difference is that we have that layer and we don't have a correspondingly complex and changing data layer. We have a persistent data store that is a simplified version of a relational database that can persist changes that happen from the object layer. But, as we're developing our applications and changing our applications, we don't need to constantly change the shape and form of the persistence layer. It's an unchanging relational schema that can persist, even as we make changes up in the object layer.

This frees us up to, one, develop our applications more rapidly, but two, to change those applications, even for our customers in production, without having to take the system down and make structural changes to the underlying database.

So, our two new approaches really reduce the coding you do up in the object layer. We try to define the application more as metadata and reduce the complexity of the relational model that you have.

Leveraging modern architectures

Gardner: So, we’ve recognized some of the handicaps of some of the older approaches, recognized the new set of requirements for the modern day, understood that SOA principles can be applied here quite advantageously, and recognized that rich Internet application interfaces are the way to go when the browser is the ultimate client target. Without getting into too much more detail, we've certainly established some improvement in modernization around the architecture. Let's get into a little bit of what that does for you.

We talked in general terms about agility, but there are some interesting add-ons here -- things that you couldn’t have gotten otherwise in terms of benefits. We're not just re-paving cow paths in terms of delivering applications and services. We're actually now able to do interesting things around BI, around scale and customization, and around different services federated to different users, but with more commonality under the hood. That brings more total cost reduction for the end user.

Let's get into what these modern architectures do not only for you in terms of cutting your costs, but advantageously creating new business benefits for your customers.

Swete: When you combine the architecture we talked about with the SaaS delivery model, you get some of these benefit categories. We get benefits in all the categories that you just mentioned, and you're absolutely right. Our view is that it's equal opportunity. There are definitely benefits for the customers that we're serving and, frankly, we think that in the approach there are tons of benefits for us, as a vendor, to take cost out of what we're doing and pass those savings on to our customers.

You named a lot of categories, so let me let me start with one area, which is the benefits we get out of doing more about integration. With an architecture that really facilitates integration and especially, if you combine that architecture with a cloud-based approach or delivery of SaaS, you get what we at Workday call "hosted integration" or "integration on demand."

We use our embedded ESB to do exactly what you just said. We take the ESB and package up integration so that it can be reused across a wide set of customers. The best example of packaged integration within what we call the "Workday Integration Network" is our benefits carrier network.

Here's a solution where Workday has used Web services to tie our HCM solution to a variety of benefits carriers and we offer customers the ability to sign up for this network. They would pay us for the use of the network just as they would pay us for any of other business service that we deliver. What we're able to do is offload the need for them to convey their benefits data out to the carrier and to get information back from the carrier into their human resource system.

This has been a very popular option for most of our customers, because most of our customers are large enough to have multiple carriers. All of the carriers inconveniently have multiple data formats, and the formats are always changing, and the mapping and testing of data access of those formats is always a cost. So, we're able to lift that off of them and just give them a service, which is a tie of all of the carriers they select into the Workday benefit system.

Gardner: Stan, one of the interesting things about cloud and this whole notion of centralizing allows for different things to be done with data. Now, the data is often in little nooks and crannies, in different formats and inside of different architectures. But, as we centralize the architecture, we're also getting more access to different types of data. In doing so, we can do joins, overlays, and comparisons in ways that hadn't been done before at a scale that hadn't been possible, at least at an acceptable price.

Let's get into this notion of BI. What can your architecture bring to the table, and what can your clients start to do in terms of gaining insights into what's going on inside their companies, but just as importantly, in conjunction with their business processes and extended business processes.

Built-in business intelligence

Swete: That's a big question. Built-in BI, as we call it, is absolutely an advantage of our offering. That is what we're offering today and the future that's possible. I can go through maybe a couple of levels on this, because as the customers that we've attracted look at the Workday solutions, they see unusually rich access to data as the first basic offering.

Having an object model that allows us to link more data attributes together than a classical relational database to establish relationship is a lot lighter weight than having to build the foreign key into another table. We're able to cross-link a lot of information that we're tracking inside the object model that we have, and so we're able to offer unusually rich reporting to the customers.

One example is that, just like many HR systems, we can give a straightforward headcount report, but with the Workday system, the headcount report isn't just a flat report in the system. We offer you the ability to give the headcount by organization to link to other information about each organizational entity, get its details if you want to, or see other reports related to that organization, probably more of the point for BI for the actual summary headcount that's in that particular organization, without the need of a third-party tool.

Workday is going to offer you the ability to drill down on that aggregate number, and take a look at the number in terms of all the dimensions that go into it. An HR professional could look at the headcount for an organization and analyze it in terms of gender by business site, for example, or job code by business site. Our transactional application is facilitating multi-dimensional analysis without the need to have to take the data, off load it into an OLAP cube, and then, by a third-party tool, query that cube.

The barrier that we have broken is -- again, going back to client-server systems -- you had these data models that were defined to provide one kind of reporting. Typically, it was regulatory financial reporting or the regulatory HR reports that you have to provide.

Workday provides all of those, but it crosses over into information that could be more interesting to the people who are not just back-office HR professionals, but maybe managers who wanted to get information about their workforce. That is all built into the application, and that's the level of increased BI we're delivering today.

As we look forward into other things we could do, you mentioned reaching across different elements of information. We do a bit of this today in terms of the automated business processing that we offer. We have built-in workflow in Workday and we have a system that is able to track all of the performance of the automated business processes we deliver.

Our BI today can reach across and look into their performance information and give the manager information, such as the average time it took you to do a hire, which department had the longest time to do it, and which department had the shortest time to do it. We'll continue to improve this kind of analytical information over your business performance. We see this as a very valuable area going forward and we'll get richer analytics supported in that space. That's an area that we're verging into.

The third opportunity, which you’ve also alluded to, is the benefits carrier network. There's an ability to drive intelligence across the population of users who are engaging in this network. For example, statistical information about the most widely used carriers might be interesting for any company in the network, whether they have those carriers or not. Usage information about the relative number of people using a carrier inside the company would obviously be interesting.

There is just a large world of opportunity to expand into, but the important thing is that we think as a transaction processing systems, which is what these systems are classically looked at as, we're growing out of that to also provide BI without the need to buy third-party tools to do it.

Social networking

Gardner: We're talking about people here -- workers, productivity, habits. People don't just live in the workplace, they have lives as well, and we have this phenomenon now that's going on around social networking and the ability for people to connect in new and different ways. It seems to me that this offers the potential for yet another large data source to perhaps be compared, contrasted, brought-in, and in some ways leveraged, vis-à-vis what's going on in the HCM apparatus inside the organization.

Swete: You're absolutely right. That actually even widens beyond social networking to the proliferation of productivity tools that get called broadly Web 2.0. For me, what that means is that to be an enterprise application that's relevant in a world where those applications are gaining increased usage, you not only have to have the great system-to-system integration that I talked about before, but you have to be an application that, with good security, is mashup-able, if I can use that non-word.

That's the second dimension of integration that you really can deliver on, if you’re an application that’s built for the Internet, just like the Web 2.0 applications, and certainly Workday is that. The application appears to our users as a Website, and the data in the application is accessible via the Web services I talked before, but you don't always have to construct or communicate in a heavy-duty Web service.

Workday has the ability to have RSS feeds of our data, the ability to instantly tie to emailing systems, the ability to link out to make calls to a phone numbers in Workday. The most popular mashup is always mapping locations of, let’s say, business sites. Workday is wide-open to that type of integration, and we expect that to explode, as the use of our applications reaches out into the workforce.

Gardner: I certainly expect that the ability to integrate to the social tier is becoming all the more important, and can be extremely valuable. I don't think people have plumbed the depths of what productivity benefits are inherent in that.

Swete: People are thinking about that a lot, and there is huge opportunity for a certain class of social network apps to bond with enterprise apps and deliver real value. A great example of that is LinkedIn as an application that really can facilitate a new way to do recruiting, for example. They certainly see that as an opportunity, and it's incumbent upon modern enterprise applications to be able to tie into services such as that, so you can get that kind of benefit.

Gardner: Another important tier to integrate to, or to reach, is the mobile tier. You guys have apparently put some thought into that. Tell us what a SaaS provider like yourself can bring to the table for an enterprise that would love to be able to get more data, more applications, and more business processes extended out to mobile devices across these mobile network.

Widening access

Swete: That's extremely important for us. I think I said this earlier. With our applications, in order to overcome the application being hard to use, you want to work on your native user experience, but you also want to consider that the wider user population is just not always going to use your native user interface (UI). You're going to have people who want to use your application without getting into the pages that your application actually renders. Mobile is a great example of that. We absolutely see widening out access to Workday on the mobile devices.

We're just taking our first step in that direction right now, and this is improving the benefits of the modern architecture. We've been very quickly able to extend the business-process framework that we have. This is the framework that delivers the automated workflow that I spoke about before. We've been able to extend that out so that approvals that are done within that framework can now be completely processed on a mobile device.

We're able to mark-up a subset of our data and have that appear in a native client on the iPhone that you can get on the App Store, just like you get any other iPhone application. Then, with security, you're just utilizing a native app, which is acting on Workday data. We use that for manager approvals, the management of to-do lists, and for enterprise search of the workforce. That's been a successful example of leveraging this modern architecture. We didn't have to go in and rewrite our applications.

Our applications developers merely extended the existing application to say, "for small profile devices here's the data that's relevant to show" and they stopped there. We're able to use the separate UI layer and extend that UI layer to generate a completely different view of what the approval would look like for the mobile device. Then, process that just as if it were a transaction coming in from our own native user experience.

Gardner: I can see where a line-of-business manager could really benefit from this. They've got some ideas about what they want to do with their business. They, of course, have to bring the employees on line. There are going to be approvals, there's going to be a necessity for dealing with the HR department on that.

If they could find a way of entering into that process or workflow around approvals through the mobile device, through these interfaces, do it quickly, and get it automated, I think that might be a very interesting opportunity.

Critical opportunity

Swete: More than interesting. It's critical. If you look at a lot of the managers I know, it's just binary. It's the difference between the using the system and not using the system. Even though we have a very accessible and very user-friendly user experience, we're talking about busy people who use what they use.

They use their portals of information to get access to information on the Web and they use their intelligent cellphones now to get access to information and even to update information.

If we can provide this functionality on the devices that they use, then they will use this. If we can't, then they will get someone else to enter their information into the system, and that's not the way we want it. So, absolutely, it's tying in another theme of Workday as wider access to our applications. We think it's absolutely essential to increase the value that you get from your enterprise applications.

Gardner: One of my favorite sayings is that convenience is the killer application and I think that's what you bring in here, right?

Swete: Absolutely. Mobile is a good place to start with that, but we won't stop there. There is a lot of information that is currently presented well within Workday, but it could be presented just as well within a gadget and someone else's portal. We'll be looking for that opportunity as well. It's a way to put information in front of the people who need to see it without having to draw them into your user experience.

Gardner: Let's move into some examples, perhaps some anecdotes, about how this is being used in the real world and then we'll also look into the crystal ball and see what you might have in mind for the future. Do you have any case studies or anecdotes of how any of your customers have actually put into use, or are getting returns and paybacks from, some of the benefits that we have talked about that have their underpinnings in the architecture?

Swete: I have a couple of examples I think might help. I can go from general to specific. The one general example that I always like to quote is a real payoff and testament to the new architectural approach and combination of the new architectural approach and the use of SaaS in terms of delivering the business services. All Workday customers are always on the current version, and this is very, very different for the world of business enterprise application.

Workday delivers new updates three times a year, and our growing customer population whether they are in implementation or in production, comes up on each of those updates within the six weeks following the initial release of the update.

We did four updates last year. We will do three this year. Just this past month, we have been bringing our user population up to Update 7. If we have had this call two months ago, the only update that anyone would have known about in the customer population was Update 6. Sitting here today, Update 6 is a complete memory, and the only update that anyone knows about, whether they are just implementing on Workday or whether they've been in production for three years, is Update 7. That just brings a whole new opportunity to the customer conversation.

When we're talking to customers, we're all looking at the same code line and the same set of functionalities. We don't have to think about what version, what tech stack are you on, what version of your database are you on, or what version of Workday are you on? When they are asking a question about a new feature they want, we're all looking at the same feature set. It really helps to facilitate the conversation about what new features might be appropriate for the coming update, to say nothing of what it does for the cost profile of supporting these guys.

We have our stack, and that's it. They all run on it and we're able to keep them current on it. That's the benefit from the vendor side. From the customer side, the benefit they get is new functionality delivered to them, and all the manual work and data conversion work that is still necessary is done by Workday and not by them. They can focus on how they want to implement this new functionality on what timetable.

That's data point number 1 for some of the payback to the new architecture. A lot of us who came from the enterprise space are really impressed and pleasantly surprised at how rapidly we can move production customers and implementing customers forward.

The psychological effect

Gardner: I suppose there's a psychological effect there as well on the receiving end of these services. All of a sudden, you're getting more and better, but you didn't have to pay more and you didn't have to go through the pain of implementation and debugging. In adopting new things in the past there was an actual penalty for adoption, whereas the SaaS model gives you all rewards. It's like "hit me again," right?

Swete: It's absolutely that. As a customer, you avoid the high cost of having to set up QA environments and duplicate environments on-premise, having to deal with data conversions, or having to deal with installation instructions for the software that you've got on your premise. That's all handled by the vendor.

The other thing that's not widely talked about that's also valuable, though, is this notion of chunking up how new features come. We're on a regular clock here. So, three times a year, you're going to get a set of new functionality from your vendor and you are going to get converted to it.

In the on-premise world, where the delivery is deferred, what's building up is just a larger set of functionality that's going to have to get consumed some time at very high cost. Part of the way we look at this is that the incremental approach is just much more cost effective for our customers and for us. We know that, because even in our brief history here, we've had an on-going conversation with our customers about how long we want the update periods to be.

Our first update period was seven months and we delivered a ton of functionality. It was harder for them to consume and harder for us to support the upgrade to it. Now, we’re on a really good balance, where we can have meaningful functionality, but come out in a way that can be readily consumed. I don't think -- well, I don't think, I know the on-premise world just does not work that way.

Gardner: Okay, a quick look to the future before we wrap up, Stan. What are some of the implications from what we've been discussing, perhaps in terms of BI, perhaps in terms of extended business processes, or more of this integration agility?

Swete: Let's focus on the last two. We talked about a lot of the value of leveraging new technology to deliver enterprise applications in a new way and then combining that with doing it from the cloud. That combination is going to profoundly change things going forward.

Today, it's a new option for enterprises to look at in terms of offloading some of the applications that they're trying to support in their existing environment. It's a vehicle for consolidating some of the complexity that you have into a single instance that can be managed globally if you have architected globally, as Workday has done.

As I see that playing out going forward, you'll see more vendors taking this approach and you'll see those vendors partnering. If you think about the combination of modern architectures and cloud-based modern architectures, what will happen when two vendors that have taken that similar approach start to partner in terms of integrated business processing is that the bar will get raised significantly for how tight that integration can become, how well supported it can be, and how it can functionally grow itself forward, without causing high cost and complexity to the consuming enterprise that's using both sides.

As I look in the future, I think enterprises will see an ecosystem of their major application providers be cloud-based and be more cohesive than a like group of on-premise vendors. Instead of having a collection of different architectures and different vendors all in their data center, what they will see is an integrated service from the set of providers that are integrating with Web services in the cloud.

Gardner: So, when the cloud model becomes the common denominator, it allows for a lot more, I don't know, co-existence collaboration but I suppose really just integrated processes.

Swete: It allows for a lot more integrated processes. The key thing with enterprise functionality is you're never done. The requirements are always changing, because business is always changing. What it allows for us is not only cloud-based integration, but the ability to change that integration without placing additional cost on your customer.

That's what's the key is, that you will be able to deliver enhancements to the integration between vendors without getting caught up in how that integration might have been deployed at customer A, versus customer B, versus C. That will allow the same kind of agility we've been talking about. That will allow integrated solutions, the cross-vendor integrated solutions, to keep pace with the change of business, which is absolutely not the case today.

Gardner: I want to thank the sponsor of this discussion, Workday, for underwriting its production and a special thanks to our guest, Stan Swete, CTO of Workday. I really appreciate your inputs, Stan.

Swete: Dana, thanks a lot.

Gardner: We've been learning about how IT architecture is destiny and how a SaaS provider's operations can mean more to its customers and simply lower costs and baseline delivery of services as a Web application. We have seen a multiplier effect, if you will, in terms of how new and additional productivity and agility benefits are gained from a modern architecture regardless of its location and ownership.

This is Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening and come back next time.