Webinar: Modernization Pulls New Value From Legacy and Client-Server Enterprise Applications

Transcript of a BriefingsDirect webinar with David McFarlane and Adam Markey on the economic and productivity advantages from application modernization.

Listen to the podcast. Download the podcast. Find it on iTunes/iPod and Podcast.com. Learn more. Sponsor: Nexaweb Technologies.

Announcer: Hello, and welcome to a special BriefingsDirect presentation, a podcast created from a recent Nexaweb Technologies Webinar on application modernization.

The webinar examines how enterprises are gaining economic and productivity advantages from modernizing legacy and older client-server applications. The logic, data, and integration patterns' value within these older applications can be effectively extracted and repurposed using tools and methods, including those from Nexaweb. That means the IT and business value from these assets can be reestablished as Web applications on highly efficient platforms.

We'll learn how Nexaweb has worked with a number of companies to attain new value from legacy and client-server applications, while making those assets more easily deployed as rich, agile Web applications and services. Those services can then be better extended across modern and flexible business processes.

On this podcast, we'll hear from Dana Gardner, principal analyst at Interarbor Solutions, as well as David McFarlane, COO at Nexaweb, and then Adam Markey, solution architect at Nexaweb.

First, welcome our initial presenter, BriefingsDirect's Dana Gardner.

Dana Gardner: We're dealing with an awful lot of applications out there in the IT world. It's always astonishing to me, when I go into enterprises and ask them how many applications they have in production, that in many cases they don't know. In the cases where they do know, they're usually off by about 20 or 30 percent, when they go in and do an audit.

In many cases, we're looking at companies that have been around for a while with 10 or 20 years worth of applications. These can be on mainframe. They can be written in COBOL. They could be still running on Unix platforms. In a perfect world we'd have an opportunity to go in and audit these, sunset some, and re-factor others.

Today, however, many organizations are faced with manpower and labor issues. They've got skill sets that they can't bring in, even if they wanted to, for some of these older applications. There is, of course, a whole new set of applications that might not be considered legacy, but that are several years old now. These are N-tier and Java, distributed applications, .NET, COM, DCOM, a whole stew in many organizations.

What I am asking folks to do, now that we're into a situation where economics are probably more prominent than ever -- not that that's not usually the case in IT -- is to take a look at what applications are constraining their business. Not so much to worry about what the technology is that they are running on or what the skill sets are, but to start factoring what new initiatives they need to do and how can they get their top line and bottom line as robust as possible? How do they get IT to be an enabler and not viewed as a cost center?

This is really where we should start thinking about modernizing and transforming IT -- getting application functionality that is essential, but is in someway handicapping what businesses want to do.

We want to exploit new architectures and bring more applications into association with them. It's not just architectures in terms of technology, but approaches and methodologies like service-oriented architecture (SOA), or what some people call Web-oriented architecture (WOA), looking to take advantage of interfaces and speed of innovation so that organizations can start to improve productivity for their internal constituents, in this case usually employees or partners.

Then, increasingly because of the difficulty in bringing about new business during a period of economic downturn, they're reaching out through the Internet, reaching out through the channels that are more productive, less costly and utilizing applications to focus on new business in new ways.

SOA and mobile devices

Increasingly, as I mentioned, this involves SOA, but it also increasingly involves mobile. We need to go out and reach people through their mobile Internet devices, through their iPhone and their BlackBerry, and a host of other devices at the edge. You need to be able to do that with applications and you need to be able to do it fast.

So, the goal is flexibility in terms of which applications and services need to reach new and older constituencies at less cost and, over time, reduce the number of platforms that you are supporting, sunset some apps, bring them into a new age, a new paradigm, and reduce your operating costs as a result.

Information really is the goal here, even though we are, with a handful of applications, starting to focus on the ones that are going to give us the biggest bang for the buck, recognizing that we need to go in and thoughtfully approach these applications, bring them into use with other Web services and Web applications, and think about mashups and Enterprise 2.0 types of activities. That involves expanding the use of these new methodologies.

One of the things that's interesting about companies that are aggressively using SOA is they also happen to be usually aggressive in using newer development platforms and tools. They're using dynamic languages, Web interfaces, and rich Internet application (RIA) interfaces. This is what's allowing them to take their newer applications and bring them into a services orientation reuse. Some of those services can be flexible and agile.

That's not to say you can't do some of those things with the older applications as well. In many cases, tools are being brought about and third-party inputs, in terms of professional services and guidance, are coming around. I'm recommending to people to respond more quickly, to save operational costs, to get agile and reach out through these new edge devices and/or the Internet, and do it in a fairly short order.

It's amazing to me that for those companies that have moved in this direction, they can get applications out the door in weeks rather than months, and in many cases, you can transform and modernize older applications on aging platforms just as quickly.

We want to move faster. We want to recognize that we need a higher payoff, because we also recognize that the line-of-business people, those folks that are tasked with developing new business or maintaining older business, are in a rush, because things are changing so quickly in the world around us. They often need to go at fast-break or breakneck speed with their business activities. They're going to look at IT to be there for them, and not be a handicap or to tell them that they have to wait in line or that this project is going to be six to eight months.

So, we need to get that higher agility and productivity, not just for IT, but for the business goals. Application modernization is an important aspect of doing this.

How does modernization fit in? It's not something that's going to happen on its own, obviously. There are many other activities, approaches, and priorities that IT folks are dealing with. Modernizing, however, fits in quite well. It can be used as a way to rationalize any expenditure around modernization, when you factor in that you can often cut your operating costs significantly over time.

You can also become greener. You can use less electricity, because you're leveraging newer systems and hardware that are multi core and designed to run with better performance in terms of heat reduction. There are more options around cloud computing and accessing some services or, perhaps, just experimenting with application development and testing on someone else's infrastructure.

By moving towards modernization you also set yourself up to be much more ready for SOA or to exploit those investments you have already made in SOA.

Compliance benefits

There are also compliance benefits for those organizations that are facing payment-card industry (PCI) standards in financial or other regulatory environments, freeing up applications in such a way that you can develop reports, share the data, and integrate the data. These are all benefits to your compliance issues as well.

As I mentioned earlier, by moving into a modernization for older applications, you've got the ability to mash up and take advantage of these newer interfaces, reuse, and extended application.

There is a whole host of rationalizations and reasons to do this from an IT perspective. The benefits are much more involved with these business issues and developer satisfaction, recognizing that if you are going to hire developers, you are going to be limited in the skill sets. You want to find ones that are able to work with the tools and present these applications and services in the interfaces that you have chosen.

Keeping operations at a lower cost, again, is an incentive, and that's something they can take out to their operating and financial officers and get that backing for these investments to move forward on application modernization and transformation.

One of the questions I get is, "How do we get started? We've identified applications. We recognized the business agility benefits. Where do we look among those applications to start getting that bang for the buck, where to get modern first?"

Well, you want to look at applications that are orphans in some respect. They're monolithic. They're on their own -- dedicated server, dedicated hardware, and dedicated stack and runtime environment, just for a single application.

Those are good candidates to say, "How can we take that into a virtualized environment?" Are there stacks that can support that same runtime environment on a virtualized server, reduce your hardware and operating costs as a result? Are they brittle?

Are there applications that people have put a literal and figurative wall around saying, "Don't go near that application. If we do anything to it, it might tank and we don't have the documentation or the people around to get it back into operating condition. It's risky and it's dangerous."

Conventional wisdom will say don't go near it. It's better to say, "Listen, if that's important to our business, if it's holding our business back, that's a great target for going in and finding a way to extract the logic, extract the data and present it as something that's much more flexible and easy to work with."

You can also look for labor issues. As I said, if skills have disappeared, why wait for the proverbial crash and then deal with it? It's better to be a little bit proactive.

We also need to look at what functional areas are going to be supporting agility as these business requirements change. If you're an organization where you've got supply chain issues, you need to find redundancy. You need to find new partners quickly. Perhaps some have gone out of business or no longer able to manufacture or supply certain parts. You need to be fleet and agile.

If there are applications that are holding you back from being able to pick and choose in a marketplace more readily, that's a functional area that's a priority for getting out to a Web interface.

Faster, better, cheaper

People are going to be looking to do things faster, better, cheaper. In many cases those innovative companies that are coming to market now are doing it all through the Web, because they are green-field organizations themselves. They are of, for, and by the Web. If you're going to interact with them and take advantage of the cost, innovation, and productivity benefits they offer, your applications need to interrelate, operate, and take advantage of standards and Web services to play with them.

You also need to take a look at where maintenance costs are high. We've certainly seen a number of cases where by modernizing applications you have reduced your cost on maintenance by 20 or 30 percent, sometimes even more. Again, if this is done in the context of some of these larger initiatives around green and virtualization, the savings can be even more dramatic.

I also want to emphasize -- and I can't say it enough -- those SOA activities shouldn't be there for just the newer apps. The more older apps you bring in, the more return on investment you get for your platform modernization investments, as well as saving on the older platform costs, not to mention those productivity and agility benefits.

We also need to think about the data. In some cases, I have seen organizations where they have applications running and aren't really using the application for other than as an application repository for the data. They have a hard time thinking about what to do with the data. The application is being supported at high cost, and it's a glorified proprietary database, taking up app server and rack space.

If you're looking at applications that are more data centric in their usage, why not extract that data, find what bits of the logic might still be relevant or useful, put that into service orientation, and reduce your cost, while extending that data into new processes and new benefits.

It's also important to look at where the technical quality of an app is low. Many companies are working with applications that were never built very well and never performed particularly well, using old kludgy interfaces. People are not as productive and sometimes resist working with them. These are candidates for where to put your wood behind your arrow when it comes to application modernization.

In beginning the process, we need to look at the architecture targets. We need to think about where you're going to put these applications if you are refactoring them and bringing them into the Web standards process.

It's important to have capacity. We want to have enough architecture, systems, and runtime in place. We should think about hosting or collocation, where you can decrease your cost and the risk of capital expenditure, but at the same time, still have a home for these new apps.

You certainly don't want to overextend and build out platforms without the applications being ready. It's a bit of a balancing act -- making sure you have enough capacity, but at the same time performing these modernization transformation tasks. You certainly don't want to transform apps and not have a good home for them.

Also important is an inventory of these critical apps, based on some of the criteria, we have gone through.

Crawl, walk, run

The nice thing about creating the categorization is that once you've got some processes in place on how to go about this, with one application you can extend that to others. The crawl-walk-run approach makes a great deal of sense, but when you've learned to crawl well, extend and reuse that to walk well, and then scale it from there.

This construction, deconstruction, rationalization process should also be vetted and audited in the sense that you can demonstrate paybacks. We don't want to demonstrate cost centers becoming larger cost centers. We want to show, at each step of the way, how this is beneficial in cost as well as productivity. Then, we need to focus continually on these business requirements, to make a difference and enhance these business processes.

