HP Discover Performance Podcast: McKesson Redirects IT to Become a Services Provider That Delivers Fuller Business Solutions

Transcript of a BriefingDirect podcast from HP Discover 2012 on how health-care giant McKesson has revamped it's IT approach and instituted a cultural shift toward services.

Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: HP.

  
Dana Gardner: Hello, and welcome to the next edition of the HP Discover Performance podcast series. I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your co-host and moderator for this ongoing discussing of IT innovation and how it's making an impact on people’s life.

Once again, we're focusing on how IT leaders are improving performance of their services to deliver better experiences and payoffs for businesses and end users alike. This time, we’re coming to you directly from the HP Discover 2012 Conference in Las Vegas. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

We’re exploring some award-winning case studies from leading enterprises to see how an IT transformation approach better supports business goals. And we'll see how IT performance improvements benefit these companies, their internal users, and their global customers.

Our next innovation case study interview highlights how pharmaceuticals distributor and healthcare information technology services provider McKesson has transformed the very notion of IT. We will see how a shift in culture and an emphasis on being a services provider has allowed McKesson to not only deliver better results, but elevate the role of IT into the strategic fabric of the company.

To learn more about how McKesson has recast the role of IT and remade its impact in a positive way, we're joined by Andy Smith, Vice President of Applications Hosting Services at McKesson. Welcome, Andy.

Andy Smith: Thank you, Dana. I really appreciate you inviting me and I am glad to be able to share my experiences with others.

Gardner: Let me start with this notion of IT transformation. We hear a lot about that. I wonder if you have any major drivers that you identified, as you were leading up to this, that allowed you to convince others that this was worth doing.

Smith: What we did, and this started several years ago, was to focus on what our competition was doing, not the competition to McKesson but the competition to IT. In other words, who was the outsourcer or who were the other data-center providers. From that, we were able to focus on our cost, quality, and availability and come up with a set of metrics that covered it all, so that we could know the areas we needed to transform and the areas where we were okay.

Gardner: So, in a sense, you had to redefine yourself as a services provider, because that's who you saw as your competition?

Smith: Exactly, and that's who our customers are talking to -- our competition. When they came to us for a service, they had already talked to third-party providers. And so we realized very quickly that our competition was the outside world, so we had to model ourselves to be more like them and less like an internal IT department.

Gardner: That, of course, cuts across not only technology, but culture and the whole idea of being accountable and to whom. So let's start at that higher level. How did you begin to define what the new culture for IT should be?

Balanced scorecard

Smith: We started out with a balanced scorecard. It really came down to whether the employees and the customers were satisfied. Did we do what we said – were we accountable -- and were the financials right?

So when we started setting up that balance scorecard, that on its own started to change the culture. Suddenly, customer satisfaction mattered, and suddenly, system availability mattered, because the customer cared, and we had to keep the employees trained, so that they were satisfied.

Over time, that really changed the culture, because we're looking at all four parts of the scorecard to make sure we're moving forward.

Gardner: I suppose it's essential, when you're a services provider rather than a technology products producer and deployer, that you understand what are the right metrics to measure. So is it a different set of metrics from IT to a service provider role of IT?

Smith: It really is, because when we were just an internal IT department, we spent more time saying, "The customer gave us an order, we hit the checkbox and finished that order, we're done." We were always asking, "Did we do it, and did we do it on time?"

What we really focused in on were the real drivers. A lot of the measures are more trailing indicators. Even money tended to be a trailing indicator.

That's not really what the customer was looking for. The customer was looking for. "Did you deliver what I needed, which may be different than what I asked for. Did you deliver it at a good price? Did you deliver it at a good quality." So it did switch from being measuring the ins and the outs of an order taker, to whether we are delivering the solution at the right price.

Gardner: As we've seen in a number of companies, when they’ve gone to more measurement using metrics, key performance indicators (KPIs), and working towards service-level agreements (SLAs), sometimes that can become daunting. Sometimes, there is too much, and you lose track of your goal. Is there a way that you work towards a triage or a management approach for those metrics, those KPIs, that allowed you to stay focused on these customer issues?

Smith: What we really focused in on were the real drivers. A lot of the measures are more trailing indicators. Even money tended to be a trailing indicator.

So we went into what's really driving our quality, what's really driving our cost. We got down to four or five that we are the ones that mattered. "Is the system up and running. Are changes causing outages. Are data protection services reliable. Are our events being handled quickly and almost like a first call resolution. Are they being resolved by the first person that gets the event?"

The focus was prevent the outage and shorten up the mean time to restore, because in the end, all of that will drop the cost. It worked, but it was focusing on a handful, rather than dozens.

Gardner: Is it fair to say that doing this well is, in fact, also a cost-saver? Is there a built-in mechanism for efficiency, when you start focusing on that service provider role, that brokering role?

Pulling down cost

Smith: It truly did bring down our cost within McKesson. I'll probably be off by several million, but each year we pull down our cost several million dollars. So every year my budget gets smaller, but every year my quality gets higher, my employee satisfaction gets higher, and my customer satisfaction gets higher.

It can really get both. You don't have to sacrifice quality to reduce cost. The trick was saying that I no longer needed a person to do this commodity factory work. I could use a machine to do that, which freed up the worker from being a reactive commodity person to being a proactive value-add person. It allowed the employee to be more valuable, because they weren't doing the busy work anymore. So it really did work.

Gardner: For those in our audience who might not be familiar with McKesson, tell us a little bit more about the company. Specifically, tell us about the scale of your IT organization to put those millions of dollars into some perspective in the total equation?

Smith: McKesson IT is roughly 1,000 employees. The company is roughly 45,000 employees. So percentage-wise, we're not that big. My personal budget to run the IT infrastructure is about a $100 million a year.

So pulling out a few million dollars a year may be only a few percent, but it's still a pretty significant endeavor. We've managed to pull that cost out, both through the typical things like maintenance contracts and improved equipment, but also by not having to grow the full-time employee (FTE) base. I haven't had to let any FTEs go, but what we've discovered was that, as we did these things, I needed fewer employees.

To get people to stop thinking about the technology and start thinking about the business solution is a slow transition, because it's a real mind-shift.

As employees resigned, I didn't have to replace them. My staff base has been shrinking, but I haven't had anybody lose a job. So that's been also very reassuring for the employees, because they kept waiting for that big shoe to drop, waiting for us to say, "We're going to outsource you," but we've never had to do it.

Gardner: I guess when you compete against the outsourcers better, then you are going to retain those jobs and keep that skill set going. There is a cliché that you're able to take people from firefighting and put them into innovation. Is there a truth to that in what you've done?

Smith: That really is truth. It took time, and we’re not done, but to get people to stop thinking about the technology and start thinking about the business solution is a slow transition, because it's a real mind-shift. In a lot of ways, these employees see the reactive work as the bread and butter work that puts the paycheck on the table. That lets them be a firefighter and a hero, and if you take that away, the motivators are different.

It takes time to get people comfortable with the fact that your brain is worth a lot more doing value-add work than it was just doing the firefighting. We're still going through that cultural shift. In some ways, it's easier for the older employees, because if you go back a few decades, IT was that. It was programmer analyst, system analyst, and business analyst. For me, "analyst" disappeared from all my job titles.

In the last couple of decades, for some reason, we erased analyst, and now you're just a programmer or an operator. In my mind, we're bringing the analyst back, which for the older employees, is easy, because they used to do it. For the younger employees, we've got to teach them how to be consultants. We've got to teach them how to be analyst. In some cases, it's a totally different, scary place to go, because you actually have to come out of the back office and talk to somebody, and they're not used to that.

Cultural shift

Gardner: Maybe there are methodologies that work here that you could discuss, services-oriented architecture (SOA) comes to mind and also ITIL. Have you been using ITIL approaches and SOA to help make those transitions? Is there a technology track is a cultural shift?

