Transcript of Dana Gardner's BriefingsDirect Podcast with Executives from Hewlett-Packard on the Business Case for SOA

This is a transcript of HP-sponsored BriefingsDirect podcast with Dana Gardner, recorded June 7, 2006.

Listen to the podcast here.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect[TM]. Today, a high-level discussion, not on the technology of Services Oriented Architecture (SOA), but on the business case -- the business issues: What's driving major enterprises to embrace SOA?

Joining us today are two SOA executives from Hewlett-Packard’s (HP’s) Consulting and Integration Division, Terri Bennett Schoenrock, the executive director of SOA services and consulting integration and J2EE open source programs, as well as Andrew Pugsley, worldwide lead for SOA service development. Thanks for joining us.

Terri Bennett Schoenrock: Thanks Dana, it’s great to be here.

Andrew Pugsley: Thanks Dana.

Gardner: Now, you two do quite a bit of traveling. You are out with folks in the field, customers and enterprises. What are some of the latest and greatest issues -- from a business development perspective -- that companies are focused on when it comes to the decision around moving to SOA? Why don’t we start with you Terri?

Schoenrock: HP and its customers believe that SOA is as much about business transformation as it is about IT transformation. SOA’s adoption is pervasive. Customers are seeing methodologies, tools, and applications changing to adopt SOA concepts and architectures. Business people are reading about SOA in trade journals and business publications, in stock market valuations for their companies, for our companies, and for other companies.

People, processes, and technologies across the enterprise are changing to adopt SOA transformational approaches. What we are seeing is that SOA is transforming business today. It’s about removing barriers between business and IT, and it's about the maturing of organizations, as businesses change and move farther into the new millennium.

Gardner: This SOA transformation involves so many different things: organization, culture, technology, and business process. I keep hearing customers ask: "How do I get started, how do I move from a pilot level into an enterprise-wide level?" Do you get those questions as well?

Schoenrock: Sure. As we look at SOA adoption -- and we work with a number of firms and a number of different customers -- SOA adoption is going to double year over year for the next five years, at least. More and more, our customers are moving from an enterprise-wide horizontal technology strategy to a strategy that says, "How do I link business and IT? How do I develop projects that help businesses understand -- as I have designed enterprise services for reuse, flexible computing services, and common platforms -- to reduce cost, so that they can be shared, so they’re architected well, etc?"

[They’re asking] how do I drive the business projects that raise the visibility of what I have done at the IT enterprise level, so that the business can begin to recognize a competitive advantage, and begin to really derive the benefit of all of this great work?

Gardner: Andrew, from your perspective -- because this subject is so large, because it's encompassing and complex across so many aspects of an enterprise -- when companies try to factor in cost-benefit analysis, what are the business needs that they are focused on? Is this a maturation and consolidation issue, or is this about becoming more agile and fleet in the marketplace -- or some combination? What are you finding are the major business motivators at this point?

Pugsley: There are a few things, Dana. One of the points I’d like to come back to is that you have made the point quite well that the move, or the transformation, to SOA is not just a technology thing. It involves many different aspects of an enterprise, from the skills these people have, the way this organization is set up, right through to how their supply-and-demand chain is established -- including technology.

One of the first things that we see as being key to successfully adopting SOA is for enterprises to actually take that step of understanding, that this is not just an IT thing. This is something that has benefits right across the enterprise, benefits for both business and IT -- but also requires action and change, for both business and IT.

Coming back to your question now, there are two sides to this coin. One side is this whole notion of consolidation and reuse. We have seen some enterprises that are treating SOA as primarily a vehicle for consolidation. And so, they’ve built a business case around consolidating applications and consolidating service and things like that -- and that’s good. They get a business benefit from that, and they treat the other benefits that SOA brings them as nice-to-haves.

But more and more, we are finding that in today’s rapidly changing business world that you can't treat some of those extra things as nice-to-haves. The need to be agile, the need to be able to identify and respond to change, is critical to not just business success, but to the very survival of organizations.

They need the ability to respond to events that happen, from customers releasing a competitive product, to changes in legislation, to changes in the way the marketplace is treating your goods or services. At the same time, there’s also a need to be part of change and take advantage of opportunities, new technologies, and new ideas that you have.

What we see is that while some organizations are saying, “Yes, we get benefits from consolidation” -- and certainly that’s an important thing to include in their business case – the fundamental benefits to SOA are the benefits that come from being more agile.

Gardner: When you talk about agility in this context, are you talking about the business side of the house being able to tell IT what they want to have happen in terms of a process and exception management, and entering into new markets, and then for IT to react to that? Is this really just getting better communication and execution between a business imperative and an IT function -- or is it larger than that?

Pugsley: That’s part of it. We tend to see or describe that interaction as a move away from how we traditionally talked about business and IT alignment as a kind of a static thing. What we really need to strive for now is business-to-IT synchronization -- alignment on an ongoing basis, so that the IT organization is able to respond or proactively respond to different events that happen.