There are some traps. It's easier said than done. It's complicated. You need to extract data carefully. If you start losing logic and access to data that are part of important business processes, then you're going to lose the trust and confidence, and some of your future important cost benefit activities might be in jeopardy.

It's important to understand the code. You don't want to go and start monkeying around with and extracting code, unless you really know what you're doing. If you don't, it's important to get outside help.

There are people who are not doing this for the first time. They've done it many times. They're familiar with certain application types and platforms. It's better to let them come in, than for you to be a guinea pig yourself or take trials and tests as your first step. That's not a good idea when you're starting to deal with critical and important application.

Stick to processes and methods that do work. Don't recreate the wheel, unless you need to, and once you have got a good wheel creation method, repeat and verify.

You need to be rigorous, be systemic, and verify results, as we have said. That's what's going to get you those transformational benefits, rather than piecemeal benefits. You're going to see how application modernization fits into the context of these other activities, You're going to be well on the way to satisfying your constituencies, getting the funding you need, and then seeing more of your budget going to innovation and productivity and not to maintenance and upkeep.

There are a lot of great reasons to modernize, and we have mentioned a number of them. There are backwards and forwards compatibility issues. There are big payoffs in cost and agility, and now it's time to look at some of the examples of how this has been put into place.

Announcer: Thanks Dana. Now, we'll hear from David McFarlane, COO at Nexaweb, on some use-case scenarios for adopting and benefiting from these application modernization opportunities. Here is David McFarlane.

Understanding value

David McFarlane: We're going to go a little bit deeper and actually take a look at a case study of one of our clients, one of our successful implementations, and see the value that came out of it.

To really understand what value is, we have to understand how we're going to quantify it in the first place. We're probably all in IT here, and we're probably all IT heads, but we have to take a step back, take a top-down approach, and understand how we define that value in the business.

As Dana said earlier, application modernization impacts all areas of your business, and the three areas that it really impacts are business, operations, and IT. So, you have to step outside your role. You have to see what value the business would see out of it, what operations would see out of it, and also for yourself in IT, what gains and benefits you would get out of that. When you add them all together, you get the overall value for that application modernization.

Let's take a look at a real case study as an example. Just to set some background, we have a legacy system, a customer relationship management (CRM) call center application for one of our clients. They have about five call centers, with around 50 employees, and they're on a C++ client-server application.

The important thing to note about this is that, in legacy systems, there are usually multiple instances of this application. Since it's a client-server app, we have to remember that it's also deployed and managed on each individual desktop. Each individual employee has their own installation on their desktop, which is sometimes a nightmare to manage for most IT shops.

We took that system and built a modernized system with it. We had a J2EE architecture with desktop browser look and feel, as Dana talked about earlier. You get that real performance out of the installed client-server application, but it's delivered over the Web via zero client install.

You don't have to do anything besides update your Web server, and everybody automatically has the new application, the new look and feel, the new business logic, and access to whatever data you've hooked it up to on the backend.

Also important is the ability of our system that we modernized to be deployed as an open standard. We used J2EE architecture, and that means we're able to integrate with anything that you have on your back end via open Java application programming interfaces (APIs).

There is a vast array of open source products out there waiting to be used, to be integrated, and to modernize systems. There's also a large workforce that will be able to understand a Java application as opposed to a custom C++ application or even a COBOL application. We also consolidated it to one distributed instance, since we can now manage it centrally from one data center.

ROI analysis

When you're doing a modernization, you're probably going to have to do some sort of return on investmment (ROI) analysis to understand exactly what you're going to get out of this application, and that's going to take some time.

If you're coming from an IT perspective, you might have most of the benefits already in your head: "I'll have people using Java instead of COBOL. I'll have all the developers focused on one development language, instead of multiple development languages. I'm going to be able to decrease by deployment time, etc."

But, when justifying something like this, you need to take a step back, and as we said before, look at the factors in these three areas that are most affected by application modernization. As Dana pointed out, it's business operations in IT. So, we go ahead and look at the business.

We have to ask a few questions here: "Who are my users? How long does each transaction take?" Say I'm a call center and it takes few minutes for a user to get through a transaction, if I can cut that to one-and-a-half minutes or even one minute, I'm able to increase productivity significantly.

The next part is operations. How is that productivity increased, but also what does it mean to have a modern application infrastructure? If previously I had to come in to work and sit down at my desktop, because that's the only place that application was installed, maybe I don't even need to come in to work anymore. Maybe I can work from home. Maybe I can work from India, if I want to, as long as I have VPN access into that sort of an application. You can begin to see the operational flexibility that you get out of that.

Then, as we look into the IT benefits that we have here, how long did it take to make a change to my legacy system? One of the biggest benefits that we're seeing is when coming from legacy C++ PowerBuilder applications, where you really have to code each and every aspect of the user interface (UI), the business logic, and the specific data interaction, because we don't have SOA to leverage, and we don't have hooks into services that we've built or are planning to build in our application.

Also, we have to think of what the developer actually had to do to make that change. In older technologies, they might not have a way to prototype the UI and show the business users feedback before they are able to get sign off on what they're going to build. They might have to program each and every element of the user interface, all the way down to writing SQL stored procedures that are application-specific to a database.

Going to a modern architecture, you're going to have services and you're going to have your object-relational management capabilities. You're going to have some great middle-tier applications like Spring and Struts to enhance the development. Obviously, with Nexaweb technologies, you have that ability to create the declarative user interfaces, which speeds up UI development time significantly.

Also we have what hardware and software do the application run on, and what licenses am I paying for? As Dana pointed out earlier, you'll have a significant opportunity for maintenance savings, when you go to a modern architecture.

Productivity gains

We asked all these questions, and we found some significant areas of value in our CRM modernization case. In the business we actually saw a 15 percent gain in end-user productivity, which impacted our clients by about $1.5 million a year. In these times, you're actually able to slim down or trim your workflow if you have a more productive application. In this case, which are the productivities that are able to do more calls quicker, service customers quicker? Ultimately, that ends up in end user satisfaction and dollars saved as well.

Next, you have the operational value. What we had here was a decrease in audit time. We found that their auditors were going around to each individual desktop and seeing exactly which applications were installed on their computer. They had to look at each of the five instances in each call center for auditing, instead of looking at one consolidated instance, with just one database and book of record for all the operation there. So, that saved a lot of auditing time for them, which is really great.

Another thing was that it improved the performance of another help desk. This was a help desk for customer support, but the internal IT help desk actually saw huge improvement. Because the application was centrally managed, all people had to do was go to a Website or click a link to access that application, instead of having to install software. As you know, when you install software, a ton of things can happen. You actually have to do a lot of testing for that software as well. All that has been reduced, and we're saving about $15K there.

When you look at the IT benefits, we have that IT developer productivity gain that we talked about. We eliminated some hardware and software for those five instances and some of that maintenance cost. So, that's and $85K impact. There are the deployment benefits of a RIA, when you're going from deploying applications on 250 computers to zero computers. You're going to see an immediate impact there, and that was around $250K for the time to do that, the software that it took to push that out, and for the support that it needed to run.

Because of the change management benefits from RIAs, the development productivity, and the ability to go from requirements to design, to testing, to production much more quickly than a client-server application, we're able to see a 90 percent gain there, which had a $200K impact.

When you look at it in total, the yearly bottom line improvement was about $2.23 million for this one instance, with one time improvement of $85K for the hardware and the software that we got rid of. It was only a one-time investment of about $800K.

I say "only," but if you look at the business, operational, and the IT impacts together, you get payback in the first full year. If you were only coming from that IT perspective, you would have seen that the payback is actually a little bit longer than a year.

If you add all those numbers up, you get something a little less than $800K, about $700K, I believe. That will be about 14- or 15-month payback instead of about a 5- or 6-month payback. When you're trying to make a case for modernization, this is exactly what your CFO or your CEO needs to know -- how it affects your bottom line from all areas of the business, not just IT.

Let's not forget the intangibles that come with application modernization. It's always about the bottom line. There are some great things that you get out of a modern application infrastructure, and the first thing you get, when you look at the business, is improved response time.

Happier CSRs

The number one thing I could think of is that your customer service representatives (CSRs) are going to be happier, because once they click a button, it's not going to take two seconds to respond like the old application. It's going to be fast. It's going to be rich. You're not going to have any installation issues when you do an upgrade. It's going to be smooth.

You're going to have happier CSRs. Having happier CSRs means that you're going to have improved customer service, and a customer satisfaction level, when people get calls through quicker, and when people talk to happy customer service representative.

Also, when you're doing application modernization, you have a good opportunity to automate manual portions of the business process. You can go in and say, "This person is cutting and pasting something into an Excel spreadsheet, and emailing this to somebody else as a report after they're done." Maybe there's an opportunity there to have that done automatically. So, it saves them time again. That's where you can really find your increased productivity.

When we look at operations, we actually enabled real estate consolidation. I didn't put those numbers in the ROI, because they were probably going to do that anyway, but it was an enabler. Having a technology to go from five call centers to one call center with distributed agents across the country and across the world saves the business a lot of money on the real estate, the power, and the infrastructure needed to have five call centers up and running.

Again, you get the workforce flexibility, because I can work from home, work from India, or come and work from the office. I could do this job from anywhere, if I have access to this application. Obviously, we're able to bring outsourced call centers online on-demand with that.

Then, we move on to IT. As I said before, it's short release cycles with more functionality. When release cycles are shorter, you can incrementally build in more features to your application, make people more productive, and make the application do more in less time, which is obviously what we want to do.

We have a standardized J2EE architecture, which means the people that you're going to look for to maintain the application are going to be out there. There is a huge number of Java developers out there waiting and ready to come in to maintain your application.

We're built on open standards to ensure that the application is ready for the future. There are a lot of RIA technologies that try to lock you in to one runtime and one development methodology. We use open standards as much as we can to push your application out the door as fast as possible, and be as maintainable as possible, and as ready for the future as possible.

Announcer: Thanks, David. Now, we'll hear from Adam Markey, solution architect at Nexaweb, on specific deployment examples of application modernization projects. Here, then, is Adam.

Enterprise-wide value

Adam Markey: As we look at these different customer examples, we really want to see how they've had an impact of value across the enterprise, and see, from a business point of view, the ability to be able to increase market reach, improve user productivity, decrease the time to market, increase customer engagement and loyalty, and sustain, if not build upon, that competitive advantage.

We also want to look at the operations as well and understand how this new architecture has actually realized benefits in terms of a reduced real estate, greater utilization of global workforce, reduction in energy, moving to green architectures, and improving the overall vendor management.