Smith: Yes, we went down the ITIL road, because we were manual before. Everybody was doing it with tribal knowledge. The way I did it today might be different than the way I'd do it tomorrow, because it's all manual, and it's all in people's heads.

We did go into ITIL version 3 and push it very hard to give that consistency, because the consistency really mattered. Then, we could really measure the quality. We could be ensured that no matter who did it or when it was done, it was done the same way, and that reliability mattered a lot.

We also got away from custom technology, and we got to where everything is going to be a certain type of machine. It's going to look the same. All the tools are going to be fully integrated and no longer be best-of-breed point solutions. Driving that standardization made a big difference. You don’t have to remember that machine on the left you reboot it this way, and that machine on the right you reboot it a different way. You don’t have to remember anymore, because they're all the same.

We made the equipment and tools standard and more of a commodity so that the people didn’t have to be that anymore. The people could be thought leaders. All those things really did work to drive out the cost and increase the quality, but it's a lot of different pieces. You can't do it with just one golden arrow. You have to hit it from every angle.

We had to increase the transparency to say we’re doing a good job or we’re doing a bad job.

We had to change the technology, the people, and the processes. We had to increase the transparency to say we’re doing a good job or we’re doing a bad job. It was just, "Expose everything you’re doing."

That's scary at first, but in the end, we found out we really are competing with the competitors and we can continue to do it, and do it better. We understand healthcare, we understand McKesson, and we’re an internal group, so we don’t have a profit margin. All those things combined can make us a better IT solution than a third party could be.

Gardner: And as you entered that standardization process, did that services orientation become a value point for you? Did private cloud or an even a hybrid model start to become interesting? How far have you progressed in that “cloud direction”?

Smith: The services orientation helped a lot. We’re on the IT side, so we started out with our service as Unix, our service as data, our service as Windows. Getting us focused on that helped us remember what the service really was. We’re now stepping back even one step farther and saying that that no longer matters.

What really matters is the business solution you’re trying to solve. We’re stepping even farther back, saying that the service is order to cash, or the service is payroll, or the service is whatever. We’re stepping back farther, so we can look at the service from the standpoint of the customer. What does the customer want? The customer doesn’t want Unix. The customer wants order to cash. The customer doesn’t want Windows. The customer wants payroll.

Thinking about cloud

Stepping back has now allowed us to start thinking about that cloud. All the equipment underneath is commoditized, and so I can now sit back and say that the customer wants this business solution and ask who is the best person to give me the components underneath?

Some of them, for security reasons, we’re going to do on our internal cloud. Some of them, because of no security issues, we’re going to have a broker with an external provider, because they may be better, cheaper, or faster, and they may have that ability to burst up and burst down, if we’re doing R&D kind of work.

So it's brought us back to thinking like a business person. What does the business need and who is the best provider? It might not be me, but we’ll make that decision and broker it out. This year we're probably going to pull off our internal cloud and our external cloud and really have a hybrid solution, which we’ve been talking about for a couple of years. I think it will really happen this year.

Gardner: We’re here at HP Discover and HP COO Bill Veghte was on the stage a little while ago. One of the things that he said that caught my attention was that we’re producing the app services and the Web services that are the expression of business processes.

I thought that was a good way to put it, because in the past, business processes had to conform to the applications. Now, we’re able to take the applications in the hybrid delivery model and extend them to form what the business processes demand. Is that also sort of a shift that's come along with your going more towards a service brokering capability?

The other 80 percent is really unique business services that our customers need to improve healthcare, to reduce the cost in healthcare, and those are really unique to McKesson.

Smith: It is a shift that's going on, and it's interesting, because I don’t think part of this is matured. If you’re dealing with the big package products whether it's the Oracles or the SAPs, those people are dictating almost a custom solution in order to keep themselves alive. But that's probably 20 percent of my business, when I think about servers and applications.

The other 80 percent is really unique business services that our customers need to improve healthcare, to reduce the cost in healthcare, and those are really unique to McKesson. What I am finding, when I look at those types of business services, they are the real bread-and-butter that makes our world different.

Having the hybrid capability does let me put together the pieces to optimize what the business need is, but it is the 80-20. For the 80 percent I can do it. For the other 20 percent, those vendors are probably going to lock me into a custom solution, but that's okay.

Gardner: Well great. I am afraid we’re about out of time. We’ve been discussing with McKesson, how they’ve recast the role and impact of IT. I want to thank our guest, Andy Smith, Vice President of Applications Hosting Services at McKesson. Thanks so much, Andy.

Smith: Thank you very much, Dana.

Gardner: And I also want to thank our audience for joining us for this special HP Discover Performance podcast coming to you from the HP Discover 2012 Conference in Las Vegas.

I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your host for this ongoing series of HP sponsored discussions. Thanks again for listening, and come back next time.

Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: HP.

Transcript of a BriefingDirect podcast from HP Discover 2012 on how health-care giant McKesson has revamped it's IT approach and instituted a cultural shift toward services. Copyright Interarbor Solutions, LLC, 2005-2012. All rights reserved.

You may also be interested in:

• Investing Well in IT With Emphasis on KPIs Separates Business Leaders from Business Laggards, Survey Results Show
• Expert Chat with HP on How Better Understanding Security Makes it an Enabler, Rather than Inhibitor, of Cloud Adoption
• Expert Chat with HP on How IT Can Enable Cloud While Maintaining Control and Governance
• Expert Chat on How HP Ecosystem Provides Holistic Support for VMware Virtualized IT Environments

Architecture is Destiny: Why the Revolution in Business Interactions Can't Work on Conventional Databases

Transcript of a sponsored BriefingsDirect podcast on moving beyond relational databases and relying on services-based architectures.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: Workday.

Additional resources:

The Real SaaS Manifesto (whitepaper)
Things Large Enterprises Need to Know About SaaS
Strength from the Core: Why Bolted-On BI Doesn't Work for HR
Built-In Business Intelligence
Real Saas
Notes from Workday's Technology Summit

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're listening to BriefingsDirect.

Thanks for joining this sponsored podcast discussion on how IT architectures at software-as-a-service (SaaS) providers provide significant advantages over traditional enterprise IT architectures.

We will look at how one human resources management (HRM), financial management and payroll SaaS provider, Workday, has from the very beginning moved beyond relational databases and distributed architectures that date to the mid-1990s. Instead, Workday has designed its architecture to provide secure transactions, wider integrations, and deep analysis off of the same data source -- all to better serve business needs.

The advantages of these modern services-based architecture can be passed on to the end users -- and across the ecosystem of business process partners -- at significantly lower cost than conventional IT.

I'm here now with a technology executive from Workday to explore how architecting properly provides the means to adapt and extend how businesses need to operate, and not be limited by how IT has operated.

So please join me now in welcoming Petros Dermetzis, Vice President of Development at Workday. Welcome to BriefingsDirect, Petros.

Petros Dermetzis: Hello, Dana. How are you?

Gardner: Very good. What is it that is different about a Workday stack versus a traditional enterprise IT stack?

Dermetzis: The luxury that Workday had at the very beginning was to start with an absolutely clean slate. Enterprise resource planning (ERP) solutions evolved over time and started adding technology solutions as problems occurred.

We have a unique opportunity to stand back and see what history and evolution provided over the past 20 years and say, "Okay, how can we provide one technology stack that starts addressing all those individual problems that started appearing over time?"

Gardner: It sounds as if a SaaS provider like Workday almost has the luxury of working the main architecture problem, rather than working many problems from what was already in place. Tell me about this clean slate. How important is that? How big of an advantage is that?

Climbing a ladder