To go one step further, when we talk about change, there’s this sense that you know there are some changes coming up; you know that you are going to release new products next year. You know that your competitors are merging or something like that. A part of the investment in SOA is not just preparing to make plans for those events that you know are going to happen, but also, to position yourself for those unexpected events, for things that might happen, or that you could imagine -- perhaps are unlikely to happen. But if they did happen would have a huge impact.

One of the tricky things with making a business case for SOA is being able to develop a quantitative basis for making decisions about how you are going to prepare for things that are, at least to some extent, uncertain.

Gardner: Terri, this ability to respond to change, do you have any case studies or examples from folks that you have dealt with -- and I know you probably can't share their names at this point without their permission -- but are there examples of how SOA has already fostered these responses toward a change or a dynamic marketplace?

Schoenrock: There are lot of ways SOA is transforming business today. One of the things that we have seen is the more mature an organization becomes, the harder it is to tell business folk from IT folk. Andrew just alluded to this.

One of the things that we have seen is organizations that become so mature related to SOA that they actually spin off an IT organization into its own subsidiary. The IT folk are now business folk, running their own subsidiary as a business, and supporting not only a whole business, but their own business. That’s really flexible business services -- breaking down the barriers between business and IT, and using SOA not just to remove inflexible business systems, but using SOA to remove inflexible business organizations and business silos, increasing organizational agility and really improving the competitiveness of business.

Another thing we have seen is -- when you take a SOA approach and provide the right enterprise architectural services, SOA services, and structured approach to measuring business and measuring IT – that you can ensure that you have services that are valued by the business and valued by IT. That improves the overall competitiveness of that customer. You can then develop an adaptive enterprise that could then support the change a business needs to become competitive.

[SOA] supports the cost-effective environment that business needs to be competitive, because, in the end, it really is about costs. It's about agility, and it’s about access to the information that businesses need in order to get the right competitiveness. That’s what we’re seeing in our customers: in financial services and in the public sector, where it’s not only about competitiveness.

In the public sector it’s about providing access to both constituents, as well as those who are within public sector organizations, especially those who are on the front line of providing defense and security. In manufacturing, it’s about providing agility, as customer preferences change, as manufacturing cost structures need to be driven down. In the telecommunications consumer area things are changing so quickly.

Gardner: This is interesting. On one hand, SOA is extremely inclusive and affects so much of IT and business, but on the other hand each business has its own history and its own legacy. The approach that they've taken could be entirely unique to them or even widely specific within a vertical. How do you take these overarching benefits of SOA and tailor it into highly individualized organizations, both in terms of their IT legacy, as well as their organizational and cultural legacy. Is SOA so agile that it can be overarching and specific -- I’ll open that up to either of you.

Schoenrock: We have customers who have achieved enormous returns on investment. We have a customer -- a financial services customer -- who has achieved a 201% return on investment. HP itself has achieved enormous return on investment from its own SOA initiatives. We have customers all over the globe.

If you look at the four verticals that we focus the strongest on, they include the financial services industry, and especially retail banking; manufacturing and distribution industries; the public sector; and media entertainment and communications sector. In all of those verticals we see a really balanced portfolio.

It's the same worldwide. We focus in three regions: Asia Pacific and Japan; EMEA, which is Europe, Middle East and Africa; and in the Americas, which is predominantly in Canada, the United States, and a few Latin American countries. We have some very strong focus in Brazil and Mexico and a few other countries very specifically. We see a really good balance across industries and across those countries.

Gardner: But in specific enterprises themselves, not just based on geography or a vertical, but because there’s so much individuality, how do you go in as a consulting and integration division with SOA being this large category, and yet still be able to adjust and deal with various specifics. Is this a technology problem or is this a management problem, and how do you face that?

Schoenrock: Actually, we have wonderful "secret sauce," and Andrew is the owner of the secret sauce, but we have two things that we do that are very specific. One is that we have a process that helps our customers very pragmatically address how to link business and IT. It’s a very quick, very easy, low-risk, high-business value process to assess your SOA.

You pick the services that the business cares about the most and that have the highest business value and business impact and the lowest risk from a technology perspective, so that IT can begin to build credibility. You then begin to build wins with the business, and begin to build increased focus. We add to that, something that HP has that’s very highly differentiated -- and that’s our approach to SOA maturity. To do that, we align that to what we call "domains of SOA." We have eight of them, and I want to hand off to Andrew who can explain this far more articulately than I.

Gardner: Yes, I want to hear about the secret sauce.

Schoenrock: This is absolutely very powerful stuff.

Pugsley: Thanks, Terri. The secret sauce is built around these eight domains. And the eight domains capture this notion that you referred to earlier, Dana. This is about technology, yes, but there is more to it than that. We have domains around business, around people, program management, governance, architecture, operations and management, technology itself, and then supply and demand.

What we do with an organization is to work with them first to understand where they are in terms of their maturity toward adopting SOA in each of those domains. Of course that gives you a picture of where you are today.