For those closely responsible for the organization and who deliver this capability, we want to look at IT and how this process helps deal with the rapidly changing demographics in the IT skills market. As the baby boomers move on and out of or off the job market, many of the legacy skills that we relied on so heavily through the years are becoming very rare and hard to find within the organization.

We'll take a look at that process efficiency, and generally how we can improve the overall efficiency and cost in terms of licenses and the use of open source. So, let's take a closer look at a few examples to help illustrate that. There's nothing wrong with your screens here. This first example is actually an example of the modernization of a Japanese phone exchange trading platform.

In this case, this was a trading platform built by Enfour, Bank of Tokyo-Mitsubishi (BTM). The challenge that BTM had was that, once they were capable of satisfying their large corporate customers with their on-premises foreign exchange trading platforms, the small- and medium-sized enterprises (SMEs) were quite different in terms of what they required.

They needed a UI and an application that was much simpler for them to adopt. They didn't have the necessary IT infrastructure to be able to establish the complex on-premises systems. They needed something that had no IT barriers to adoption.

What we did for BTM with our partner Hitachi was to help modernize and transform the entire trading platform to the Web. Just to stress, this isn't simply an information portal, this is a fully functioning trading platform. There are over 500 screens. It's integrated to a 120 different data sources with very stringent service-level requirements to the deployment of the application.

We needed to be able to display any fluctuations and exchange right from the Reuters feed in 200 milliseconds or less. We needed to be able to complete a close loop transaction in two seconds or less.

So, this is a fully functioning trading platform. What's it's meant for BTM is that they've been able to dramatically increase the adoption and penetration into the SME market. Fundamentally, these SME or institutional traders don't need any architecture whatsoever, just a browser. There is no client installation. They're able to self-serve, which means they can simply enter the URL, log in, and get started. This has been a tremendous cost reduction and also revenue growth for this product line in penetrating this new market segment.

In the same field of foreign exchange trading, we were able to help a number of Japanese banks take their products and services global. Traditionally, the market had been very service-intensive through a call center. You dialed in and placed your trade with the trader over the phone. By being able to move this entire platform to the Web, we allowed them to go global and go 24/7.

Now, we have over 30,000 institutional traders using this trading platform and application to self-serve through operations, not just in Tokyo, but in Singapore, London, New York, Frankfurt, literally around the world.

New capabilities

Not only has it extended the product line with very little additional operational cost to the banks, but it's also allowed them to provide new capabilities to those customers. One, for example, is the ability to be able to run continuous global book.

In the traditional implementations of trading platforms, each one would be an on-premises installation, which meant that each region would actually have to close their books and close out their operations at the end of their working day. Because it's now managed and provisioned in system, it can actually run globally, and allows them to maintain those books, and maintain common alerts across entities that themselves have a global footprint.

Not only were we getting them to a new market, but we were also allowing them to introduce new functionality. It allowed them to interact more closely with the customers, providing real-time chat facilities, and allowing the traders in Japan to interact directly with a trader as they exhibited certain behavior. It allowed them to offer custom contracts and has significantly increased the close rate of those applications.

So, a big impact in terms of market reach for the banks in Japan is one example. Let's take a look here at how we've been able to dramatically improve user productivity and dramatically reduce the business process time for large organizations.

This is a representation for one of the largest telecommunications groups in Europe. The challenge that they were facing is that they had a request for proposal (RFP) process that was very complicated. They had to be able to provide quotations for countrywide mobile platforms, a very large, complex design process, which was performed through one application, one legacy application as a product configurator.

Then, they would go to another application for doing the parts costing and bill of material assessment, another application for the pricing, and finally, an overall RFP approval process for these large $100 million-plus projects running over 10 years.

The whole process was taking them anywhere up to four weeks. It was fragmented. It was error prone. There were spreadsheets, and the files were flying around the globe, trying to complete this process.

What we were able to do for this organization was to streamline the process and present it as a single-branded Web-based workflow that brought all the different elements together, and, most importantly, ran on top of a SAP NetWeaver infrastructure. In fact, the workflow was designed to have an SAP look and feel.

End users didn't know when they were in or outside of SAP. They didn't care and they didn't need to, because as an end-to-end process, SAP acts as the overall system of record, providing a much higher degree of control, accuracy, and a dramatic reduction in errors.

The great result, from a user productivity point of view, is that they've been able to go from a process that took four weeks to a process that now takes four hours or even less -- a dramatic reduction. More important was the ability to increase the accuracy of these processes.

Desktop-like experience

These Web applications, I should stress, are really a desktop-like experience for the end user. We think of them and talk about them as a desktop in a browser. Everything that you could do as a desktop application with all the user navigation and productivity in very intense data environments, you can do in a browser-based application as deployed in this solution.

Let's take another look at another example where Web architecture and rich Web interfaces allowed us to dramatically improve customer loyalty and customer engagement.

You maybe familiar with the concept of the extended enterprise, whereby more and more organizations need to be able to open up traditionally back-office processes, and back-office systems still managed on the sort of green screen UIs in the bowels of the company. In order to be able to truly engage their customers and improve the process flow, more and more of those systems are being opened up and presented to their customers through rich, engaging Web applications.

This is an example of that. This is a company in the Netherlands called Waterdrinker, which is actually the largest flower distributor in Europe, a very significant business for them. We were helping them to create a Web-based, self-service ordering process that dramatically reduces the dependency on the use of customer service reps. It was similar to the scenario for the foreign-exchange trading platform. We were actually migrating customer interaction to the self-served Web platforms without the need for human intervention and costly CSRs.

But, it's much more than that. We're providing a much richer experience for the user, a much more engaging experience for the user, where they're able to more dynamically navigate through the catalog and determine the optimal order for them with all kinds of what-if calculations and analysis that are provided for them in real time at their own discretion.

The net result has been a significant increase in customer satisfaction, engagement, loyalty, We're yet to see it, because it's still relatively new, but just based on the amount of response reaction and conversion that we have seen through these Web-based interfaces, loyalty benefits will follow soon after. In addition, with a Web-based UI, you're able to easily and effectively customize the user interface with different users and communities.

In this case, they're able to provide a custom UI solution that integrates their catalog ordering process into their partners' processes. They distribute through local partners and local Websites, and they're able to provide this architecture as a white-label capability and then brand it according to the local distributor, delivering a rich branded experience through their partner.

Let's talk generally about competitive advantage. Obviously, all those things that we have talked about and shown with regard to different customers, and Dana has talked about in aggregate, offer all kinds of competitive advantage.

But, there's a certain element to competitive advantage that I would like to emphasize in this transformation process. Organizations, through the years, have basically instantiated and codified their best practices in the workflows within those legacy systems. Those business rules represent years of intelligence and competitive intelligence, and often the point at which you can realize tremendous competitive advantage.

Razor-thin margins

This is never truer than in the razor-thin margins of the consumer packaged goods (CPG) business, where a lot of the margin for a customer can actually be determined through the appropriate inventory, logistics, and pricing management, literally as goods are on route. What we've done for customers like these is to enable them to quickly and effectively extract the business rules that are buried in the legacy systems.

Frankly, nobody knows how they work anymore. They're not really very well documented at best, but we have allowed them to extract those business rules that represent the competitive advantage and consolidate them into a set of corporate-wide rules that can be more effectively managed.

One issue in a traditional legacy environment is that, as you establish business rules in terms of the legacy implementation, each one is monolithic. They start to create their own derivatives, as people program, tweak, and modify. At the end of a 10-year process, the rules barely resemble each other in each of the iterations.

In our transformed architecture, we're able to provide an environment, in which you can centrally manage, control, and modify those business rules and have them consistently and immediately applied across all the necessary touch points. Through this process, we can dramatically reduce human error.

This architecture allows us to provide support tools and business rules in a form that's readily accessible to the end user. You might say, "Wait a minute. It's a Web-based application, and when I'm sitting face to face with my customers, I'm not going to have access to the Web."

As you would expect in these solutions, we're able to architect them, so that the same application can be deployed as a Web application, or used as standalone. A great example of that is Aflac, where we created their premium calculation solution that is basically used across all the customer touch points, 38,000 users. And, 6,000 of those are agents who go door-to-door.

Part of the architecture and part of the challenge was to deliver that insurance calculation solution in such a way that when the agent is sitting across the kitchen table from their customer, they could still perform a level of custom quotation. They could produce the necessary documentation to be able to close the customer there and then as a standalone laptop with a local printer right across the kitchen table. That's all part of bringing those business rules that represent the years of competitive advantage successfully to the Web.

Let's take a look at how some of these capabilities impact the operations themselves. Here, we'll take an example of a call-center application. This was a transformation for the Pepsi bottling group of their customer-equipment tracking system It was a PowerBuilder application, maybe 10 years old, that we successfully moved to the Web.

The real business value in this is that by doing this, by creating a Web-based environment that could be deployed in any call center, we provide the flexibility and the agility for organizations to better utilize those call centers and better utilize that real estate, often consolidating from a large number of call centers to a smaller set of agile call centers, where they can put a lot of different processes through the same infrastructure.

Cost-management advantage

This has tremendous advantages, as you can imagine, in terms of cost management for those customers. We're even able to take that to the next step with the advent of voice-based telephony. It's now possible to engage home-office operators through a voice over Internet protocol (VoIP) infrastructure.

Those operators can not only have the benefit of the call center application as a Web based application accessible through their home broadband, but actually can have the same level of computer telephony integration (CTI) that they would have had, if they sat in the call center, by virtue of a series of VoIP based CTI technology that's available.

This is offering tremendous operating improvements in terms of, for example, real-estate consolidation. Also, looking at operations and the ability to optimize the use of the workforce, we have a situation here where we deploy a very complex laboratory information-management solution for the AmeriPath, now part of Quest Diagnostics. This is part of a pathology services process that requires very experienced technicians to participate.

The joy of being able to deploy this as a Web-based application means that you get great skills mobility, which means that technicians from anywhere, provided they have Web access, can actually participate in a diagnostic process, without the need to move the sensitive Health Insurance Portability and Accountability Act (HIPAA) data. So, HIPAA data that has to be stored in one place, can be made accessible to technicians through any location who can participate then in a process 24/7.

The value to IT is manifold. We'll take a quick look at some of those before we jump into the value equation itself. This is an example with SunGard Shareholder Systems, where they wanted to modernize their commercial product line, a 401k management application. I'm sure they're pretty busy these days.

It was originally deployed as an IBM-Oracle mainframe solution with a C++ front end. We modernized it through a pure Web application, but, from an IT development point of view, the benefits of being in that Web architecture are manifold. First and foremost, they were able to manage this entire development process with one person in the US, and a whole development team offshore in India, dramatically reducing the time and cost.