Dermetzis: It’s a huge advantage. Look at most ERP vendors, for example. They started with a need to report data and very quickly realized it was like climbing a ladder of hierarchic needs. When you get your basic reporting right, you need to start analyzing data.

The technologies at the time, around the relational models, don’t actually address that very well. Then, you find other industries, like business intelligence (BI) vendors, appeared who tried to solve those problems.

What we try to do at Workday is understand holistically what the current problems are today, and say, "This is a golden opportunity." This is opposed to finding all existing technologies, cobbling them all together, and trying to solve the problems exactly the same way.

Is there a totally different innovative approach to addressing those problems?

Gardner: I have to imagine too that the requirements are different. Back when ERP was just coming into the mainstream, it was about just getting a handle on processes. Now, we're at the point of refining and extending processes. It’s a different set of requirements.

Dermetzis: If you go back in time to when mainframes started appearing, it was about transactions, capturing transactions, and safeguarding those transactions. IT was the center of the universe and they called the shots. As it evolved over time, IT began to realize that departments wanted their own solutions. They try to extract the data and take them into areas, such as spreadsheets and what have you, for further analysis.

We want to take it more to an area which is business interactions, and interactions can happen from humans or machines.

Obviously, they were solving the problem incrementally, as they were going along. What we tried to do was address it all in the same place. Where we are right now is what I would describe as very business transaction-centric in what I define as legacy applications. Then, we want to take it more to an area which is business interactions, and interactions can happen from humans or machines.

Gardner: Just for the edification of our listeners, Workday is focused on human resources management (HRM) and other employment-related issues, but also increasingly moving into a larger ERP and the business applications set. The important fact here is that in human resources you need to relate to outside entities. Maybe it’s payroll, maybe it’s insurance or healthcare. This puts you in an interesting position of mastering the integrations, something that’s probably going to become more important with cloud computing and other aspects of business over the coming years.

Dermetzis: That’s correct. If you think of the majority of the systems out there, the way we describe them is that they were built from the ground up as islands. It was really very data centric. The whole idea was that the ERP system gave all the solutions, which in reality isn't true.

If you're managing any system with HRM systems, you need to communicate with other systems, be it for background checks, for providing information to benefit providers, connecting to third-party payrolls, or what have you.

Adopting new standards

Right now, the state of the art is hardwiring most of these central solutions to these third-party solutions, and that basically doesn't scale. That’s where technology kicks in and you have to adopt new open standard and web services standards.

Gardner: Let's drill down a bit into existing legacy architecture. It was the right architecture for the job, but the job has changed. What can be done? As you mentioned earlier, people have incrementally added on over the years more and more. They have a sort of bolt-on mentality. What's wrong with that, and what can be done to move in a new direction?

Dermetzis: I would describe it more like an onion. We keep on adding more and more and more layers of vendors, and the more the poor enterprise IT customers are trying to peel it, the more they start crying -- crying in terms of maintenance and maintenance dollars.

Just to introduce the basic concept of how applications are being built, they are being built with the idea of storing, managing, and safeguarding the transactions.

Applications are built on top of relational databases today, and then they are being designed thinking about the end-user, sitting in front of a browser, interacting with the system. But, really they were designed around capturing the transaction and being able to report straight-off that transaction.

However, all the business logic, all the security, and the whole data structure that hangs together, is known by the application and not by the database.

The idea of integrating with third parties was an afterthought. Being an afterthought, what happened was that you find this new industry emerging, which is around extract, transform and load (ETL) tools and integration tools. It was a realization that we have to coexist within the many systems.

What happened was that they bolted on these integration third-party systems straight onto the database. That sounds very good. However, all the business logic, all the security, and the whole data structure that hangs together is known by the application -- and not by the database. When you bolt-on an integration technology on the side, you lose all that. You have to recreate it in the third-party technology.

Similarly, when it comes to reporting, relational technology does a phenomenal job with the use of SQL and producing reports, which I will define as two-dimensional reports, for producing lists, matrix reports, and summary reports. But, eventually, as business evolves, you need to analyze data and you have to create this idea of dimensionality. Well, yet another industry was created -- and it was bolted back onto the database level, which is the [BI] analytics, and this created cubes.

In fact, what they used were object-oriented technologies and in-memory solutions for reasons of performance to be able to analyze data. This is currently the state of the art.

Gardner: And this is fairly expensive. When you have to buy the bolt-on, you have to manage the integrations yourselves. You have to troubleshoot where it's going to break and where it's brittle. Then, of course, you have to add what you can for security and maintenance over time to keep up that needed level of security. We're talking about some significant cost.

Why don't we address that? Why is this bolt-on approach not just problematic technologically, but also very expensive?

Things are never stable

Dermetzis: That’s absolutely true. In fact, if you think about it, you can actually buy something. You can buy an older application, a legacy application and you can bolt-these integrations and analytics components onto it. You can get it up and running, and everyone is happy.

But then, things are never stable. Vendors update things, change things. They upgrade, they apply fixes and patches, change their data models. And what you have done is, in effect, you have alienated and broken these third-party bolt-ons.

IT shops have hundreds and hundreds of integrations hanging over this all. And, the times comes when they don't want to accept anything, not even a bug fix from a vendor, because they know they're going to break their integrations. That’s just maintainability, and that’s just dollars and dollars and dollars that you need to spend to maintain things.

And you can't get new functionality, new innovative solutions, because as soon as you go back and start changing things downstream, well ... the costs are huge.

Gardner: So, with Workday, or any SaaS provider that’s architecting for the future, you're able to address some of these issues for your architecture, but you're also able to add new technology based on the architecture, not as an adjunct or an additional bolt-on product.

The reality around ERP systems is actually making all this work together.

This is happening behind the scenes. You're able to improve your security, keep up any patches that you need to do, while at the same time increasing the frequency through which these end users can enjoy these improvements.

So, we've got, I think, two benefits here. One is the initial architecture, and two is the fact that you're managing all that maintenance. Please tell me why these two aspects are important and what you did to make it improved over the past systems.

Dermetzis: The way things evolved, you started with an application, and integrations were an afterthought; they got bolted on. Analytics was an afterthought, and that got bolted on.

What we tried to do at Workday was start from a complete white sheet of paper. The reality around ERP systems is actually making all this work together. You want your transactions, you want your validations, you want to secure your data, and at the same time you want access to that data and to be able to analyze it. So, that’s the problem we set out to do.

What drove our technology architecture was first, we have a very simple mentality. You have a central system that stores transactions, and you make sure that it's safe, secure, encrypted, and all these great words. At the same time, we appreciate that systems, as well as humans, interact with this central transactional system. So we treat them not as an afterthought, but as equal citizens.

Additional resources:

The Real SaaS Manifesto (whitepaper)
Things Large Enterprises Need to Know About SaaS
Strength from the Core: Why Bolted-On BI Doesn't Work for HR
Built-In Business Intelligence
Real Saas
Notes from Workday's Technology Summit

The same treatment

Any request that comes into our system, be it from a UI or from a third-party system by integrations, we treat exactly the same way. They go through exactly the same functional application security. It knows exactly what the structure of your object model is. It gets evaluated exactly the same way and then it serves back the answer. So that fundamental principle solves most of our integration problems.

On the integration side, we just work off open standards. The only way that you can talk with a third-party system with Workday is through web services, and those services are contracts that we spec to the outside world. We may change things internally, but that’s our problem.

We're a SaaS vendor, and we do modify things and we add things, but those external contracts, which are the Web services talking to third-party systems, we respect and we don’t change. So, in effect, we do not break the integrations.

The next one is about analyzing data. As I said, there are a lot of technologies out there that do a very good job at lists and matrix reporting. Eventually, most of these things end up in spreadsheets, where people do further analysis.