The next thing you need to look at is where you need to get to. As you point out, every organization is in a different industry or different marketplace, or geographies. Companies have different investments that they have already made and they have a different history.

What we also have associated with a domain model is a set of SOA value propositions. The task is to take these value propositions and really consider them in the context of the specific enterprise and ask whether this value proposition is valid for this particular enterprise in their context, given their strategy.

And by working through that value proposition across each of the SOA domains, we end up with a picture of where we need to take the enterprise. Of course, knowing where you are and where you need to go gives you some indication of what you need to do, what are the tasks, what does the roadmap look like to get there.

But we don’t stop there, because one of the things that I firmly believe is that SOA can bring value to every enterprise. At the same time, not all parts of an enterprise will benefit necessarily to the same extent. What we do then is to start to apply different types of measurement, where we are measuring the ability of different paths of the business to respond to different events. And we have a continuum of events.

So, there are some events that just about any organization will encounter, there are some that are unique to a particular marketplace or geography. Some will be unique to industries. And then, of course, there will be events that each enterprise in itself is facing because of its unique strategy and position.

What we do is develop a measurement -- for each part of the business -- of its essentially core business process. We identify a metric of how well they are able to respond to change, but we also look at that in the context of how important is it for that part of the industry to respond to change.

For example, with one of the Scandinavian telecom companies we have been working with recently, we see a big contrast in the need to be able to react to change in their wholesale business, as compared to their mobile cell phone business. In the wholesale business, they have a small portfolio of products that change relatively infrequently. And their focus is more about managing their partners and suppliers. In their cell phone business they have a huge array of products. They package those products for the marketplace in different ways constantly, and that’s quite a different picture to manage.

And so, in that particular case, when we want to start targeting our SOA investment, we focus on that cell phone business in the product creation areas -- where we are going to get the biggest bang for your buck. The follow-on benefit from that is, in terms of creating a business case, nothing sells better than success. When you've had that first project, and you've had some real impact, taking that and communicating that through the enterprise significantly eases the ongoing process of creating, developing, and managing the business case going forward.

Gardner: As we look at these cost benefit analyses on an enterprise-by-enterprise basis, are you finding in the field that there's a certain hurdle that they need to overcome at the beginning in terms of quite a bit of investment and quite a bit of inertia that needs to be moved through in terms of cultural shift, change, and transformation? Is there some sort of a payoff tipping point here, where the more you get into SOA, the more business value and the more return on investment you get? Is this linear? What sort of trends do you see in terms of business payback from SOA now?

Schoenrock: If we look at our own story -- and HP has done this for thousands of customers -- but if we look at our own story, we can take a look at the projected cost savings.

The cost savings actually start on implementation. When we look at where we measured return on investments; return on investment actually happened on go-live with our own implementation of our e-business center. Return on investment starts Quarter 1. We doubled our revenues. We halved our transaction processing requirements. We really recognized improvements right away. We achieved $1 million in cost reduction from fraud the first year we went live.

So, a lot of initial cost savings. From a projection standpoint, when we look at just the shared service piece of SOA, we think that we are going to be able to achieve a synergy implementing shared services. And those shared services are shared business services, and the shared services that we’re going to get in a virtualized and managed architecture running those business services.

We are actually projecting, just around our e-business architecture, a shared service synergy and cost savings of $70 million that we are taking out of IT. That’s an amazing amount of cost to remove by 2010. We are actually looking for more than that now, based on some of the other cost savings, but that’s just from that one piece we implemented around SOA.

Gardner: Obviously time is on your side if you get going on this sooner rather than later, particularly if you looking for that return on investment. That’s very interesting. From the perspective of those companies that are forecasting these sorts of returns, what can you offer them in terms of a get-started, get-into-it methodology? Within your organization, how should companies start working with HP, for example, in order to get going on this?

Schoenrock: As a transformation journey to build an adaptive enterprise, it starts with an identification of a key business initiative. We talked about that earlier. We believe that they should start that journey with us in an SOA assessment. We believe they should use our approach to measure SOA maturity and our capability to help them bring the business constituents into their project and really begin to link business and IT initiatives.

Gardner: On this point of getting started, you mentioned the SOA assessment. How long typically does that take? I know it’s going to vary a lot by company and verticals, but for a large enterprise -- what are we are looking at here in terms of creating a real assessment? Is this is a matter of months, weeks, quarters?

Schoenrock: It's a matter of weeks -- probably in the range of four to six weeks, depending on global scope and the scope of the actual assessment.

Gardner: We are just about out of time. I want to pass it off one more time to Andrew. In terms of assessment for those people that perhaps have had their interest piqued here, what is it that you are bringing to the table? Can you actually come out and give them a forecast on savings and business case, and what are the business values that you can provide just from this assessment phase?

Pugsley: One of the things that I point out here is that when you do the assessment our goal is not to come and do the assessment to somebody, but rather to come out and do an assessment with the people from that enterprise.