In this new architecture, the ability to respond to program change requests is tremendously different. We're able to program and change requests in one-tenth of the time and, by virtue of being a Web architecture, actually deploy those in now what are weekly release cycles, instead of six-monthly cycles that you would typically see as a point solution.

As we're running a little long here, I won't go into all of these, but there are many different ways in which the modern architecture really played into creating significant additional IT value.

We provide a process we call Nexaweb Advance, which is an end-to-end transformation process that allows us to dramatically reduce the time, risk, and costs of this overall implementation. It starts with a capture phase that is able to go in and interrogate legacy systems and dramatically reduce the amount of time and effort to document the code that typically is not well documented.

Then it goes through a model transformation process that dramatically reduces the amount of actual code that has to be written. In this example, it was a 65 percent reduction in the amount of code in the three million lines of application. The net result of that is through a typical designer development cycle, we were able to realize 50 percent or more reduction in the development time.

Having done that as a Web based application, there is no kind installation, no on-site provisioning. It's all centrally managed, so dramatic reductions in operating costs recognized by customers. In the example that we shared with you a little bit earlier, where, because we're in a modern object-oriented architecture with all the inheritance benefits that that brings, we're actually able to modify and execute change requests quite often in one-tenth of the time and then deploy them immediately and effectively as Web applications.

Announcer: Thanks, Adam. With that we conclude our podcast. You have been listening to a sponsored BriefingsDirect presentation taken from a recent Nexaweb webinar on application modernization. Please find more information on these solutions at Nexaweb.com. Thanks for listening and come back next time.

Listen to the podcast. Download the podcast. Find it on iTunes/iPod and Podcast.com. Learn more. Sponsor: Nexaweb Technologies.

Transcript of a BriefingsDirect webinar with David McFarlane and Adam Markey on the economic and productivity advantages from application modernization. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

BriefingsDirect Analyst Insights Podcast Examines WOA to SOA Continuum With Keen Eye on Cloud Computing

Edited transcript of periodic BriefingsDirect Analyst Insights Edition podcast, recorded April 24, 2008.

Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.

Dana Gardner: Hello, and welcome to the latest BriefingsDirect Analyst Insights Edition, Volume 28, a periodic discussion and dissection of software, services, cloud computing and related news and events with a panel of industry analysts and guests. I'm your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions.

Our distinguished panel this week -- and this is the week of April 21, 2008 -- consists of Joe McKendrick, an independent analyst and prolific blogger. Welcome back, Joe.

Joe McKendrick: Thanks, Dana, happy to be here.

Gardner: We’re also joined by Jim Kobielus, senior analyst at Forrester Research. How do you do, Jim?

Jim Kobielus: Hi, Dana. Hi, everybody. Glad to be back in the saddle.

Gardner: Also joining us this week, Tony Baer, principal at onStrategies and also a prolific blogger. Welcome, Tony.

Tony Baer: Hey, Dana, good to hear you again.

Gardner: Also joining us is Brad Shimmin, principal analyst at Current Analysis. Hello, Brad.

Brad Shimmin: Hey there, Dana. Thanks for having us. Good to be back on the air with you as well.

Gardner: And making his debut on this particular podcast, Phil Wainewright. He is an independent analyst, the director of Procullux Ventures and a ZDNet blogger. Welcome to the show, Phil.

Phil Wainewright: Glad to be here, Dana.

Gardner: Our discussion this week will focus on several recent news events. We've seen the Live Mesh announcement from Microsoft -- and that came on the heels of the Application Engine from Google.

So, we're going to look at those. We're also going to put this discussion in the context of some recent back-and-forth blogging and some discussion about leadership around the intersection relationship between Web-oriented architecture (WOA) or "webby applications" and their environment and support technologies, as well as traditional services-oriented architecture (SOA).

I'm going to start with you, Tony. You just came out in the last day or two with a blog that referred to WOA as a "lowest common denominator." I wonder if you could help us understand what you mean by that.

Baer: My sense of it is that it’s technologies that are basically extremely accessible and relatively simple, and you don’t have a very complicated stack to wade through. They're technologies that have been around with Web developers for five to ten years, and, in that sense, it’s very much like Ajax, in that these are technologies that are there are and, guess what, we’ve found new ways to repurpose them.

We're using HTTP, plain old XML, and a RESTful style of service requests to essentially make the Web more dynamic, almost an application-centric environment. What it lacks is the perceived complexity or what would be considered as a capital "S" SOA, which should be the Web services stack. I've lost count of the number of standards or proposed standards. I know on the Wikipedia page, they list about 80. I think Linthicum has quoted numbers close to a couple of hundred.

Again, it’s part of a back-to-basics backlash against complexity, whether you’re perceived correctly or not. Like Ajax, it’s just have a loosey-goosey collection of things that were already out there.

Gardner: So, from your reference point, "lowest common denominator" isn't necessarily derogatory or a bad thing, but is inclusive and perhaps a positive.

Baer: If it gets you the information you need, who cares about how ugly it is?

Gardner: Okay, let’s take this to Brad Shimmin next. Brad, we have seen some opportunity now, public APIs, Web Services, even platform-as-a-service (PaaS) offerings. We all have seen Live Mesh from Microsoft, which I guess you can call a direct re-interoperability as a service function. What is relationship between WOA and SOA? Are they exclusive or are they separate? Can they overlap? How do you view that?

Shimmin: I just see the two as different sides of the same Rubik’s Cube that you can mix up and make into a complete absolute mess if you want to. Or, you can see them as highly simplified, depending on your viewpoint. If you are a developer, building an app that’s just going to run on the Web and you want to avail yourself of the benefits of SOA, you are probably going to want to use REST, because of its simplicity and applicability to services that are running on the wire or on the Web.

I see it as a continuum, the Rubik’s Cube continuum, if you will. But, now things are coming out of Google and Microsoft and I don’t see those two as being competitive with one another or similar, but as a representation of a very fast moving, huge wave.

We're being inundated right now from a number of vendors who are really pushing hard to make use of the Web as not just a form of connectivity, but as an actual platform for the services and software that we consume -- whether you are a consumer using Live Mesh to synchronize your computers or you’re an IT department looking to extend your B2B network without having to go to a VAN provider.

Gardner: Now, Phil Wainewright, you cover software as a service (SaaS) diligently. I'm not wedded to the term WOA. I'm happy with "webby applications" or 'web-facing technologies." Do you think that with these announcements from the cloud providers, you’re better off availing yourself of them as an enterprise or a service provider organization? Is there a benefit from a WOA perspective for absorbing and using these Web-based or cloud-based services, or are good old SOA technology and approaches just as good.

Wainewright: We really shouldn’t try and separate these two phenomena, because they are two sides of the same coin or two facets of the same Rubik’s Cube. To deliver something using WOA, any kind of serious provider is going to need to instantiate that within a SOA. So, there’s going to be SOA underneath a WOA provider.

We're going to look a little bit stupid if we start to debate the difference between one artificial term that we have created and another artificial term we have created. Really, it is just about services that you use within a certain set of protocols, which are really based on the Web anyway.

We are realizing that what was taught or asked as SOA within the enterprise is actually something that we can do in the WOA Web. If we do it an environment where there are lots of different participants who all play very different rules, then you do need a lowest common denominator approach to put everything together.

That’s why the emphasis now is on doing things using REST rather than SOA, trying to keep it as simple as possible and as standards-based as possible, and exposing things in a simple way, rather than making it really complex.

Gardner: Now, Jim Kobielus, you’ve been known as a wordsmith. If we're using artificial designations with WOA and SOA, but we still want to recognize this lowest common denominator benefit to tie some of these up together, what typically we should call this lowest common denominator approach?

Kobielus: Before I answer that, let me just peel the onion. I agree with what Phil Wainewright just said, which is that we’ll see SOA underneath a WOA provider. That is crystal clear to me. It’s already happening in my core area, which is data warehousing. The delivery layer or the front-end presentation layer of most business intelligence (BI) or data warehousing environments is going to go WOA or REST or Web 2.0, however you look at it.

So the middle persistence layer, the primary interface there, is not so much SOA or WOA, but SQL for querying data in databases and in OLAP cubes, etc. Then, what I call the "ingest layer" that extracts data from the sources and brings them into the data warehouses has a bit of SOA, bit of ESB, bit of EAI, and EPL.

So, looking at the big picture here, the whole notion of this is simply that cloud services is a convergence term, or should be, because the cloud that all of these paradigms inhabit is a multi paradigm cloud and they are co-existing in various ways. It’s a semi-permeable membrane between these organisms that live in the same soup or the same cloud.

Gardner: Maybe a common factor here is that we are extending and deepening the value we extract from widely embraced standards.

We wouldn’t be able to extend the lowest common denominator, the cloud, or improved SOA conceptually across more assets, resources, and infrastructure in middleware, if we didn’t have some either de-facto or established standards.

Let’s go to you Joe McKendrick. How do you see this? Are we really talking about the result of a lot of standards work in the acceptance and need for standards over the past 20 years?

McKendrick: Exactly, Dana. There are a lot of complaints about what's happening with standards these days. As Tony pointed out, there are anywhere between 80 to 200 standards that are evolving, particularly in the SOA-Web services space, as we know it. But, looking back over a 20-year horizon, we see that things have come a long way. We have HTTP, for example, and the rise of the Web.

I'm going to borrow a bit from Dion Hinchcliffe. He calls the whole Web 2.0 cloud phenomenon "The Global SOA." We have the standards and services that could be built using these standards out in the cloud. That essentially will function as one humongous universal SOA. Bringing that down to WOA, you could look at SOA, as it’s enacted within organizations, as a WOA island, or an internal cloud.

I have heard the phrase "my cloud" applied to an internal instantiation. SOA essentially acts as internal cloud within organizations. I think that’s a good way to sell SOA. I know there has been a lot of difficulty selling the concept to the business, and you can explain to the business that SOA is actually cloud computing, a SaaS enacted within the organization. Your business units no longer have to worry about building their own services or their own interfaces. You have this secure cloud service that exists within the boundaries of your enterprise.

Gardner: Okay, so we have standards and, of course, the funny thing about standards is that some are more standard than others or more accepted than others. What I think I hear you saying is that there is this private cloud or SOA activity in an enterprise, and the standards by which that functions can be the choice of that organization or perhaps what they have been left with as a result of their legacy and on-going IT adoption over the years.

Then, there is this public cloud, WOA, or extended global SOA, which is based on those standards that are accepted by a larger group, perhaps from a social networking perspective, the anointed standards from the social technical graph. What do you think, Phil Wainewright, are we talking about sort of tiers of standards here?