But the dream that we are aiming for continuously is: when you are looking at a screen, you see a number. That number could be an accumulation of counts that you'd be really interested in clicking on and finding out what those counts are -- name of applicants, name of positions, number of assets that you have. Or, it's an accumulation. You look at the balance sheet. You look at the big number. You want to click and figure out what comprises that number.

To do that, you have to have that analytical component and your transactional component all in the same place. You can't afford what I call I/Os. It's a huge penalty to go back and forth through a relational database on a disk. So, that forces you to bring everything into memory, because people expect to click something and within earth time get a response.

The technology solutions that we opted for was this totally in-memory object model that allows us to do the basic embedded analytics, taking action on everything you see on the screen.

When you are traversing, you come to a number in a balance sheet, and as you're drilling around, what you are really doing in effect is traversing an object model underneath, and you should be able to get that for nothing.

The technology solutions that we opted for was this totally in-memory object model that allows us to do the basic embedded analytics, taking action on everything you see on the screen.

Gardner: And that common approach with the juxtaposition of the logic and the data also allows you to update your system without worrying about all of those bolted-on aspects breaking, which gets us back to that ability to update, refresh, and deliver new benefits fairly rapidly.

One code line

Dermetzis: That’s absolutely true as well. As soon as you can have the luxury of maintaining one system, let's call it one code line, and you're hanging our customers, our tenants, off that one single code line, it allows you to do very, very frequent upgrades or updates or new releases, if you wish, to that central code line, because you only have to maintain one thing.

And, there is another bit of technology that you add to that. We're a totally metadata-driven technology stack. Right now, we put out what we describe as updates three times a year. You put new applications, new features, and new innovations into the hands of your customers, and being in only one central place, we get immediate feedback on the usage, which we can enhance. And, we just keep on going on and keep on adding and adding more and more and more.

This is something that was an absolute luxury in your legacy stack, to take a complete release. You have to live through all the breakages that we mentioned before around integrations and the analytical component.

Gardner: Could you explain about that persistence layer? You started to get into it a bit with the metadata. Explain that a bit more in more detail if you would.

Dermetzis: The persistence layer is really forced by the analytical components. When you're analyzing information, it has to perform extremely fast. You only have one option, and that is memory. So, you have to bring everything up in-memory.

What you used to use in legacy system was putting things on tape for safety and archiving reasons. We use disk, and we actually believe, if you look at the future, that nearly everything will be done exclusively in-memory.

We do use a relational component, but not as a relational database. We use a relational database, which is what it’s really good at securing your data, encrypting your data, backing up your data, restoring it, replicating it, and all these great utilities the database gives you, but we don’t use a relational model. We use an object model, which is all in-memory.

But, you need to store things somewhere. In fact, we have a belief at Workday that the disk, which is more the relational component, is the future tape. What you used to use in legacy system was putting things on tape for safety and archiving reasons. We use disk, and we actually believe, if you look at the future, that nearly everything will be done exclusively in-memory.

Gardner: So, the architecture is destiny and we can see the architecture is shifting. I wonder about if I'm an enterprise IT individual. I really understand the architecture, and I enjoy your position of being able to do it the right way from your vantage point. But I can’t, as this IT leader. I have other restrictions. I have this large installed base that I need to maintain. How is it that these can coexist? How is it that a SaaS provider like Workday integrates to enterprise XYZ with a lot of legacy ERP? What’s the connection point there?

Dermetzis: The main connections that you have with systems are when you want to start creating applications or sharing information from other systems. As I mentioned before, when it comes to integrations, the only way you talk to Workday is via web services.

We still have systems that require a flat file, a comma-delimited file, that we need to send to them. That’s the point where we have a technology around our enterprise service plus our integration server that actually talks the language that we do, standards web service based. At the same time, it's able to transform any bit of that information to whatever the receiving component wants, whether it’s banking, the various formats, or whatever is out there.

We put the technology into the hands of our customers to be able to ratchet down the latest technology to whatever other files structures that they currently have. We provide that to our customers, so they can connect them to the card-scanning systems, security systems, badging systems, or even their own financial systems that they may have in house.

Gardner: I suppose the point there is that you're forward-compatible, based on our earlier discussion points about being able to move to the future, bring in new technologies, and keep up-to-date with security and other best practices, but you are also backward-compatible, based on your architecture for integration.

Straightforward approach

Dermetzis: That’s correct. In fact, it's the beauty of working with forward-thinking companies. I'll use an example of Salesforce.com. Our integration with Salesforce is totally web services talking to web services -- straightforward. We have a contract called web service. They have a similar contract. It just works, whatever we do or whatever they do. We don’t break each other.

It’s a whole different conversation, when you are trying to integrate some of our payroll output into one of our customers who has an SAP financial system. So, we are going to have to ratchet that down all the way to whatever file format that party vendor has. But we can do it, and we have the technology to put it in the hands of our customers.

Gardner: The architecture you've been describing at Workday not only benefits the end users, not only provides the forward- and backward-compatibility, but you have also architected for your own business model, I assume, which involves the need for multi-tenancy. You want to provide the lowest cost services for your own business model, but that I suppose also has architectural benefits. Tell me how the architecture relates to multi-tenancy and why that’s important for you as an organization.

Dermetzis: Multi-tenancy is one of the core ingredients, if you want to become a SaaS vendor. Now, I'm not an advocate of saying multi-tenancy A is better than multi-tenancy B. There are different ways you can solve the multi-tenancy problems. You can do it at the database level, the application level, or the hardware level. There’s no right or wrong one. The main difference is, what does it cost?

All we're looking at is one single code line that we have to maintain and secure continuously.

We believe in one single code line, and multiple tenants are sharing that single code line. That reduces all our efforts around revving it and updating it. That does result in cost savings for the vendor, in other words, ourselves.

And as far back as I can remember, when humans realized that you take time and material, package that for a profit, and send it to your end-market, as soon as you can reduce your cost of the time or the material, you can either pocket the difference, or move that cost saving onto your customers.

We believe that multi-tenancy is one of the key ingredients of reducing the cost of maintenance that we have internally. At the same time, it allows us to rev new innovative applications out to the market very quickly, get feedback for it, and pass that cost savings on to our customers, which then they can take that and invest in whatever they do -- making carpets, yogurt, or electric motors.

Gardner: This architectural approach, with its benefits around analytics, integration, the single source code, and the multi-tenancy values, the ability to adapt quickly and pass those updates along without disruption, all points to almost a revolution in how IT is conducted.

What does that mean for organizations that don’t take the plunge, whether they do this on their own architectures or they start to use more of the outside providers? It almost sounds like there is going to be a sort of a haves or have-nots split in the market in terms of how people adapt to these new IT economics?

Dermetzis: We're living through, or we're creating a revolution in the ERP industry. As always, you have early adopters. At the other end of the bell-shaped curve, you've got the laggards. When you're talking to forward thinking, modern thinking, profit-oriented, innovative companies, they very quickly appreciate that the way to go is SaaS.

Security questions

Now, they've got a bunch of questions, and most of the questions are around security -- "Is my data safe?" We have a huge variety of ways of assuring our customers that these are actually probably safer in our environment than on premise.

Some customers wait, and some will just jump in the pool with everyone else. We are in our fifth year of existence, and it’s very interesting to see how our customers are scaling from the small, lower end, to huge companies and corporations that are running on Workday.

Gardner: What can we look to in the future? If we go back to that future-proofing benefit, the architecture that you are using, the benefits and value that you are able to pass along in terms of functional improvements, more rapidly adopted, and these economic benefits, what’s next?

Is there a benefit to going into the mobile tier? Are there benefits of adopting other source applications, cloud computing or third-party ecosystems? By doing this architecture properly, what can we expect as new trends in IT and business unfold?