We work with them to help the organization assess their own situation. That’s very important, because ultimately the people working within that enterprise understand how the business works, they understand all of the spoken, as well as the unspoken, challenges that they are facing.

What we would tend to do, for example, is talk about percentage improvement in time-to-market. From that point, the customers’ organization can then interpret what that would mean for them. What we do is provide a basis for coming out with some final numbers.

But typically, we wouldn’t go quite so far as to give a fixed limit on that. Having said that, there is still that consolidation benefit piece that I mentioned. Often with that, it's quite reasonable to come up with some much firmer numbers, because we have a fairly well-defined methodology for consolidating applications and services. And that’s kind of core business. We come in and often we can give quite a good indication of how much saving would come from that.

On the agility side, it’s more tricky, because you are dealing a lot more with unexpected things. What we tend to do as part of our analysis is look at what are the events that are potentially going to happen, what’s the impact of those events, what’s the cost of the thing, how should they respond to those events, what’s the likelihood of that event occurring. From there, we can build up a picture not unlike risk assessment.

Gardner: It sounds like you would get a payoff from consolidation, a payoff from reduction of redundancy and reuse across services, and that then probably biggest payoff over time is the ability to be agile and fleet -- not only in your expected strategic challenges, but for the unexpected. What seems essential is being able to move quickly in a marketplace, to adjust and adapt [regardless of the challenges].

Pugsley: That’s probably the key. Ultimately, that will be the key benefit that people will get from SOA.

Gardner: Thank you. This has been a discussion on the business case and rationale for the ramp-up around SOA. We have been talking with executives from HP's Consulting and Integration Division, Terri Bennett Schoenrock, the executive director of SOA and J2EE open source programs, and also Andrew Pugsli, worldwide lead for SOA service development.

This is Dana Gardner, principal analyst at Interarbor Solutions. Thanks for joining us at BusinessDirect, and thank you to Terri and Andrew.

Schoenrock: Thanks a lot, Dana.

Pugsley: Thank you, Dana.

Listen to the podcast here.

Transcript of Gardner's BriefingsDirect Podcast With Executives from Hewlett-Packard. Copyright Interarbor Solutions, LLC, 2006. All rights reserved.

Transcript of Dana Gardner's BriefingsDirect Podcast With Wall Street Analyst Brent Williams on Eclipse Foundation

This is a transcript of Eclipse Foundation-sponsored BriefingsDirect podcast with Dana Gardner, recorded June 7, 2006.

Listen to the podcast here.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions and you are listening to a sponsored BriefingsDirect[TM] podcast. Today, a discussion about the “Eclipse Effect.”

The Eclipse Foundation has grown in popularity for the past two or three years and really is on the cutting edge in de facto standards for development environments of major Java software projects, particularly among software companies themselves. To discuss this subject, we have Brent Williams, a Senior Analyst at KeyBanc Capital Markets. Brent has been a stock analyst for some 10 years. Prior to that, was a tools analyst at Gartner, and before that an operating systems and applications analyst at IDC. He has also spent some time as a developer. Welcome to the show, Brent.

Brent Williams: Well, thanks very much for having me, Dana. I'm glad to be here.

Gardner: You have a little bit of business to attend to in terms of your ability to discuss these subjects as a stock analyst. Can you go ahead and provide some clarity?

Williams: As part of our ongoing, “Keep Analysts Out of Jail program” and “Keep the Lawyers Happy program,” I've got to let you know that we may talk about publicly traded companies. My firm, KeyBanc Capital Markets, may have a relationship with those companies, including making markets in their stock, soliciting to provide them with investment banking services, or other forms of business relationship. On the other hand, you should also note that none of the companies that we discuss are ones that I hold or any members of my family hold any investment stake in any capacity.

Gardner: Alright. Let’s get into the meat of the subject: Eclipse Foundation. You have pointed out in some of the presentations I have seen that Eclipse is unique in that it straddles both business and technology. Describe what you mean by that -- and is this something that’s new? Have we ever really seen anything like the “Eclipse Effect” before?

Williams: What I meant by that was that Eclipse came along, taking technology that was developed commercially under the standard model at IBM, and brought it out to open source. Because of the nature of the tools business, the IBM sponsorship, and what this project was all about, it really attracted corporate developers.

If you go back to the early days of Linux, it was all individual contributors working on pieces of the project that were of interest to them. Eclipse came out as a fully finished piece of production-ready code. And, so it just didn’t evolve that way.

When Eclipse moved from a foundation or from a consortium into a really independent foundation that really had no material control from IBM, it was really set up to say: "How do we accommodate the business needs of all of these companies that are contributing code to this organization; and how do we do that to create a neutral playing field, because we recognize, many of these companies will be fierce competitors?"

That intentional accommodation of corporate needs was built into the organization from day one, and it’s been built into open source projects over time. And so, when you talk about the Eclipse Effect, it means that Eclipse has taken significant amounts of contributed corporate technology and has run with it, but it's also managed to accomplish a dramatic market share.