Wainewright: Well, I was listening to what Joe said and it kind of crystallized in my mind. WOA is actually SOA that works, because, as you said, you can build a SOA in your own organization with your internally defined standards. I am thinking back to the fact that the SOA required standards so that two SOA implementations can work with each other.

These internal SOAs are actually nonsense, because they are totally internalized and they can't interact with the outside world. If you want to actually take advantage of all the resources that have been on the Web, if you want to interact with people in other organizations or with computer systems or database resources that other organizations are making available, you have to go to WOA.

That's the SOA that works. The reason it works is because it’s been implemented using standards that everyone actually understands and haven’t got the latitude to define for themselves.

Perhaps this is the moment when all those kind of people who have been building all these wonderful SOA infrastructures within their organizations -- for whatever it was they thought people were going to do at the end of the day -- are really going to meet their nemesis.

Gardner: Okay, so we have a set of SOA principles and standards that have a certain internal maybe even extranet type of a flavor, but in order for those islands to work well across other islands or to avail themselves of highly cost-efficient cloud service that are made available by such notables as Amazon, Google, Microsoft, IBM, eBay, EMC and Apple, you need to go to this higher common denominator, accepted level of standards.

Tony Baer, do you think we’re getting close to what’s the proper understanding of WOA/SOA and what should come next?

Baer: The way Phil was characterizing WOA as "SOA that works" and the way Joe characterized SOA as basically the internal cloud, kind of the rang bells rang here. It was like, "Aha! Yeah, that’s really what it’s about." It seems like what we are sailing into is these tiers of granularity.

If you are going out to the wider world, you go out to the wider world of the standards that have already been there for years, where we don’t need a learning curve. And, it makes sense, because the more sources you deal with, the lower your common denominator has to be. You need to basically widen the gate there. The way Joe and Phil put it really sums up how these are settling out. So, that makes a lot of sense.

Gardner: Alright, so perhaps from the user-centric, developer-centric, and even the disrupter-centric viewpoint, that being the cloud, the new cloud providers are happy to embrace these more open or common-denominator standards. On the other hand, there are vendors who are established that have incumbency and perhaps have business models to protect.

So, there could be some tension here between the SOA as an internal cloud and the WOA as the more external, more highly interoperable cloud. What do you make of that, Brad Shimmin? Are we are going to have some tension here between the incumbents and the user/developers/disrupters?

Shimmin: If IBM is any indicator of things to come, I would say no. It’s simply going to be the established firms taking advantage of the situation and partnering with or building up their own infrastructures for delivering RESTful-based Web-Service applications

Gardner: It doesn’t seem like they have too much of a choice, right?

Shimmin: Absolutely not, and if you look at companies like BEA -- Cape Clear was one of the first actually -- they’re in the application for SOA structure’s base. They are climbing over themselves to REST enable all of their APIs, strangely enough, starting with their governance tools and then moving to their more messaging-oriented software.

So they are REST enabling all the software, actively partnering with service providers to help them, and enabling ISVs to build apps that use their technologies. BEA and Progress Software have well-established ISV programs for customers to build out these SaaS apps.

Gardner: Alright, I think we're looking at a period of some disruption, particularly on the business-model side. So, if there is this great sucking sound that the Web as a platform is defining what is productive, what can be done cost effectively?

You can produce and put apps up on Amazon or Google or other alternatives. That’s kind of an offer you can’t refuse, if you are a startup or if you are an internal development organization within an enterprise and you have limited funds, but you want to accomplish something. These are very enticing opportunities to take the logic to the cloud, perhaps even do the tooling and development in the cloud, produce something, and then pay for that as it produces revenue or is in demand.

So, given the disruption on the business model side – again, good news for developers and users and disrupters -- isn’t there a risk if this happens too quickly for folks like IBM, TIBCO, and perhaps SAP? What do you think about that Phil?

Wainewright: One of the things it’s going to expose is that the WOA world is still in some early days and that there are quite a lot that the providers have got to get it right in terms of a service level commitments and in terms of what they are billing for their services, how they are establishing the robustness or reliability of a data feed, and of course, the security stuff.

Before these providers become highly competitive for the established enterprise vendors, there is some work that has to be done. But having said that, if you look at the more established players like Intuit, QuickBase, and salesforce.com and as well as the attractions for doing stuff on Amazon EC2, a fair bit of enterprise use is already being made of these capabilities.

Gardner: So perhaps the period of some mutual harmony with the older providers continuing to provide services value, perhaps maintenance and ongoing technical support for the SOA cloud as Joe referred to it, but also a new opportunity and competition in the higher level cloud. Let’s go back to Tony Baer, what are we missing in all this? Is there something that needs to happen in order for harmony between the WOA providers and the SOA providers?

Baer: I think Phil was hinting at that. I was just thinking about which part of what was supposed to be the appeal. Part of the problem of the Web services stack is that it tries to be very ambitious in terms of what it has tried to accomplish within that technology stack. Not only did it provide a service request to providers, or conversation infrastructure, but also tried to internalize all the types of security, reliability, transactionality, that traditionally were internal to application or database silos.

The need for those services and those guarantees of robustness doesn't go away, but the question is, where do you implement them? It’s one thing to request a transaction that's not humongously mission critical. But, at some point, you're going to need to ensure that the requester is authenticated and is authorized. If you were going to make this a business, you have to ensure that you maintain service levels. This is very data- transaction focused. You need those transaction guarantees, guarantees of roll back, etc.

I still haven’t figured out the answers to this yet, but my sense is that, if we are going to try and do this and do this on top of a lowest common denominator stack, you can't expect to internalize that within that lowest common denominator stack. You have to apply this externally.

A harbinger of that kind of approach is in some of these new enterprise mashup sandboxes that folks like IBM and Serena and a whole bunch of others are now trying to set up. We recognize that within the sandbox we will make it easy for you to do what you want to do, but we will put external controls to make it safe for enterprise consumption.

I don't have the answers to how this is going to happen, but controls over service levels, security and all that sort of thing will have to be externalized to the WOA stack, if you want to call it a stack.

Gardner: So, clearly there's a set of issues that needs to be thought through and those are thorny around transactional activities or mission criticality, absolute delivery, and guaranteed delivery. Performance levels need to be maintained and there will be compliance and regulatory impacts in that space as well. So let’s talk about data.

Let’s go back to Jim Kobielus. On the issue of data, when it comes to the lowest common denominator or cloud based, isn't there an opportunity for data to become a little bit more inclusive of WOA. Can we exploit the benefits of the cloud, either services or the repository in the cloud and virtualized data repositories, before we have to deal with the thorny transactional set.

Kobielus: Right. In the discussion that we had on SOA versus WOA, I've seen everybody tune into the issue. Offering transactional applications is the primary focus of much of what's going on. In terms of analytical applications, on the analytical data sets and where they are hosted and so forth in the cloud, that’s a big virgin territory that’s beginning to be opened up by, among others, Microsoft.

I was just on the phone with Microsoft yesterday about their SQL server data services, basically database in the cloud offering, which is in limited beta. They plan to go production in 2009. They were keying into an issue that I heard Tony talk about a moment ago that, as you externalize more of these sources into the cloud in an SaaS environment, the controls, whether internal to the cloud or external, are critically important.

Right now, SQL server data service is just a subset of the premises-based SQL server 2005 functionality. Microsoft recognizes that, as they bring it along to more production, they are going to need to build in the 24/7 service level guarantees and all of the security and other mission critical features that customers have come to demand and the premises based version of that particular database.

So, as you go out into the cloud then, that’s a huge open issue. First and foremost is what I call DW2.0, light-weight data warehousing. Microsoft is not the only one in the space. There is Zoho and a few others. It's very light weight, not really mission- or enterprise-grade data warehousing capability, hosting structured data sets in the cloud and then making them available for analytics such as reporting and dashboard. You can wait for this to play out, before these cloud-based data warehouses achieve some degree of functional parity and robustness, comparable to the premises-based offerings that enterprises everywhere have already implemented.

Gardner: Right, but part of the rationale for embracing the Web-tier, cloud-tier of interoperability is, because you can play across ecologies, be inclusive of more partners, allow for SOAs and applications sets within organizations to be more interruptible, then it’s not just going to be analytics. Why not put data in the cloud, because you want to share certain data on a privileged basis with other people and create layers of metadata that can then make for highly productive business processes.

Kobielus: Exactly. Microsoft is positioning SQL Server Data Services (SSDS) supposedly for B2B integration scenarios and also for the mid-market, but is very much focused primarily right now on transactional applications, database applications and so forth.

Microsoft has very much bought into the whole data services vision. They have a very strong one going forward. With WOA, they're at the front and center of it. When I say "front and center," it's in that delivery, access, presentation, sharing, and synchronization layer, leveraging things like Live Mesh and so forth, going forward in their road map.

So, WOA is very big on the front end. On the back end of SSDS, they are very keen and hot on SOA, and everything SOA implies. But, they're not really keen on exposing all of that SOA natively to their target customer, which is a mid-market or a small company that doesn’t have the technical resources or the skills to do programming in a real fixed SOA stack. They prefer to virtualizes all of that stuff and have WOA be that simple front end.

Gardner: Now, when you’re talk about standards in Microsoft, we have to look also at tradition, with Microsoft wanting to establish its own standards, ones that continue its strength and extend its strength into other areas. I think we've seen another example of that most recently with Live Mesh, in that it’s got interoperability across devices, two way communication using RSS and Atom, and other technologies that we would consider WOA technologies. But again, to a subset of the overall device environment or the software and standards environment.

So, let’s go to Joe McKendrick. Do you think that, as Microsoft moves into the cloud, it’s going to fully embrace the lowest common denominator, or perhaps attempt to take its platform approach and extend it into the Web?

McKendrick: Well, you can definitely see Microsoft moving in that direction. Jim made some excellent observations about what's going on in the SQL server space. Microsoft is in a difficult position here, because most of its revenues come off of the traditional, onsite, resident software stack, Windows, the Window server and Window’s client, the Office Suite, the SQL server onsite. If you look at its revenue pictures, billions and billions come out of that stack.

So Microsoft has to be out there, talking about changing the paradigm of computing, which runs against its revenue stream.

Gardner: Alright, I agree with you 100 percent. Let’s put that in the context of its pursuit of Yahoo. Microsoft is seeking to buy Yahoo for approximately $40 billion and Yahoo doesn’t want them to.

Brad Shimmin, if you recall when this was announced on February 1, people were scratching their head and saying, "What, is Microsoft crazy? What are they doing?" I think that over the last couple of months, it started to make more sense. Do you think that the Yahoo component can help Microsoft bridge this crosscurrent, as Joe described it?