Dermetzis: The thing that moves incredibly fast in the market is where humans interact. If you think way back when, there were green screens, and then we moved to client server, where everything was based on a Windows-based machine. Then, you move into the Internet, so you are actually touching more and more and more users. Right now, I think the next revolution is around mobile devices.

The trick here is how you can provide similar functionality that you have on a browser-based system onto the devices very simply and quickly.

There are two types of users normally in an enterprise. First, are the users who are the administrative users, the HR partners, the procurement clerks, everyone who actually needs the back-end system, and there’s one way to address that. They normally sit in front of their computers and browsers most of the day.

Then, you have the other population, the real population of a company, which is the operational side. They don’t even care if they have a back-end ERP system. Where the future there is that they will interact with the back-end, without even knowing it’s there, via mobile devices.

The trick here is how you can provide similar functionality that you have on a browser-based system onto the devices very simply and quickly. By the way, the device world is changing continuously. The interaction that you get from an iPhone is very different than what you will get from an Android, or what you will get from a BlackBerry. So that comes back to the vendor. The way you should be architecting your product should be end-user or end-device agnostic, as much as possible.

That’s where the future is. For devices that come out of Apple, you have to go native, because people expect a certain user behavior. The better job we do there, they don’t even have to care if Workday is on the back-end. They can do their expenses, their time reporting, and their approvals.

The other devices, which are more browser-based, require something more like an HTML technology to be able to provide the solutions for those devices. So, your back-end technology must be able to be versatile enough to keep up with that growing device evolution that’s going on right now.

Gardner: So it sounds like we are back to that conundrum of the onion, where we have got yet another layer now, managing how the mobile tier and various devices within that mobile environment relate back to the logic and the data. For IT, this is not a minor, trivial issue, but a SaaS provider is going to work this through. They have to, and they probably are well on their way to doing it.

Back to technology

Dermetzis: That’s exactly right. It comes back to technology, again. What we have on the back-end, the way we build our business logic, the business logic is agnostic. If the request comes in from a user or a system, the people who actually build the business logic themselves have got no control over what it looks like.

Now, what does that mean? From a technology point of view, they focus on the business logic and the validation in that behavior, and the tool will take care of rendering it on a browser or on a mobile device.

So, today, we're an Adobe Flex-based front end browser. Tomorrow it’s Silverlight, HTML5, whatever it is. The way you architect your product, you should be able to always be on the latest and greatest technology out there, without having to rewrite your application.

Gardner: Well, great. I am afraid we will have to leave it there. We've been discussing the advantages of modern services architecture and how those benefits can be passed on to users and extend both in terms of forwards compatibility and also legacy or backwards compatibility. We've been comparing and contrasting this to what a lot of enterprises have as a vestige of the 1990s in terms of their IT.

I want to thank our guest. We've been talking about this with Petros Dermetzis, Vice President of Development at Workday. Thank you, Petros.

Dermetzis: Dana, thank you for your time.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.

Additional resources:

The Real SaaS Manifesto (whitepaper)
Things Large Enterprises Need to Know About SaaS
Strength from the Core: Why Bolted-On BI Doesn't Work for HR
Built-In Business Intelligence
Real Saas
Notes from Workday's Technology Summit

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: Workday.

Transcript of a sponsored BriefingsDirect podcast on moving beyond relational databases and relying on services-based architectures. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

• Delivering Data Analytics Through Workday SaaS ERP Applications Empowers Business Managers at Actual Decision Points
  
  
• HCM SaaS Provider Workday's Advanced Architecture Brings New Business Agility Benefits to Enterprises
  
  
• Workday's Aneel Bhusri on Advancement of SaaS and Cloud Models for Improved ERP

WSO2 Data Services Provide Catalyst for SOA and Set Stage for New Cloud-Based Data Models

Transcript of BriefingsDirect podcast on data services, SOA and cloud-based data hosting models.

Listen to the podcast. Sponsor: WSO2.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, a sponsored podcast discussion about data services, how services-oriented architecture (SOA) is enabling an expansive reach for data, particularly enterprise data, how this will relate to the development of cloud infrastructures and services.

We’ll also examine what technologies and approaches organizations will need to federate and integrate these data sources and services and hosts, but without additional risk. That is to say, to free up data, give it more legs, but without losing control or increasing security risk.

We're also going to look at how open-source software relates to this, and how organizations are bridging the risk reduction and larger availability of data using open-source software.

To help us in this discussion, we are joined by distinguished a panel. First, Paul Fremantle, the chief technology officer at WSO2. Welcome, Paul.

Paul Fremantle: Hi, nice to be here.

Gardner: We are also joined by Brad Svee, the IT manager of development at Concur Technologies, a travel and expense management company in Redmond, Wash. Welcome to the show, Brad.

Brad Svee: Glad to be here.

Gardner: We are also joined by James Governor, a principal analyst and founder at RedMonk. Good to have you back, James.

James Governor: Thank you very much. Hello, everyone.

Gardner: Let's set this up by looking at the problem. I suppose the good news of looking into the past is that data has been secure and controlled. There are lots of relational databases with many, many bells and whistles applied over the years. There has also been a lot of development, middleware, and system's administration work to manage that data, keep it available, but also secure. That's the good news.

The bad news is that it's been limited in some respects by that firewall of personnel, technologies, and standards around it. I want to go to first to Paul Fremantle. Can you tell us a little bit about why the old model is not going to be sustainable in the world of services and mixed hosting environment?

Fremantle: It's a very interesting question. There are two key issues around the old model. The first is the just-in-time nature of data systems that are being bought today. Typically, customers are coming onto Websites and expecting to see the status of the world as it is right now.

They don't want to know what happened yesterday. They don't want to know what happened a week ago. They want to know exactly what happened right now. So it's very important that we move away from batch-oriented systems and file dumping and move to a real, live connected world, which is what people expect out of the Internet.

That live, connected world needs to be managed properly and it's very, very difficult to build that as a single monolithic system. So, it's really essential to move the ownership of that data to the people who really know it, create it, and own it, and that really plays to SOA. This is the model of keeping the data where it belongs and yet making it available to the rest of the world. That's the first point.

The second point is, of course, the danger inherent in getting it wrong. I have two stories, which I think will shed some interesting light on this. One is, I was working with a government organization and they were involved in a situation where every day one of the employees has to FTP a data file from a remote system and back load into their local system.

The employee went ill, and, of course, this didn't happen. They had a whole process to find out who had the password, who could do this and solve this problem. The employees had no one there to back load this data. As I was investigating, it turned out that data in the remote system, from the other organization, was actually coming from within their own organization.

There was another employee uploading the data from the main system to the remote system every day, and they had no clue about this. They didn't realize that this process had built up, where the data from organization A, was being sent to organization B, and then re-downloaded to organization A again, every single day, taking up two employee's time to do that.

Gardner: This is sort of the medieval approach to data transfer.

Fremantle: This is the medieval approach to data transfer. This was not back in 1963 that this is happening. This was actually happening in 2007.

Governor: Medieval or not, the simple fact is that there are vast amounts of exactly that kind of stuff going on out there. Another lovely story told by Martin Fowler talks about a customer -- I believe he was in the U.K. NHS, but I should be a little bit careful there. I should say it was a large organization, and they were freaking out. They said, "We've got to get off Java, because the printer driver is just no good."

He said, "What exactly are you trying to do? Let's have a chat about the situation." "We got to get off Java. We will just try and work it out." He looked at the work was that got involved. Basically, they were getting a document, printing it out, taking it across the room, and then typing it into another system on the other side of the room. He had to tell them, "Well, maybe there is another way of doing it that won't require printer drivers."

Gardner: One of the motivators, it seems, is if nothing dramatic requires you to change your patterns, then you stay with them. It's sort of inertia with people's behavior, and that includes IT. What we're seeing now is an impetus, or an acceleration and automation in services, because they have to, because there are outside organizations involved. A business process is not strictly internal, from one side of the room to the other, but could be across the globe and span many different companies. Does that sound correct, Paul?