According to one survey I've seen, Eclipse is a tool of choice for about two-thirds of the Java developers in the world, and it’s coming up fast as a tool for many other platforms as well. So it's gotten tremendous market-share gains, which I think validates that the approach for this particular type of project really worked.

Gardner: Eclipse started out as an integrated development environment (IDE). It since branched out into some other areas. Are we really talking about the best of both worlds here in terms of commercial command-and-control development, as well as the viral and lower-cost development of the open source community approach?

Williams: That’s exactly it. Part of the way that they have been able to pull off this seeming contradiction is that they have a fairly loose project structure. In an operating system, by comparison, the Linux kernel all of the pieces are very tightly interdependent; and so, if there’s a bug or if there’s an integration issue between a couple of modules of the kernel, the whole thing comes crashing down and doesn’t work very well.

But in the Eclipse project, the technology is much more loosely organized. The end result is, that companies wanting to contribute a particular piece to Eclipse can go off and build that in a conventional structure, then contribute the product to open source. They don’t have to worry so much about dependencies with other projects. So, they can use a standard structure to get their area or their projects built, and then go and take advantage of open source. When you come out with finished code, we are actually starting to see the community come in and do enhancements off these more monolithic contributions from the corporations.

Gardner: As we have seen swift adoption, there seems to have been some tipping point, or critical mass, where the interdependency of those contributing and those using, starts to well up -- and there is more opportunity for people to contribute, which makes it more valuable, which brings more people into the community, which then prompts them to contribute. Is that what we are seeing: a powerful adoption benefit here?

Williams: I think we are seeing an inflection point, and that’s come up in maybe the last 12 to 18 months. That’s exactly the sort of virtual circle that you are describing. What's different, maybe just in degree or maybe in the way that it’s accomplished, is that the structure that Eclipse brings to bear makes it very, very easy for people who are focused on certain types of things; and are what they refer to in Eclipse as "add-in providers."

They maybe unlock some particular piece of hardware, or a gateway to older legacy data -- something like that. They can fit into that project or into that environment very effectively, perhaps more so than in other major platform architectures. That's really been one of the factors that’s helped this inflection point ramp up so fast, because the more focused add-on providers you can get out there with access to RFID readers or bar-code scanners, the more commitment they’ll have for that platform, and the more valuable the platform becomes.

Gardner: Now, an integrated development environment -- this is not a trivial piece of software, this is not even something on the same level of, say, a Web server. It traditionally required a great deal of research and development and effort by companies like Borland and Microsoft, who have been leaders in tools. For this to happen in this environment and for this inflection point to take place, does it portend a real shift in how software is developed, or is Eclipse a one-hit wonder that will probably not be repeated. And if this is something that is a harbinger of more similar types of activities to come, what does that mean in general for the software business?

Williams: Well, let me answer these two pieces in reverse order. We are entering a point in the software business where, if you look back to the height of the Internet bubble, there was a lot of stuff coming to market, that was features disguised as products, disguised as companies. Basically any somewhat-decent idea that was kicking around inside of somebody’s head went out and got funding, whether or not it was a sustainable product, or even company. When it got funding, it went public.

And so, what you had was a trough of despair for few years after that, when the idea file had been drained of even average ideas. There weren’t any really new technologies coming to market. We’re at a point now in the software business where we’re on the rebound from that drought of good new ideas; and we’re starting to see that broadly in many areas.

So, I think that, yes, development tools fall into one such area. It's been a fairly stagnant market until the last couple of years or so, since Java began to attain prominence in the mid-1990s. A lot of Java development environment decisions were made. Things went fairly quiet until Eclipse came along, and that has started to revitalize it. In general, we are in a period where there’s lot of good new technology coming to market that people are taking a look at. You are starting to see people actually put their dollars behind buying some of this technology, which they weren’t doing in the 2001-2003 time-frame. And now I have completely forgotten your question.

Gardner: Is this a one-hit wonder? That's to say, is what's happened with Eclipse unique, or are we seeing a larger shift toward open community development frameworks that are embracing the tipping effect that happens where adoption and contribution begets more adoption that begets more contribution? And does this happen outside of a traditional licensed software business model? And if so, what does that portend for folks like Microsoft, IBM, Oracle, and SAP?

Williams: There are a couple of interesting things going on; and I have been around development environments for a lot of years. As you mentioned, I covered development environments in the early nineties at Gartner Group and left to go to Wall Street just as Java was starting to become prominent.

The thing that’s happening is that the integrated part of integrated development environments is really undergoing change. If you look back historically to Visual Basic, Borland, or some of the stuff that Sun Microsystems has acquired or any of these development environments -- PowerBuilder, you name it -- they were all tightly integrated with a single vision and a single way of doing things. If you wanted to do a re-think of that, it was all-or-nothing. If you didn’t like the way that, let’s say, Borland’s Delphi handled database access, well, you had to just sort of live with what they did, or you had to go to a completely different tool, which would probably have faults of it own.