Shimmin: I do, and it’s interesting, isn't it. When that was first announced, I think most people thought this was an advertising play and a play for eyeballs, but it seems after looking at releases like Live Mesh that it’s really more about the connectivity services that already exist within Yahoo. They have a broad audience that Microsoft would like to capitalize on, because, when you look at the numbers between MSN and Yahoo, it’s a staggering difference, both in terms of the people who use those services and the number of services available.

For example, the Yahoo mashup server or mashup tool they have is one of those things that Microsoft could easily pull into Live Mesh and make a part of that. Live Mesh, in a way, is a response to some of that. Steve Ballmer, a week or so ago, said something like, "The desktop doesn't matter anymore. It’s the network that matters." This harkens back to something Sun Microsystems said some 20-odd years ago.

Gardner: And, what about Ken Olsen, he said that the PC was a toy, and he had been ridiculed for it, but we are beginning to come back to that, aren’t we?

Shimmin: Exactly. It has come a full circle. Microsoft is running here and running back to the past, if you will, but, as we were just talking about, they have a significant investment that they need to protect. When I look at Live Mesh, I see that as a protection of that system of the desktop and the applications themselves. It is really what Apple has been doing for the last three or four years with OS X, with their Sync Technology, just expanding it a little bit, and dropping some Atom and RSS on top of it.

Gardner: Kind of Hailstorm, Chapter Two?

Shimmin: Right. When you look at what they have been doing with their Office applications, in terms of enabling those to utilize the web, they have been extremely slow in doing so, and are just now sort of picking up where the companies like Zoho have gone light years beyond.

Gardner: You hit upon an interesting issue, Brad, discussing the fact that the cloud compute value isn't just in low-cost per compute tick or for storage per hour, but that there is also this notion of an audience, and the metadata associated with that audience. All those end-users can be provisioned, perhaps quite powerfully and at massive scale, both scaling up and down in terms of the massive size of the possible audience, but the granularity of the service provision to them is another value that Microsoft perhaps sees in Yahoo.

Let’s go to Phil Wainewright with this. Are we talking about cloud computing, not so much functionally, but as a way of bringing together applications, companies, services and the end-users?

Wainewright: I think there is a social dimension to cloud computing, because there is a social dimension to the Web. Looking at if from a WOA perspective -- I do hate these acronyms, especially when we start to turn them into words, but anyway, let’s go with that.

We looked at if from a WOA perspective and what you are actually doing is looking at it also from a social and a user perspective. SOA always tended to be about linking our systems together, and once we’ve done that, it was then what do users actually want, and the business case was often quite a long way in the thinking.

So, cloud computing is good because you have to put the service out there. You have to think about where the people are going to use it. The problem I have with a lot of the kind of Web 2.0 space is that getting eyeballs is the name of the game, and people aren’t really thinking about what the commercial proposition is and in what way are you actually delivering value and making revenue.

That’s why I'm a little skeptical about how much value there is for Microsoft in the Yahoo acquisition, because I hear Steve Ballmer and other Microsoft leaders talking about advertising as a major fund revenue stream.

The amount of money that is available in advertising is virtually nothing compared to the amount of money that is available in transactions as a whole, if you are providing value to businesses. I think there is a great more revenue potential there than simply enabling businesses to get close to the consumers.

Gardner: Okay. You put your finger on something here. It's not just the advertising revenue, but the potential transactional revenue by linking up these constituencies, providing the scale up and down, and giving the developers the opportunity to originally create applications to feed this kind of cycle. If somebody has taken a big portion of the transaction across these activities, that’s a much more sizable market, than the advertising market.

Gardner: Anybody want to react to that?

Baer: I definitely agree that transactions are where the money is, but I think that we need to be careful not to fall into the trap of these B2B exchanges of about nine or ten years ago, when we thought that that was going to be the future of commerce. Instead, it was basically trying to institute a practice that was going against 20 years of supply-chain management and partner management trends. I think we need to watch out there to avoid getting ahead of ourselves with the hype.

Gardner: You've also put your finger on something. What will be the future of commerce in the WOA-SOA linked world, where internal business networks and resources and assets can, at a highly automated level, with full scaling, security and reliability, start interacting with the cloud and therefore, with the end-users. It's really an automation of commerce. What's going to come next? Any idea?

Kobielus: I agree with everybody that Microsoft needs to pursue Yahoo just to keep on building up that audience, because obviously it's an eyeball decision in the whole Web 2.0, eCommerce arena.

Gardner: And that’s because they missed the boat on search, right?

Kobielus: Right. If you look at it, and I agree with what everybody said, transactions are the money to be made from connecting those eyeballs/wallets to transactions. It's where the Web 2.0 money will primarily be made.

In a sense, tracking eyeballs is instrumental to both connecting those wallets to transaction, but also connecting those eyeballs and the brains behind them to the intelligence and the analytics that are out there, selling that service as well. Microsoft is providing not only business intelligence, but market intelligence, consumer intelligence and so forth into the cloud.

McKendrick: Let me add to that. It's going to be changing the nature of organizations internally as well, not only on a B2B basis. The dot-coms that you saw arise in the 1990s all had to buy their infrastructure. They needed to buy Sun servers and everything else to support their operations. Now startups especially can just tap into the infrastructure and services that are available across the cloud and offer up these services to their consumers.

I’ll leave with an example. If you look at the Amazon Web services site, look at some of their case studies. There is a company -- a podcast service company, as a matter of fact -- Online Podcast Service, that was able to start up with a full-fledged infrastructure that cost a total of $82 for the first two months for storage, processing, messaging, everything they needed.

Gardner: I agree. There is the whole middle layer of the applications and services right before an explosion -- sort of what we are seeing on our trees and in our lawns these days in April -- that can create a very fertile environment. But, that environment exists within the confines of someone’s cloud. That cloud can interoperate significantly, but the metadata that ties the constituencies together can be manifested across these relationships at a price.

McKendrick: Dana, you just sent a shiver up my backbone here, because what I see in my lawn are tons of mushrooms. So, when I put mushrooms in clouds in the same sentence, I have a shiver running down my spine.

Gardner: Maybe the English language isn’t sufficient to keep up with the technology concept?

Shimmin: I am disposed to use WOA as a word, I guess. I've seen two examples in the last couples of days that speak to what seems to be a growing future for this sort of commerce that you are talking about. I don’t know if you got to see this, but Sun’s Solaris On Demand program that they launched a couple days ago, is really about enabling ISVs to make their applications and to host them on either Sun’s network or on Sun’s partner’s networks. In either case, Sun takes a cut from both the partner and the ISV for being the middleman -- the provider of some technology and some supported services for those other datacenters.

Gardner: We're going to have to wrap this up pretty quickly now, but we haven’t discussed the whole mobile tier, and the fact that many more consumers entering their metadata continuously about what their wants, needs, desires and what they are willing to pay money for, will come through a mobile device, not necessarily a PC or even a browser. This offers yet a much larger global audience potential for what these clouds can pull off. Anybody wanted to discuss very quickly, the mobile edge impact on this before we close up for the day?

Wainewright: I’ve made a couple of observations,. The mobile Web is not going to exist as a separate thing. It’s just going to be the Web as we experience it on PCs.

Gardner: Right.

Wainewright: So, that's was interesting for two reasons. Yes, the way it is going to be available on mobile devices. We are going hook into a mobile, but it’s going to look much more like the Web that we are already used to rather than some kind of completely separate thing.

Gardner: Excellent.

Kobielus: A lot like a Live Mesh.

Wainewright: Indeed, and I think that the genius of Live Mesh is that Microsoft has really created in Live Mesh a bridge that enables it to take the cloud rather than being something that’s up there on the Web, but to bring it down and envelop the desktop as well, which then gives it a transition bridge to bring it’s own products into the cloud.

Gardner: But in doing so with a certain risk by not being inclusive of all the different permutations of how that could be done.

Wainewright: I think it's going to do more permutations. It’s has come right with the Microsoft-only implementation, because this is the first release. We will see how much effort it puts into making Mesh available on other platforms; that’s going to be a big test of how successful it will be in the long term.

Gardner: Well, thanks. We're going to have to close it out here. Tony Baer and I had a quick discussion at IBM Impact a couple of weeks ago about how the thought process is so much richer when you’ve got a group of bright and educated people like you all.

So I appreciate the group thing. I think we have been able to solidify and even move the needle a little bit on some of these concepts. I hope the readers and listeners appreciate that. So, I want to thank our panel. Once again we have had Joe McKendrick. Thanks, Joe.

McKendrick: Thanks, Dana. Glad to be here.

Gardner: Jim Kobielus. Thanks, Jim.

Kobielus: Oh, it’s been a pleasure once again.

Gardner: Tony Baer, I appreciate your input.

Baer: Nice to be back.

Gardner: Great to have you here, Brad Shimmin.

Shimmin: Thank you, Dana.

Gardner: Well, once again, welcome to Phil Wainewright, and we certainly hope you come back again.

Wainewright: Thanks very much, Dana. It’s been a pleasure being here.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to the latest BriefingsDirect Analyst Insights edition, Volume 28. Please come back and listen next time.

Listen to the podcast here.

Edited transcript of software services, cloud computing and related trends and analysis discussion. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.

Platform as a Service Enables Cloud-Based Development While Accelerating Role of SaaS

Transcript of BriefingsDirect podcast on platform as a service and on-demand applications deployment trends.

Listen to the podcast here. Sponsor: Bungee Labs.

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

Today, a sponsored podcast discussion about platform-as-a-service (PaaS). We're looking at an entire lifecycle approach to services on the Web for development, integration, and deployment. We are going to be talking about Bungee Labs, the sponsor of our podcast and take a deep look at how they approach PaaS.

I think it’s important for us to get into this topic to understand its wide-reaching implications. PaaS is really taking the best of some of the old and the new that’s now available to developers and architects -- and it really puts a new spin on Web-oriented architecture (WOA).

For example, many developers can use tools that are fleet and easy as they approach rapid application development (RAD) and Agile development. But when it comes to the flip side -- the deployment -- there are still gaps in many cases a hand-off. There is also an opportunity, now that users are increasingly on the Web, to use mashups and open APIs.

To take advantage of data independence -- data that can be acquired, used, and mashed-up from the variety of sources -- including services-orientation from inside the firewall, from within legacy applications. What's nice about the PaaS approach is that the scale on the deployment can go up very rapidly and scale down efficiently in terms of cost.

In many respects, we are now leveraging the incredible value that comes from not having to pay upfront in capital expenses for applications and infrastructure, but instead can take advantage of the pay-as-you-go, metered approach.

To help us better understand PaaS, we’re joined by Phil Wainewright. He's an independent analyst, the director of Procullux Ventures, and a ZDNet software-as-a-service (SaaS) blogger. Welcome to the show, Phil.

Phil Wainewright: Good to be here again, Dana.