Fremantle: Absolutely. I just want to give you a second example, which has been very well published in the U.K. where I live, but maybe it hasn't been so well known outside of U.K. The revenue and the customs in the U.K. had a significant problem recently, where they sent a CD containing 20 million records, including the birth dates, names, national insurance numbers, and bank account details of the 20 million people to another government department.

And, they lost it. They sent it again, and they lost it again. It would not be too far to say this had significant ramifications on the government and their ability to stay in government. The payoff of this was, they had policemen out searching rubbish dumps. They had to send a personal letter to each of the 20 million people. Banks had to update their security procedures.

The overall cost of this mistake, I imagine, must be in the millions of pounds. Now, the interesting question is, firstly, they didn't encrypt that data properly, but even if they had, there is a huge difference between encrypting an online system and encrypting a CD. If a hacker gets hold of the CD, he can spend as long as it takes to decrypt that system. If it takes him two years of computing power to do that, he can sit there for two years and break it.

If you have an encrypted online system and someone keeps trying to break it, the administrator sees log messages, knows that something is happening, and can deal with that. So it's not just the lack of encryption and the bulk dumping of data from one department to other, that's the problem. The model of sticking it on a CD hugely increases the dangers.

Governor: Well, people should be imprisoned for that, or at least lose the right to trade. Obviously, being government organizations, it's difficult to make that stick, but the U.K. government loves the use of phrase "fit for purpose." Quite frankly, there has been evidence that they are not fit for purpose.

Interestingly enough, one of the things about the importance of data and managing it more effectively, is thinking about data in a more rigorous way. I was going to talk on this call about "leaky abstractions." One of the problems with SOA is the notion that, "Oh, we can we can just take the system as it is and make it available as a service."

Actually, you do want to do some thinking and modeling about your data, your data structures, and how it can be accessible, and so on, because of this notion of leaky abstractions. You can push something in one place and something else is going to pop out in another by just taking a service as it is and making it online. You may not be doing the work required to use it more effectively.

I think that's the kind of thing that Paul is talking about there. What better example of the leaky abstraction is there than somebody sending a disk and not tracking where it goes? Again, the fact that there wasn't any cryptography used is really shocking, but frankly, this is business as usual.

Fremantle: In fact just to completely confirm what you are saying there, the government department that wanted this data did not want the bank account details, the national insurance numbers, or the ages. They didn't want all that data. What actually happened was the revenue and customs team were not sufficiently IT aware to be able to export just the data that was wanted, so they dumped everything onto the disk.

I think that exactly confirms what you are talking about the leaky abstraction. They just pushed out everything, because that was the simplest possible thing to do, when it wasn't exactly what's required, which is what should have been done.

Gardner: So, it does seem clear that the status quo is not sustainable. That there is inherent risk in the current system and that simply retrofitting existing data in turning it on as a service is not sufficient. Either you need to rationalize, think about the data, and generate the ability to slice it and dice it a little better, so that in the case of this disk of vast amounts of information, there was only a small portion of that that was actually required.

Let's look at this also through the lens of, "If we need to change, how do we best do best do that?" Let's look at an example of how someone who needs to view data in a different sense, in a more modern sense, how they are adjusting? Let's go to Brad at Concur. Your organization is involved with helping to improve the efficiency and productivity of travel and management inside of organizations.

Your data is going to come from a variety of areas that probably could be sensitive data in many organizations. Certainly, people are not happy about having their travel information easily available around the organization or certainly outside of it. And, of course there are government and tax implications, compliance, and implications as well. Can you give us a little bit of sense of what your data problem set is and if it's different from what we have heard on the "medieval" front? What sort of approaches you would like to take and have been taking?

Svee: First, I would like to clarify the distinct separation between our research and development team, which actually works on our product that we sell the clients, and my team, which works internally with our internal data.

I would like to draw a distinct clarification between those two. I am only able to speak to the internal data, but what we have found is exactly that that. Our data is trapped in these silos, where each department owns the data, and there is a manual paper process to request a report.

Requesting a customer report takes a long time, and what we have been able to do is try to expose that data through Web services using mashup type UI technology and data services to keep the data in the place that it belongs, without having a flat file flying between FTP servers, as you talked about, and start to show people data that they haven't seen before in an instant, consumable way.

Gardner: So, not even taking that further step of how this data might be used in an extended enterprise environment or across or departmental organization boundaries, just inside your organization, as you are trying to modernize and free up the data, you are looking at this through the lens of availability, real time, lower cost and clip, print, and touch from IT personnel. What sort of technologies and approaches have you been taking in order to try to achieve that?

Svee: For the last year or so, we have been pushing an SOA initiative and we have been evaluating the WSO2 product line, since, maybe November. We have been trying to free up our data, as well as rethink the way all our current systems are integrated. We are growing fairly rapidly and as we expand globally it is becoming more and more difficult to expose that data to the teams across the globe. So we have to jump in and rethink the complete architecture of our internal systems.

Gardner: What is it about the architecture that has a bearing on these flexibility and agility you are looking for, but that also protects your sense of reduced risk, security privacy access control?

Svee: Most of the data that we are dealing with is fairly sensitive, and therefore almost all of it has a need for at least per-user access basis, as well as, when we are transporting data, we will have to make sure that it's encrypted or at least digitally signed.

Gardner: Now, it seems to me that this data will need to be available through a browser-based portal or application to the end users, but that the data is also going to play a role with back office system, ledger, and different accounting activities, as this travel and expense content needs to be rectified across the company's books.

Svee: The browser becomes the ubiquitous consumption point for this data, and we are able to mash up the data, providing a view into several different systems. Before, that was not possible, and the additional piece of moving the file between financial systems, for example, we are able to not have to pull files, but actually use Web services to send only the data that has changed, as opposed to a complete dump of the data, which really decreases our network bandwidth usage.

Governor: There's even potentially a green argument in there. I mean, all of this batch is just kind of crazy and unnecessary. We see a lot of it. There is so much data duplicated everywhere. It seems like we, as an industry, are very good at just replicating and getting ridiculous redundancy, and not so good at synchronizing and really thinking about what data does need to be transported and working with that accordingly.

That sort of makes a lot of sense to me. It's very good to hear you are taking that approach. I think sometimes we miss-call things SOA, when in fact what you are doing is kind of "suck and play." You take this thing, suck old things out, and then work on the new thing, as opposed to actually thinking about the data structures you need to enable the data to be useful and fit you.

Gardner: Let's go to Paul. Now, here is an instance where the organization has, I think, its feet in both camps. In the old style, there is accounting, the ledgers, and data extension across application sets from a common repository, and how to batch that in such a way that the data is all on the same page, so to speak, across these applications in a time frame.

We also need to take this out through Web applications to individuals and also across applications that are Web services enabled. So, it sounds like what we have here is a situation where the data needs to do many different tricks, not just a couple of old basic tricks.

What is it that WSO2 has done recognizing this kind of need in the market and is able to satisfy this need?

Fremantle: What we have built is what we call WSO2 Data Services, which is a component of our application server. The WSO2 Data Services component allows you to take any data source that is accessible through JDBC, MySQL databases, Oracle databases, or DB2, but, in addition, we also have support for Excel, CSV files, and various other formats and very simply expose it as XML

Now this isn't just exposed to, for example, Web Services. In fact, it can also be exposed by REST interfaces. It can be exposed through XML over HTTP, can even be exposed as JSON. JavaScript Object Notation makes it very easy to build Ajax interfaces. It can also support it over JMS, and messaging system.