These were very monolithic, and it was difficult to integrate, say legacy 3270 access or something like that to the development environment, but you had to buy into a particular way of doing things. Then, you were at the whim of the vendor to do that. Eclipse has changed that a lot. Java had to a certain extent, but it was still proprietary vendors. Eclipse changes this dramatically, because the various bits of the IDE are very much decoupled and almost dis-integrated. They can be swapped out, reassembled, and reorganized much more flexibly than any development environment that I can think of at the moment.

If you don’t like something about Eclipse, you have the chance to go out and replace it and end up with a more best-of-breed solution. So the end result is, that a development environment or development strategy based on Eclipse can evolve over time more smoothly -- unlike: "Okay, I get PowerBuilder in here in client-server era, then the Internet comes along. PowerBuilder’s Internet support has taken them a long time to get out there, and then they don’t really make the curve very well. So, you have to just dump PowerBuilder and go on with something else." That's not a very smooth move forward -- in fits and starts every five or six or seven years.

Gardner: So, I guess we have now gotten to the point where the framework that developers are comfortable with, as long as it adheres to Eclipse, gives them an opportunity to do what they want to do, in the way they want to do it and yet not feel that they are outside of the larger environment that allows us to be compatible with other frameworks and other activities by other groups and developers. Is that fair?

Williams: That’s absolutely right. Even these days, whenever somebody uses the word framework, I find myself gritting my teeth unconsciously. If you hark back, I think this is really fallout of the mainframe era. If you hark it back a decade or so ago, a number of folks were talking about frameworks with a capital “F," and these were really complicated. I mean, you had everybody from Anderson Consulting -- where they called them methodologies, but conceptually equivalent -- and all the big system integrators -- you had guys like IBM, EDS, and a bunch of other folks -- talk about frameworks.

The idea was that if you bought into our one, big framework -- the one, true way to build software -- then your productivity would go through the roof, and life would be wonderful. The old style of frameworks was just another kind of religious buy. You had to buy into this whole way of doing things before you could buy the product. That was the same problem we had with early client-server tools, with those monolithic closed-development environments like PowerBuilder and stuff that I referred to.

Fast forward to today. Because of the open, loosely coupled approach to Eclipse, if you don’t like whatever framework is at hand, if you want to change to some other framework that supports the platform, you could do that. You don't have to heave out all your code. You don't have to start from square one. It gives you what frameworks can offer in the best of circumstances, but it does it without having to make you start from scratch to change frameworks.

Gardner: So, we can clearly see some technology benefits -- agility, flexibility and openness -- but there has to also be some impact on the economics and business of software. I suppose in the past there was a bit of a quid pro quo or at least a relationship between the tools, which were often sold at cost, or even a loss, because they tied the application and developer to a platform; and the monetization happened in that volume selling of the license for the platform.

Well, now that -- as you pointed out -- we are loosely coupled, we are not tied to a specific platform, how does the modernization happen? What does this mean for the folks who are making a transition from licensed software tied to the platform to this new era where we have got loosely coupled Web services, frameworks, and developers who are really not even thinking about what platform their code might be operating on?

Williams: The last thing you said hints at it the old model where you used a low price development tool as kind of a free "vial of crack" to get them hooked on your platform. That model only worked in an era where there weren't decisions already cast in stone about platforms. Right?

In the early days of client-server that model was brilliant because people hadn’t really made a decision about, "This is our platform for client-server type stuff." It was all new market, and that’s the right way to reach that market. On the other hand, saving somebody a thousand dollars, or whatever it is, on the development tool license, when the platform decision is already made, it’s really not going to do much for you. The cost of moving from UNIX to .NET is in no way going to approach the economics of free .NET tools, which is not going to close the gap.

It’s like if you buy a new car and you get free gas for a year. That might sway your decision. But if you buy a new car and you get those little things that screw on the tires to keep the air from leaking out free for a year, it’s probably not enough to make a difference. So, platform decisions are already made. Folks like IBM and a lot of folks from the Microsoft universe are going out there and saying the next opportunity is not to get people on the platform, because everybody has already got a whole mix of platforms.

We are no longer playing for, “Hey, we will get you on our platform. Our platform will solve all your problems. You will throw out all your other platforms -- and we’ll have a monopoly.”

Gardner: The old rip-and-replace methodology.

Williams: Yeah, rip-and-replace, and give all of your business to a single vendor. I don’t think that’s going to happen. IBM, for instance, is tremendously interested in Eclipse, because its flexible architecture allows it to surface capabilities from legacy systems into Internet Web-based applications.

You can make better use of assets that you have, and the end result might be that, instead of just trying to keep the mainframe business growing at a slow level of growth, IBM might be able to accelerate the growth of mainframes. That's not because that’s becoming a monopoly, but just because people will store more data on mainframes because they can get to it easier -- and they can get to it easier because they can integrate it into any application -- Web-based, client-server, whatever -- because of Eclipse.