Gardner: We are also joined by Alex Barnett, the vice president of community at Bungee Labs. Welcome to the show, Alex.

Alex Barnett: Many thanks, Dana, for having me on.

Gardner: Now, as I mentioned, this on-demand platform value brings together a lot of the old and the new. But in some regards, the current state of development for applications and Web services is still a tricky business. We're still in a period where friction between the developer and what the operational environment is expected to be.

There are often integration issues. We are also having to deal, of course, with on-premises software acquisition and downloads, licenses, upgrade paths -- just maintaining the software on premises for development and for testing.

Phil, could you help us understand what is it about the current state of development that will benefit from moving all of this into the cloud?

Wainewright: One of the factors is that IT is getting more and more complex, and obviously there is a lot of emphasis on governance and oversight and so on. So, provisioning a new system for a development project can be a very long-winded process.

On top of that the world seems to be moving fast ... because of the Web, because it’s connecting us in much more immediate ways. And therefore, business people want to have much more record intervention, and they need automation of new processes a lot faster. You’ve got these two processes: On one hand, it’s getting more and more complex, difficult, and time-consuming to bring new projects online. At the same time, there is this pressure to have those new projects faster and faster, and to have an adaptable and agile development environment. It’s a collision course, really.

Gardner: And I suppose with the way teams are dispersed now, and with people leveraging globalization and offshore development, that you want to bring groups of people together without also having to maintain and oversee the on-premises software at each location that’s supports new development along with application lifecycle management (ALM) ?

Wainewright: Yes, that’s absolutely true. The web enables this collaboration, whether you are developing on on-premises platforms or in the cloud. You want to do it via a distributed team, because that’s the way that you get to this scale, and you can get the best minds on a project. And so you are going to be doing that collaboration in a kind of Web-connected environment anyway.

Gardner: I suppose it’s also important when we look at the speed of development to appreciate that three or four folks in a garage in Northern California can come up with a mashed-up service and go out and create a social networking company, for example, quick and easy -- and at low expense. And then, here you are in an enterprise, taking six months to work through a requirements process. It seems as if something has got to change.

Wainewright: This is a rewind back to the late '90s when people looked at the Web and they thought, "Well, how is it that my daughter or son can look up the information of some arcane homework project in a couple of seconds, while it takes me three weeks to find out what's happening in my own business?"

Now what we are seeing is my daughter is able to hook out to these applications from some guys working off in a garage for Facebook, and do it all in a couple of days. And, again, I am kind of trying to get similar functionality on my corporate network -- but it could be 18 months before I see it.

People are asking, "Well, why, why is that? Why are we so far behind what these people in garages, these teenagers, are able to do so much out there on the Web?"

Gardner: That’s a reason why we are seeing very rapid uptake in what's known as Enterprise 2.0, WOA, mashups, rich Internet applications (RIAs) -- and it's not just startups, but really starts to move across the board. It’s just a faster, better way of getting a fairly large class of applications going -- and also managing the integration of data on the back-end.

Wainewright: Well, let’s be cautious, Dana, because I think that a lot of people are experimenting with it for the moment. I wouldn’t say enterprises are necessarily doing things that are business-critical or mission-critical right now. They are still working out what the utility is, and what the risks are from this model.

Gardner: Let’s take that over to Alex. Alex, tell us a little bit about how you perceive the rates of adoption around SaaS and WOA. Do you see this as something that is just building; and what about that issue about risks security, control and management?

Barnett: The context from the big picture point of view is that everything we know is moving to the Web. And what that means in tangible terms is that businesses and service providers and software companies are providing layers of functionality and data that are native to the Web or are Web-oriented.

Things like Web services and even less-sophisticated and increasingly popular things using REST and XML offer interfaces into the functionality and data. This ongoing trend is being driven by a frustration in what we’ve inherited from the previous generation of computing, where everything was essentially behind a proprietary protocol or proprietary set of APIs. This required that you to buy a platform set, or toolset, across the board, just so you were able to get the data that you owned as a company.

If you think about customer relationship management (CRM) systems or a certain kind of database -- they are in silos, they are disconnected, or they are very expensive and require lots of proprietary knowledge in order to be able to access the data, and therefore the value.

What we are seeing with things like WOA is a materialization of how we get out of that frustration as an industry -- how we get out of that frustration from business. We want the data and the business intelligence from it, and to be able to get at that from a business perspective.

The IT managers feel the pressure to be able to more rapidly to develop applications and access the data that are based on and being made available through Web APIs. And developers are able to then connect, develop, and build-out new applications based on distributed data, on distributed functionality and react to the business needs.

If you look at ProgrammableWeb.com, for example, at the end of last year, you would have seen that there were something like 500 Web APIs catalogued. There is a combination of commercial and public APIs. And now, here we are in April and we’ve got 650 APIs from the public and commercial space. So exactly the same trend is occurring behind the firewall, within organizations, as they create these layers of connectivity and programmable end-points to gain functionality and data.

Wainewright: It is important to say that the interfaces being published on ProgrammableWeb.com are not just some stupid little kind of stock market data feeds or what's the weather in my area tomorrow, the sort of thing we saw in the early days of Web services. These are actual, complete and functional API sets of the kind that an enterprise calls to applications like Salesforce.com, and to many other resources.

Gardner: So we have some significant new opportunities for taking advantage of the Web with these mashups and the data portability. And, again, we want to take advantage of the old as well as the new, with the old being characterized by lower-risk control and management.

So what does PaaS do conceptually, Alex, and how does that bring together the best of the old and the best of the new?

Barnett: If we define "old" as being that you are locked into a stack, that you aren’t able to get up through using open standard protocols such as SOAP, or even just standard XML interfaces, then that "old" is typical to get around. That’s what we’re seeing in terms of investments to upgrade system to unlock that value.

Gardner: I guess by "old" I mean enterprise-ready and mission-critical, that’s what I mean.

Barnett: Right, and once they’ve got to the point whether they have allowed that services layer to occur, the question is, "How do we get to the next step? How do we quickly derive value from the systems we have?" What we hear businesses crying out for is getting at the data, getting at the applications that are open.

Now, there are some companies that are moving ahead very quickly with this, being able to take the leap of faith of providing CRM-type data on a hosted service. Or, they may want to maintain it behind the firewall, behind their existing systems, and then just be able to provide limited, yet secure, access to that data through applications that are inherently secure in terms of their architecture.

Wainewright: What we're seeing develop at the moment is kind of a two-tier information technology. On the one hand, you have all of the existing on-premise, legacy applications and all that data that Alex was describing. It's locked away, and IT managers are really puzzling over and grappling with the issue of how to unlock that data. How do they make it more accessible? How do they build more agility into applications infrastructure?

They are looking at things like service-oriented architecture (SOA) and other ways of connecting and integrating the data, while automating business processes within the organization. So that’s one tier.

The other tier that’s developing is this Web-oriented tier, all of these APIs and in-the-cloud resources and applications that are out there on the Web. To take advantage of those connections, you need to build a completely new infrastructure, which is different from the existing infrastructure within the firewall. It has to cope with connecting to external resources, and it has to have different kinds of security, different kinds of identity management.

Building a robust infrastructure to do this is very, very hard. That’s one of the reasons why a lot of enterprises are holding back, and are therefore missing agile opportunities. That’s one of the roles that the PaaS can provide.

Barnett: What they have tried is failing, or they haven’t got the right level of investments, or they have other priorities.

Wainewright: Yes. And, we see some tremendous disasters happening where people in e-commerce are, in a very limited way, opening up to customers to transact with them. And they have to do that. They are losing customer data, because they're not getting the security right. So, yes, people have to be wary of that whole area, that Web tier -- because it’s full of pitfalls and traps.

Gardner: Okay, we’ve established that the tide is turning to the Internet, that there are some great Web-based services available, that technologies are now bubbling up to allow for better and easier connectivity. And yet, there is still a need for the right platform and the right infrastructure to make this all mission-critical and enterprise-ready.

So let’s get into PaaS as a possible stepping stone that, in a sense, bridges the best of the Web-oriented architecture and the available SaaS and the APIs-world with what developers inside organizations -- be they ISVs, service providers, or enterprises -- need to make these approaches acceptable and within the acceptable risk parameters.

I noticed that Bungee Labs does not call this "Development-as-a-Service" or "Deployment-as-a-Service" or "Integration-as-a-Service" -- but "Platform" as a service. Alex, give us the primer. What does "Platform-as-a-Service" really mean?

Barnett: That’s what we are trying to define at Bungee Labs. PaaS is one of those terms that we’re going to be hearing more and more. And they are going to be different -- varying levels of definition and interpretation of what that means.

But what we’ve done is put a stake in the ground in this respect, and then saying that in order to really be a PaaS -- and not just any one of those single pieces that you’ve mentioned plus more individual pieces -- that you need to be able to provide the end-to-end services to really call it a "platform."

From the developer’s standpoint, which is the development cycle, this means the tools that they need to develop applications, to be able to then test those applications, to be able to connect to Web services and to combine them, and to have all those kinds of capabilities -- and to then deploy and to make those applications instantly available to the business users.

Literally, we mean a URL that is the end-point for the end-user. From that, they can start consuming the application.

So, PaaS means having an environment in which you deploy inherently and have built-in scalability, reliability, and security. Once you’ve deployed your application, you know that you don't have to take care of all the infrastructure in the datacenter and the capital investments and the bodies that are required to make it scale when newer applications increases in use.

There is also the ability to connect to the various distributed data sources or functionality that the application needs to be able to consume. You can get that inside of that platform, the ability to be able to do that in a Web-native way, and so take advantage of the architectures we descried earlier, such as SOA.

There is also the ability -- and we touched on it earlier -- for developers to be able to collaborate on projects that are built-out in the cloud. They can share code, check in code, do all the standard revisions and collaborative-type functionality that developers need when they’re working on projects with teams distributed across the world or across your offices. And they can do this without having that entire infrastructure on-premise.

And then, the last, but critical, piece is having deep instrumentation and an analytics ability around the use of the application -- of how it’s being used, of where the connections are -- right across the board from the "glass of the window," the browser, for example, and right on through to the Web services in the CPU, or the rest of it.