So the fundamental idea here is that the database can be exposed through a simple mapping file into multiple formats and multiple different protocols, without having to write new code or without having to build new systems to do that. What we're really replacing there is, for example, where you might take your database and build an object relational map and then you use multiple different programming toolkits -- one Web services toolkit, one REST toolkit, one JMS toolkit -- to then expose those objects.

We take all that pain away, and say, "All you have to do is a single definition of what your data looks like in a very simple way, and then we can expose that to the rest of the world through multiple formats."

Gardner: When that data changes on the core database, those changes are then reflected across all of these different avenues, channels, and approaches it's sharing. Is that correct?

Fremantle: Absolutely, because it's being accessed on demand and then exposing them as needed through whichever format they ask for. So, it's not storing those data formats in it's own system,

Governor: One of the things that I really like about this story is that we went through a period where there was a view that everything needed to be done with the WS stack, and the only way to do SOA, the only way to data integration, was to use these large-scale Web standards. But they're not critical in all cases, and it really depends on your requirements for the security and so on. Do you really need SOAP and some of the heavier weight protocols and technology?

I think that the approaches that say, "Let's understand is this behind the firewall? What are the levels of protection that are required?" "Can we do this in a simpler fashion?" are very valuable. The point about JSON, for UI related stuff, certainly REST kind of interfaces, but at the end of the day it's a question of, do you have developers that are available out there in your shop or to hire that are going to be able to do the work that's required and some good examples that came out of the Web world?

If you look at eBay, they had a SOAP API, but nobody used it. A great number, or 80 percent plus, of the calls were using RESTful styles. Understanding the nature of your problem and having more flexibility is very, very important.

Gardner: One of the things that I really like about this is that, almost like Metcalfe's Law. The more participants there are on the network, the more valuable it is. The more people and systems and approaches to distributing data, the more valuable the data becomes. What's been nice is that we've elevated this distribution value with data, at the same time that open source and community-based development have become much more prominent.

That means that the ways in which the data is shared and transferred is not just going to be dependent upon a commercial vendor's decision about which standards to support, but we can open this up to a community where even very esoteric users can get a community involvement to write and create the means for sharing and transferring.

The data can take on many more different integration points, and standards can evolve in new and different ways. Let's discuss a little bit, first with Paul, about the role of open source, community, and opening up the value of data.

Fremantle: I am just a fanatic about open source and community. I think that open source is absolutely vital to making this work, because fundamentally what we're talking about is breaking down the barriers between different systems. As you say, every time you're pushing the proprietary software solution that isn't based on open standards, doesn't have open APIs, and doesn't have the ability to improve it and contribute back, you're putting in another barrier.

Everyone has woken up to this idea of collaboration through Web 2.0 websites, whether through Flickr or FaceParty or whatever. What the rest of the world is waking up to is what open-source developers have been discovering over the last five to ten years. Open source is Web 2.0 for developers. It's how do you collaborate, how do I put my input, my piece of the pie? It's user-generated content for developers, and that power is unbelievable. I think we're going to see that grow even more over the next few years.

Governor: I fundamentally agree with it. Open source was an application of a pattern. Open source was the first real use case for this need for a distributed way of working, and we're certainly seeing that broadened out. People are getting a much, much better understanding of some of the values and virtues of open approaches of exposing data to new sources.

Very often, you will not get the insight, but someone else will, and that sort of openness and transparency, and that's one of the key challenges -- actually just getting organizations to understand some of the value of opening up their data.

I think that is one thing to have to tools to see that. Another is that we all now are beginning to see organizations kind of get it. Certainly, "How do we syndicate our information?" is a really key question. We are seeing media companies ask themselves exactly that. "Do we have an API? How do we build an API? Where do we get an API, so that people can syndicate the information that we have?”

I suppose I'm just double-clicking on what Paul said -- that passion is something that is becoming more and much better understood. Reuters is realizing it has to have an API. The Guardian, which is a British newspaper -- and those Americans certainly of the leftward persuasion are very familiar with it -- now has a team that is also presenting at Web conferences and talking about the API. We've got to think about how to make data more available, and open source will just be the first community to really understand this

Gardner: I'd like to bounce this off of Brad at Concur. Do you feel a little bit less anxious, or more at ease, knowing that whatever data needs that you have for the future, you don't have to wait for a vendor to come up with the solution? You might be able to go and explore what's available in a community, or if it's not available, perhaps write it yourself or have it written and contribute it back to the community. It seems to me that this would be something that would make you sleep better at night -- that an open-source and community-based approach to data services deliverability gives you more options.

Svee: I personally love open source. I think that it is the movement that's going to fix software and all these proprietary systems. I think that my small team, four developers and myself, would not be able to produce the kind of quality products internally that we're essentially asked to do, without being able to stand on the shoulders of a lot of these geniuses out there who are writing amazing code.

Gardner: Do you agree that there is this sense that you can almost future-proof yourself by recognizing, as you embrace open source, that you're not going to get locked in, that you're going to have flexibility and opportunity in the future

Svee: Exactly. I find that there are a few products that we have that we've been locked into for quite some time. It's very difficult to try to move forward and evaluate anything new, when we're locked into something that's proprietary and maybe not even supported anymore. With the open-source community out there, we're finding that the answers we get on forums and from mailing lists are every year getting faster and better. More people are collaborating, and we're trying to contribute as much as we can as well.

Gardner: And, of course, over the past several years, we've seen a tremendous uptake in the use of open-source databases and sources from MySQL, Ingres, Postgres, and there are others. Let's bounce this back now to the WSO2 product set. What is it about, when you are developing your products, Paul, that open source becomes an enabler, as well as, in a sense, a channel into the market?

Fremantle: What was interesting about us developing this data services solution was the fact of what we built on top. The data service's component that we built actually took us very little time to get to its first incarnation, and obviously we are constantly improving it and adding new capabilities.

We were working on that and it didn't take time, but the very first prototype of this was just a piece of work by one of our team who went out and did this. What enabled that really was the whole framework on which it was built, the access to framework, the app server that we built, and that framework built on the work of literally hundreds of people around the world worked on it.

For example, if we talk about the JMS support, that was a contribution by a developer to that project. The JSON support was a contribution by another developer and relied on the JSON library written by someone else. The fact that we can choose the level of encryption and security from HTTPS all the way up to full digital signatures relies on the works of the Apache XML security guys who have written XML security libraries. That's an incredible, complex piece of work and it's really the pulling together of all these different components to provide a simple useful facility.

I think it's so amazing, because you really stand on the shoulders of giants. That's the only way you can put it. What I like about this is to hear Brad say that he is doing the same, we are doing the same, and all around there is a value change of people doing small contributions that, when put together, add up to something fantastic. That's just an amazing story.

Gardner: Given that there are many approaches that Brad, as a user organization, is undertaking, and they dovetail somewhat with what you are doing as a supplier, we also have other suppliers that are embracing open source increasingly and building out product sets that have originated from technology that was contributed or project format or license. How do these pieces come together, if we have a number of different open-source infrastructure projects and the products? I'm thinking about perhaps an ESB, and your data solution, and some integration middleware. What's the whole that's greater than the sum of the parts?

Governor: I certainly have some pretty strong opinions here. I think we can learn a lot from the ecosystems as well. One of the absolutely key skills in open source, as a business, is packaging. Packaging is very, very important to open source, and pulling things together and then offering support and service is a very powerful model.

It's really nothing new. If we look at personal computers, you go out and you can buy yourself chips from AMD or Intel, you can buy an OEM version of Windows or choose to do with Linux, you can buy RAM from another company, you can buy storage disks from another company, and kind of glom it all together.

But, as that industry has shown us, it really makes a lot more sense to buy it from a specialist packager. That might be Dell, HP, or others. I think that open-source software has really got some similar dynamics. So, if you want an Eclipse IDE, you are likely to be buying it from an IBM or a Genuitec or CodeGear, and a couple of those are our clients. I should disclose that.