Gardner: Perhaps one of the business impacts here is that a developer and an architect have a lower risk with Eclipse because they have both backward as well as forward compatibility with platforms; and in having that ability to be compatible, both to the past as well as the future, this gives new life blood to some of the older sun-setting platforms and reduces the risk of having to change framework and tools, should you want to move ahead to a new platform.

Williams: That’s exactly right. This is just another slant on what I was suggesting earlier about Eclipse taking you from having to live with what you’ve got until a revolutionary change in development environment comes along. Eclipse supports incremental evolutionary change more effectively, allowing customers to take advantage of those technologies, and allowing vendors to make money supporting that.

I think it’s a win-win situation when IBM has extended capabilities of some of the non-relational databases like Information Management System (IMS), so that they can capture what's happening in real time and generate streams of events to be pushed back out to a Web-based application. And, that’s a new capability for IMS. With a development solution that allows developers to take advantage of that on the Web-side -- since there is not that much IMS expertise out there in the world these days -- when you can get to that stuff easily, you can take advantage of your existing legacy code in a new way.

That’s usually great economics for the customer, and IBM can sell more IMS licenses, which, given the amount of R&D they spent keeping IMS maintained and improving it, creates a huge win for IBM. It really does give win-wins to both the customer and the vendor.

Gardner: There are some other trends that are bubbling up in the industry that have some impact here. I'm thinking about Service Oriented Architecture (SOA). You might have different applications running on different platforms, and not only can you take advantage of that from a development perspective using Eclipse, but on the runtime and operations and production side of things, you can expose those services and suddenly you have an opportunity of continuing to operate for a longer period of time for a lower total cost of the lifecycle of the application and platform.

That also raises the issue about where is the next value-add. Is it in the integration, and is there another level of tool that you’ll be depending upon to stitch together and orchestrate and composite these applications? And, not to be too long-winded, but what does Eclipse bring to that level of tool; how does Eclipse impact SOA?

Williams: Well, I think this evolutionary approach is certainly very much in line with SOA. Instead of going out and ripping out huge chunks of systems just because there is no other way to integrate stuff effectively, now I can surface bits -- not all at once, but over time -- that are important and I can effectively hook them all together in a way that’s already platform independent.

SOA is really about using incremental evolution of legacy code to try and produce revolutionary results, being able to do business in a far more productive way that I had in the past. Everybody knows SOA is a big deal; its going to take a long time, but it is a big deal.

Eclipse helps because -- I think you gave it away in the use of the word "orchestration" -- when you are building services, you might use one development approach to write code, with Java based IDE, which Eclipse is already very good at, and to stitch those things together, it might be a different team of people that are stitching these services together, and they are using an orchestration approach.

Having that work inside the Eclipse umbrella is very attractive to customers because they don’t have to have a completely separate product that has nothing in common with the Java IDE. The notion of business process management systems, or workflow management systems had been around for a while, but they’ve all been standalone products from different vendors than your ‘C’ Compilers or Java Tools guys or your database guys.

If those guys can operate under Eclipse with their own unique vision of workflow and orchestration, and the software development environment happens there under the Eclipse umbrella, then it’s a lot easier to have all those guys coordinating their efforts more effectively. The tools can all interface more effectively. That gives you more reliable applications, and it gets it done in less time.

Gardner: Perhaps some of the overview impact here is that the vendors are going through some transition, facing some challenges in terms of a shifting business model, but there should be plenty of opportunity for them to monetize and find value and bring more business benefits to their end-users over time.

I suppose the biggest winner here, the win-win, is for those enterprises that have reduced risk, have an opportunity to gain agility and can finally bring somewhat of an end-to-end understanding of benefit or control over development. Or, am I over-hyping some of the benefits to the end-user enterprise here?

Williams: It’s one of these things where there is enough interesting stuff going on, that I don’t think you are over-hyping. The over-hyping zone is in promising how fast this is going to go. We are now at a point where, for the first time, we can achieve these goals; that’s great news.

Just saying it’s possible is quite legitimate; saying that it’s going to happen in a short period of time -- whether that’s six months or two or three years -- that’s probably a little over-hyping. You certainly didn’t do that. I think that you are absolutely right.

The enterprises that can get to this can get themselves on a platform that will support incremental evolution of development processes. So, you don't have to go in fits and starts every five years, like you do with, a silo-based tool. Organizations that can do that will win over the long term.

So, yes, this is a reward for the clever. But interestingly, we are just talking about linear extensions of what people understand Eclipse to be about today. The other thing that we are starting to see is effects where companies are able to use Eclipse support in their products in ways that are bolstering their business and that aren’t terribly obvious. We have seen this in the case of, for example, Actuate which sponsors BIRT, which is one of the more popular tools, a Java Reporting Engine that can be embedded in your Java app. It’s part of the Eclipse platform.

Gardner: Right.

Williams: What’s interesting is that the Actuate guys went out and they -- as we talked about earlier -- used a very standardized command-and-control development approach to build the first two releases of BIRT, got it out there in community, and now they are building a community of developers around it. They are working in a more classical in-source fashion.