As a result, you are able to understand performance. You are able to understand your billing, if it’s a billing proposition that you have. And all of what I described is comprised within six pillars [of Bungee's offerings]. All of that is delivered and available purely as a service, so there are no on-premises requirements for any of those components across the development and platform used in a utility model. You use it as much as you pay for, or as much as you use in a utility-based model -- all in the cloud. No bit needs to be installed on any machine at the enterprise in order to take advantage of all those Web services and functionalities.

Gardner: For our listeners who are just getting used to this concept of PaaS, let’s just get right in quickly and describe what Bungee Labs is. It’s a young, innovative company. And you’ve come out with a service called Bungee Connect. This is essentially one place online where you can go to develop, mash up, and access data, to put together Web-based applications and services, and then instantly -- with a click of a button, and perhaps I am oversimplifying -- develop and deploy in basically an integrated continuum. Is that correct?

Barnett: Yes, and provide very rich user experiences as part of that, with highly interactive application functionality. We’ve built out essentially that stack that I’ve described earlier. We've made that available for organizations to take advantage of. We're specifically targeted at developers who really want to be able to build very sophisticated Web applications that leverage orchestration workflow around connecting to Web services.

We are not in the business of being able to provide non-programmers with the ability to do these nice simple mashups.

Gardner: Well, if you can do that, let me know, because that would be a very good trick. I am sure the world would love to have development by anybody!

Barnett: Yeah, and that’s a great dream to be able to have, but inherent in that is inflexibility, because you are simplifying it all for the end-user. What we really offer is for the developers who are tasked with building sophisticated Web applications to do just that, deploy that, and then deliver very rich user experiences out on the Web.

Gardner: And to be clear, this is not just open source. This is commercial code, if they wish. The people who develop on this system, that code is their intellectual property. Is that right?

Barnett: The intellectual property of the code that is developed by the developers is absolutely their own intellectual property and remains so. We do have a community side of things that allows developers -- just as in the open source world -- to be able to share code and even entire applications as open source running on our grid.

But in terms of a company, it’s entirely their intellectual property that they developed and they are able to literally export the code. And if they want then re-factor that for a different kind of a grid or runtime, it’s their property.

Gardner: Phil, how do you see the relationship between PaaS and what Bungee Connect is doing, and then the larger SaaS trend? Do you see a relationship of one aiding and abetting the other? Or are they in separate orbits? How does that work out?

Wainewright: I think they are very much in a similar orbit. And to an extent, I don't think of PaaS as being part of SaaS or vice versa. It’s just everything moving to the cloud. These are two examples of that happening.

One of the things I want to highlight, as Alex was saying, is the useful experience. When people start developing for the Web, for the cloud, then it’s not just building the infrastructure -- it’s also learning what is involved in writing applications for that environment.

There is much more emphasis on the user experience. There is much more emphasis on reusing what other people have done, whether it’s by mash-ups or by reusing other people’s code, as opposed to reinventing the wheel every time. There is much more emphasis on developing applications and programs that can adapt and change to future opportunities in business conditions.

All of those things also have to be learned, at the same time as building the infrastructure. Using PaaS enables you to tap into that shared expertise in a way that you can’t do, if you try all by yourself.

The other thing that’s happening here is that we’re connecting into the resources of the Web, and getting onto the Web, so that we can interact with partners and customers and connect into those other Web resources. This is what we're really expected to do as businesses today, in order to stay competitive. So, there’s a tremendous pressure building to be able to do this kind of thing.

Now, there are three ways you can get onto the cloud. You can go to a cloud-computing provider and basically build your stuff in that cloud, which gets to some of the infrastructure, but, there's still the issue of how do I write applications in this environment and connect to other client resources.

Second, you can go to pure SaaS whereby you get a ready made application and you can do some customization, but there are going to be quite a few gaps around what that provides and what you actually want to do. There are going to be quite big gaps in terms of integrating that into your existing on-premises applications and to the other client application that you use.

Third, where PaaS comes in, it allows for the ability:

A) To get much faster to the custom applications that you need to build for that environment

B) To do the integrations to fill in the gaps and to access other SaaS applications and services, and to patch and connect back to the existing on-premises applications.

Gardner: Well, great. Now to the point a little earlier that if you read a lot of the blogs that are out there you might think that this is all widespread. But PaaS is just in its early stages. Yet one place where SaaS has really become quite popular and in a full enterprise usage is the CRM space.

First, why is it do you think that SaaS has taken off with CRM, and then secondarily, what is it about the nature of the data in CRM that might be something that this PaaS approach might be well suited for?

Barnett: In the early days, CRM took off because SaaS automation allowed a sales manager to get to the functionality he wanted. In the eyes of the IT manager, he said. "Well, okay, this is just a standalone application inside of Salesforce.com. The sales department is not going to hurt anyone else, so go ahead with it." And the sales manger just signed up on the credit card, and perhaps didn’t even tell IT about it and got on with it.

So it was very easy to establish on-demand CRM. Now what has happened more recently is that enterprises have realized that they have a lot of on-demand CRM being used. And perhaps they’ve decided that they want to harness it because it does kind of enable them to give functionality to the sales team faster than they can, if they built it themselves.

But they would have to do that in the context of their IT infrastructure, and they are looking at things like integration and to make sure a customer record in the on-demand CRM system is the same as the customer records in the ERP system. If a salesman closes a prospect, then how do you translate that closing from the CRM system into an order on the ERP system of records so it gets invoiced and the salesman is properly compensated? How do you then take back the data and functions into the SaaS system?

Gardner: So, we have a lot of fast-changing data that is actually essential to a business. This is what makes their sales happen and how they then fulfill those sales and get them into the processes that their back-end systems will perhaps manage and drive to create the actual products and services. This is certainly mission-critical. It’s distributed across a number of people, with many of them scattered and mobile, and it’s all quite dynamic.

Barnett: Right, and they need to do even more functionally. The on-demand CRM providers like NetSuite, Salesforce.com, Oracle, and now we’re hearing Microsoft Dynamics, are providing Web services layers over the functionality that they provide to the end users.

We’ve always been able to do a certain level of functional customization around those applications, but when you have the Web services that provide access to the data -- on the programmatic level -- you gain a whole new opportunity to merge, in terms of levels of customization against an existing CRM application, or ERP systems.

This pushes out the expansibility and the increased functionality of the investments that they’re making. It allows for those services to be able to expand that further in a cloud-orientated, Web-orientated way.

Gardner: Now, back to Phil. What is it about the CRM and PaaS from your perspective that demonstrates a larger opportunity in the market?

That is to say, if we can take advantage of the mashups and services and high level of on-demand CRM -- we can bring PaaS in to help integrate data or the take that data and some of the interfaces and views from a CRM activity and bring it and relate it to either a channel or a supply chain and/or backend systems.

Does that mean that CRM now highlights what will be repeated across other types of business applications?

Wainewright: Yes. I think it’s great for the on-demand CRM vendors, because it really starts to hammer home the benefits of being an on-demand application. Now you’ve got this Web context that you can take advantage of.

As you look to the huge advantages of being able to consolidate community insights into a better application, of being able to connect into API resources and aggregate data for doing composite processes, then that means these are mashups, data mashups and user interface mashups -- it’s all the same kind of thing.

So you gain this ability, and you really destroy the misconception that if you go to SaaS you can’t do customization and you can’t do integration. It means that we’re actually doing better customization and better integration than you are capable of doing with many on-premises systems, because it’s actually a more flexible customization. It’s more cost-effective integration because it’s a shared service.

What previously seemed like disadvantages of the SaaS model can be turned on their head and turned into advantages.

It shows the way to using these applications in other areas. We talked about CRM -- because that’s a very big area that gets a lot of media attention -- but there are other areas that are equally successful with on-demand, such as people management, human capital management, the whole e-commerce area, and, of course, content management. There are lots of opportunities to take this model further.

Gardner: It’s been interesting for me as I look into Bungee Labs and Bungee Connect because it appears that the PaaS value forms a stepping stone to allow more use and exploration of the SaaS applications and services that are available. And the more you use those services -- in a virtuous adoption cycle -- the more you want to customize and integrate. And so you might then look to PaaS as a means for doing that. I think they play off of each other quite well.

Wainewright: They do. And I think probably the biggest takeaway for anyone listening to this is that as a business, you need to know how to work in this Web environment. Your customers expect you to be connected to allow them to participate. Your partners expect it too. You’ve got to be open to the Web. You need to play in this environment.

And secondly, if you are a developer, you need to learn how to do all this stuff, because this is going to be a big, expanding field where the skills are going to be in demand.

A lot of the focus at the moment in IT is on getting all of the internal systems operating together. I think there’s very little budget available for doing a lot of new stuff. So, you can’t afford to build the infrastructure for all of this Web stuff. You really need to go to outside providers to be able to start playing with it quickly, but if you don’t start playing with it now, you are going to left behind.

Gardner: Great points. Also, if you build services and applications on a PaaS approach, they are going to be public facing. Putting it onto a grid, or utility/cloud-type of deployment allows you to then scale up very rapidly without you having to worry about that forklift upgrade of your blade servers or your datacenter. And, of course, you can also scale down if needed if the services impact just a handful of people in a supply chain environment, for example. You can build a service that might be for a small group of people, but at a price-point that makes that worthwhile.

Barnett: I’d say that’s the beauty of what the whole SaaS trend has allowed us to be able to do.

Going back to the CRM example, the sales managers have been able to just start up a test account using their credit card. And, all of a sudden they can start seeing the value instantly of having this CRM on-demand, through a browser. And, then they can just slowly, slowly increase the activity that’s going on there because they see the value and it’s becoming cost effective.

But if you take the same kind of concept and now bring it back to the IT department, they can just try a simple application that has business value, as long as they’re happy on the security side of things. Then maybe they try a composite of two Web services, and provide instant value back to the business. There it is. It’s a URL. It’s secure. It’s locked down, and it’s all the rest of it. And nobody can get access to it except for the end users that you've decided on.

It just slowly builds up. There's no long-term cycle around this massive kind of evaluation, cost and ROI studies, TCOs, and infrastructure investments and projections. You can just like try it out slowly, and if you like what you see and you get in that kind of positive feedback as a developer or as an IT manager or from an end user -- you just slowly build it up and only pay for what you use. And you have the instant ability to scale if it really takes off.

That’s great thing for anybody in business: To be able to try before you buy, without any kind of commitment or contractual commitment or cost-commitment upfront.

Gardner: I am afraid we’re going to have to leave it there, we’re out of time.

We’ve been discussing PaaS and how Bungee Labs has been bringing that concept to market with a service called Bungee Connect, which fulfills much of the underlying functionality for PaaS.

To help us better understand the market opportunity and the trends that support this, we’ve been talking with Phil Wainewright, an independent analyst, director of Procullux Ventures, and a ZDNet SaaS blogger. Good to have you on the show again, Phil.

Wainewright: Pleasure to be here.

Gardner: We’ve also been joined by Alex Barnett, the vice president of community at Bungee Labs. Thank you, Alex.

Barnett: Yes, many thanks for having me on, Dana.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a sponsored BriefingsDirect podcast. Thanks, and come back and join us next time.

Listen to the podcast here. Sponsor: Bungee Labs.

Transcript of BriefingsDirect podcast on platform as a service and on-demand applications deployment trends. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.