In this space we've got the same dynamics. If you are, for example, a Web company, and you don't want to be paying these third parties to do that packaging for you, fine. But, for the great mass of enterprises, it really doesn't make that much sense to be spending all your time there with glue guns, worrying about how pieces fit together, even in Eclipse, where it is a very pluggable architecture.

It makes a great deal of sense to outsource that to a third party, because otherwise it's really a recipe for more confusion, I would argue. So yes, you can do it yourself, but that doesn't necessarily mean, you should. The PC example, yes, for a hobbyist or someone who wants to learn about the thing, absolutely, build your own, roll your own. But, for getting on with things in business, it does make sense to work with the packager that's going to offer you full service and support.

Fremantle: I've got to jump in here and say that's exactly our model. Though we don't just offer the data services, we offer, an ESB, a mashup server, and SOA registry, and we make sure all those things work together. The reality is that there are a lot of programmers out there who are hobbyists, so there are a lot of people who do like to take individual components and pieces and put them together, and we support both of those equally, but I think your analogy of the PC market and that plug and play model is absolutely like open source and specifically open-source SOA. We all focus very much on interoperability will make sure that our products work together.

Open source drives this market of components, and it's exactly the same thing that happened in the PC market. As soon as there was an open buy off that wasn't owned by a single company, the world opened up to people being able to make those components, work in peace and harmony, and compete on a level playing field. That's exactly where the open-source market is today.

Gardner: So how about that, Brad? Do you really like the idea that you can have a package approach, but you can also shake and bake it your own way?

Svee: That's exactly the sweet part in my opinion. I can shake and bake, I can code up a bunch of stuff, I can prototype stuff rapidly, and then my boss can sleep well at night, when he knows that he can also buy some support, in case whatever I cook up doesn't quite come out of the oven. I see there's a kind of new model in open source that I think is going to be successful because of that.

Gardner: Okay, now we have seen some very good success with this model: have it your way, if you will, on the infrastructure level. We are moving up into data services now. It seems to me that this also sets us up to move an abstraction higher into the realm of data portability. Just as we are seeing the need in social networks, where the end user wants to be able to take their data from one supplier of a social networking function to another, I think we are going to start to see more of that in business ecologies as well.

A business will not want to be locked into a technology, but it also doesn't want to be locked into a relationship with another supplier, another business. They want to be able to walk away from that when the time is right and take their data with it. So, maybe we'll close out our discussion with a little blue-sky discussion about this model taking a step further out into the cloud. Any thoughts about that, Paul?

Fremantle: I think that's a really interesting discussion. I was at a conference with Tim O'Reilly about two years ago and we were having exactly this discussion, which is that openness of services needs to be matched by openness of data. We are definitely seeing that in the Web marketplace through back-end systems like Amazon S3 storage, and we are beginning to see a lot of other people start to jump on this and start to build open accessible databases.

I think that's an absolutely fantastic usage for this kind of data service, which is to say, "It's my data. I don't just want to host things in an open fashion. I don't want to write code in an open fashion. I want open services and open data, so I can get it, move it, protect it myself, and relocate it."

So, I think there's a really interesting idea behind this, which is, once we get to the point where your data is no longer tied to a specific system and no longer has to be co-located with a particular MySQL database, we start to free up that processing. If you look at what Amazon did with the Elastic Cloud Service and their storage system, the storage system came first. The data services were a precursor to having an effective cloud-computing platform. So, it's really a precursor. You have to have data services, before you can start to migrate your processing and scale it up in this fashion.

Gardner: What do you think, James? Is this something that will be in great demand in the market, and there is also a green angle here?

Governor: Yeah, I think undoubtedly it will. Simon Phipps from Sun talks about the freedom to leave. We had a big example recently, Comcast buying Plaxo. They have lost a lot of the users. A lot of Plaxo users just closed up their account there. Interestingly enough, Plaxo had a nice function to do that -- very good for closing the account, not so good for exporting the data. I am not so sure the problems are primarily technical. I think there are a great deal of policy and social problems that we are going to have to deal with.

It's very interesting to me that we call people heroes that are trying to break Facebook terms of service, in some cases with the recent data portability example. We've got some really key challenges about what does data ownership mean. From my perspective, as I said earlier, I think it's very important that we have the mechanisms whereby we have access to data without necessarily allowing replication of it all over the place.

If it is your data, then yes, by all means, you should have permission to take a copy of it. What about if you're on a network and you want to take all the data and all of the surrounding metadata? Really, the discussion becomes about that metadata. Am I allowed to get anything back from Google about my behaviors and other people's behaviors?

It's really a social question, and we, as a society or a number of different societies, have got to think about this, and what we want from our data, what we want from privacy, and what we want we want from transparency. We can gain wonderful things, I mean wonderful advantages, but there is also the flip side, and I think it's very important that we keep that in mind.

So, it's going to be a wild ride. It's exciting, and I think that it is important that we get the tools in place, so that once we get the policies well understood, we can actually begin to do things more effectively. So, again, it's very exciting, but there are a lot of threats and lot of risks that we do need to take account of. Those risks are expanded, as I say, by what I sometime call "information bulimia." This notion that we just keep eating and swallowing more and more information and more data and we need more information, and if you do that, what you end up doing is puking it all up.

Gardner: Let's close here with that real-world perspective, Brad, aside from the visual image of puking, does this interest you in terms of the idea of third-party neutral cloud-based data and does that have any bearing on your real-world issues?

Svee: Well, I can give you an example what we were able to do with data services. Within a matter of weeks, not even months, we are able to use the data services in the application server from WSO2 to essentially give a complete client picture to the business by reaching into the ERP system, pointing out invoices and products, and then reaching into the CRM system to pull out open issues, as well as, sales manager, probably about 50 data points about each customer from the CRM, and then expose those services through a simple JSON-based UI with a smart type-ahead for the customer name. Quickly, we are able to show a picture of our clients that hadn't previously been available -- and within a matter of weeks actually.

Gardner: That data could have come from any number of different sources if, to James' point, you had the proper permissioning?

Svee: Yeah, and since we are IT and we own the systems, we are able to determine who is who, and we were able to use a Web service, another data service into our HR system, to pull out roles to see whether or not you could access that information.

Gardner: That's highly valuable from a productivity and planning perspective. If you are a business strategist, that's precisely the kind of information you want?

Svee: Exactly, and they were amazed that they've had been able to live their lives without it for so long.

Gardner: Paul, do you think much of this common view business, when it comes to data services?

Fremantle: Actually, we are working on another project with a health-care provider, which is providing a single patient view. So, it's exactly the same kind of scenario with significant security and encryption and data challenges to make sure that you don't provide the wrong information to the wrong person. Obviously, all the same issues need to be solved, and being able to pull together everything that is known about a patient from multiple different system into a single view once again has huge value to the organization.

Gardner: Well, this has to be our swan song on this particular podcast. We are out of time. I want to thank our guests for helping us get into a nice far-reaching discussion about data services, what the problem set has been, what the opportunity is, and how at least one organization, Concur, is making some good use of these technologies. We have been joined by Paul Fremantle, chief technology officer at WSO2. Thank you, Paul.

Fremantle: Thank you, it has been great fun.

Gardner: I also strongly appreciate your input Brad Svee, IT manager of development at the Redmond, Wash.- based Concur. Thank you, Brad.

Svee: Well, thank you.

Gardner: And always, thank you, James Governor from RedMonk for joining. We appreciate your input.

Governor: Thank you much. It has been an interesting discussion.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect Podcast. Thanks and come back next time.

Listen to the podcast. Sponsor: WSO2.

Transcript of BriefingsDirect podcast on data services, SOA and cloud-based data hosting models. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.