Actuate’s hope was to use the project to give them a stream of revenue for low-end business intelligence. Actuate’s problem had been that they were pinned at a very high end of the market, like Lamborghini is pinned up at the very high end of the car market. It’s hard for them to sell down into a more mass-market configuration without destroying their brand.

Actuate had been kind of the Lamborghini of business intelligence, and other companies that were more mid-market had outrun them. So, they went and had an Eclipse strategy, launched the BIRT product, and did a lot of good stuff as how they built their community. Now what they are finding is that it’s actually helping them sell the high end Lamborghini product, which isn’t open source. The end result is that having the Eclipse product not only helps them address a new market that they weren’t able to reach, but it actually helps them address their existing markets even more effectively.

Gardner: So, the business benefit for the vendors is that they can reduce their overall R&D spending on some of their new products by -- after a few iterations -- bringing it into a community; And, they can get the benefit of that larger community adoption becoming aware of their other commercial products and/or perhaps have additional monetization around service support, maintenance, and so forth.

Williams: Exactly. And that's a very unexpected kind of result -- the idea that they are getting rewarded for being a part of Eclipse on stuff that even isn’t directly Eclipse-related revenue. I think you'll see other people out there looking at using Eclipse, perhaps as BEA Systems has done with their Beehive project, contributing code to Eclipse to help achieve other strategic aims within their businesses than just, as they say, driving a support revenue stream from Eclipse-related stuff, as they do for their current projects.

Gardner: So, in effect, the Eclipse Foundation and community has provided a viral marketing benefit to these vendors, that they would have to spend a great deal of money attaining on their own -- with their own direct-sales force trying to create their own community and their own lock-in around a proprietary stack.

Williams: That’s exactly right; and this becomes a benefit to customers as well; as vendors start to use the interest, the market share, and the mind-share that Eclipse has among the customers, then they start to find these non-obvious business models.

That accelerates the momentum around the platform still further. The end result to the vendor community is that no longer is it a forward-thinking, bold, risky move, but rather an interesting one, to join Eclipse and contribute stuff to open source. It becomes just what you do for some portion of your business.

I am not saying for a second, that all code that’s currently commercial is going to open source. It's probably not. But, like the BEA guys have done, the Actuate guys have done, and some other folks have done, contributing some portion of your code asset to open source is going to provide dividends to you, the vendor, and its going to provide huge dividends to the customer community.

Gardner: I suppose the net takeaway here is that Eclipse Foundation has given a community and a viral distribution benefit to the vendors, the corporations and the users. They have had significantly reduced risk about making choices around platform.

Williams: That’s exactly right.

Gardner: That sounds like a nice combination.

Williams: What's interesting is that this is a very unique combination at the moment. But if you look at other areas, one of the things that have happened is people in industries outside of software are looking at what Eclipse is doing and they are saying: "Hey, this is really intriguing."

So, a couple of success stories include Procter & Gamble and a thing called InnoCentive, which was started by Eli Lilly, the drug manufacturers, to do essentially outsourced community-based science or product research and development. The exact methods are somewhat different than the way Eclipse works.

All of this was inspired by the work that the Eclipse Foundation has done as an organization, as a way of bringing companies that are often competitive together to do collaborative innovation among users, vendors, and competitors, and to have it work out well, so that everybody has real economic opportunities. The proof that Eclipse is actually doing this is in looking at how this notion of collaborative innovation is spreading to industries that have nothing to do with software.

Gardner: So, the Eclipse Effect is not, by any stretch, through – it’s just moving outward from its IT roots.

Williams: That’s exactly right. The Eclipse guys, as near as I could tell, are fairly sharp at understanding what's given them success. They've got a ways to go, but I think, you can actually see, without being excessively hype-driven, that in part because of Eclipse, and in part because of the attractiveness of open source in so many areas, that collaborative open innovation becomes an important way of doing all kinds of things.

It's not going to be the sort of circus show like, “Oh! Look, there is a bunch of hippies; they think they can write an operating system that will take the market share from Microsoft.” That was the perception around six or seven years ago.

Now, there may be some hippies involved -- many of them are on the payroll of these vendors, and they are already taking a lot of share from Microsoft -- it's no longer a freak show. This collaborative innovation model with a structure that allows competitors to have an even playing field and maximize those opportunities for vendors and benefits to customers, is just going to be a way that innovation happens in this increasingly globally outsourced to off-shore kind of world.

Gardner: Brent, I want to thank you very much for joining us here. We have been discussing the Eclipse Effect in community innovation, how it began with development tools and extended into other areas, and perhaps beyond IT altogether. Brent Williams is the Senior Analyst at KeyBanc Capital markets. Thanks very much for joining us here today.

Williams: Well, thanks very much for having me, Dana.

Listen to the podcast here.

Transcript of Eclipse Fouundation-sponsored BriefingsDirect podcast, recorded June 7, 2006. Copyright Interarbor Solutions, LLC, 2006. All rights reserved.