BriefingsDirect SOA Insights Analysts on the SOA Consortium's Formation and Goals with OMG CEO Richard Soley

Edited transcript of weekly BriefingsDirect[TM/SM] SOA Insights Edition, recorded March 9, 2007.

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 SOA Insights Edition, Vol. 14. This is a weekly discussion and dissection of Service Oriented Architecture (SOA) related news and events with the panel of industry analysts and guests. I am your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet software strategies blogger and Redmond Developer News Magazine columnist.

Our panel this week consists of show regular, Steve Garone. Steve is a former IDC group vice president, founder of the AlignIT Group, and an independent industry analyst. Welcome to the show again, Steve.

Steve Garone: Hi, Dana. Great to be here.

Gardner: Also joining us is Joe McKendrick. He is a research consultant, columnist at Database Trends and a blogger at ZDNet and ebizQ. Thanks for coming, Joe.

Joe McKendrick: Good morning, Dana.

Gardner: Also, we have Tony Baer. He is a principal at onStrategies, and blogger at Sandhill.com and ebizQ. Thanks for joining, Tony.

Tony Baer: Hi, Dana.

Gardner: Also joining us, Jim Kobielus. Jim is a principal analyst at Current Analysis. Welcome again to the show.

Jim Kobielus: Hi, everybody.

Gardner: Our guest this week is Dr. Richard Soley, the chairman and CEO of the Object Management Group (OMG). Welcome back to the show, Richard.

Richard Soley: Well, thanks for the invitation. I am happy to be here.

Gardner: We're going to be digging into a few items this week, principally to discuss the new SOA Consortium. We are going to learn more about what's going on with that. It’s an interesting approach, combining end-user organizations and enterprises along with vendors to promote adoption and, I suppose, further definition of the scope of SOA.

We’ll also be discussing some of the events at EclipseCon, wrapping up for the week of March 5, 2007.

Gardner: First for those of our listeners who are not familiar with the greater details of OMG, why don’t you give us the elevator pitch, Richard, on OMG, its mission, and where it’s headed?

Soley: Sure, the Object Management Group is an 18-year-old consortium of software users and vendors, academics, and a growing number of government institutions focused on delivering standards to make interoperability and portability a reality. We were founded in 1989 focused on object technology, later grew into distributed object technology, and were best known for the first few years for our Common Object Request Broker Architecture (CORBA).

In 1997, we moved in two new directions; one being the adoption of a unified modeling language with the clever name, Unified Modeling Language (UML), and also into vertical markets -- originally healthcare, finance, telecommunications, and manufacturing, although we are now in about 25 different markets, everything from robotics to regulatory compliance.

In 2000, we actually leveraged that modeling technology and made it the base technology for all of the efforts that we have under way. So, we defined business models and software models, and, in some cases, even hardware models and process models.

The next big leap came in 2005, when we merged with Business Process Management Initiative (BPMI.org), so that now all of the modeling languages from meta modeling languages like Meta-Object Facility (MOF), to business modeling languages like Business Process Modeling Notation (BPMN), to software modeling languages like UML, and systems engineering languages like SysML are all in one place. That’s been our focus, but looked at from another dimension, what my staff is really good at is getting competitors to agree on things.

We have been doing that at OMG for 18 years with, at this time, between 500 and 600 member companies. We were approached by a group of 11 companies to create a community around SOA, an advocacy group, not a standards group, which is why it’s separate from OMG. We strongly believe that SOA isn’t a technology at all, but rather an approach to achieve business agility. It’s not a technology, but rather a business strategy.

Gardner: Well, it certainly seems to fit in well with the heritage and the direction that OMG has taken. This is really an industry development that’s ready-made for many of the values that you bring to the table.

Soley: I appreciate that and I think that’s fair. But it’s important to understand that this is not a standards organization. There are plenty of organizations focused on SOA standards and, in fact, OMG is one of them. Let’s get this straight upfront -- we are going to pronounce it SOA (So-wah) from now on, because, otherwise you can’t say, "SOA what?"

Our SOA group at OMG has been focused on modeling SOA, modeling for software assurance, and modeling for software producibility, and so forth. At the other end of the spectrum, you have organizations like W3C and OASIS that are doing a great job designing the protocols and languages at the pipe level -- how do we connect the systems together?

That hasn’t been our primary focus in over a decade, so we are not in that space, but the advocacy group is exactly that. It’s an advocacy group. How do we help the CIO? And, we call this "Corner Office SOA." How do we help the CIO get the news across to the rest of the C-suite that this is not a technology but a business strategy, and a business strategy that can deliver agility and a better bottom line?

Second, "Ground Floor SOA." How do we help the enterprise architect, the domain architect, the data architect get the word across to his alter ego in the line of business that this is a business strategy and not a technology and it’s something he needs to pay attention to?

Gardner: Back on Feb. 12, the SOA Consortium announced its formation of this advocacy group, and it’s quite a nice mix of organizations. You’ve got such enterprises as Avis, Bank of America, CellExchange, WebEx -- I suppose WebEx [now part of Cisco] is a vendor, but probably could be both -- and then we’ve also got some very large influential vendors, BEA, Cisco, IBM, SAP and HP.

Tell us a little bit about what the goal of this organization is -- combining, I guess, the constituencies of the end-user issues and vendor issues. You’ve had some of these closed-door summits over the last several weeks to come up with a charter. Tell us what you can about what took place at these events and what is shaping up as the charter, given you’re straddling the fence between the user and vendor organizations.

Soley: It’s important first of all to note the mix of users and vendors. We are currently running 3-to-1 end-users to vendors, and that’s because the focus is on this advocacy activity. It’s not on whose SOA infrastructure we should buy and "Our Web service is cool," or any of those questions. I am guessing that we are actually going to be more like 5-to-1 or 10-to-1 end-users to vendors eventually, but, as you can see, on Feb. 12 four vendors stepped up to the plate to fund it and get it off the ground. They were BEA, Cisco, IBM, and SAP. As an old consortium hand, I listed those in alphabetical order.

You also saw, as you said, some very dedicated end-users who have ideas about how to get the idea across to the lines of business that this is not a technology play, but a business agility play. Some you didn’t mention, for example Wells Fargo, and, of course, Object Management Group ourselves are a member, as well as the Integration Consortium. So, that’s another differentiator from OMG, which is about half end-users and half vendors. We expect that the SOA Consortium is going to weighted toward end-users, although there will be a couple of sponsors joining.

Gardner: So, with this predominance of users, what do they say? What do they want your organization do for them?

Soley: Number one, they want to be truly vendor neutral. Over the last two years, there have been various alliances of vendors saying, "We have created this" – their usual common phrase is -- "SOA alliance to help our customers understand the products in the SOA space." That’s wonderful. That’s all well and good. That’s how the industry works.

But you notice that there are always one or two vendors and one or two of their top customers. This is four major vendor-sponsors, a couple of more that are participating and might be sponsors later, and a lot more end-users, because what they are looking for is understanding the business strategy, not trying to decide which product to buy to "SOAfy" their infrastructure. That’s a very important differentiator.

They are not building reference models. They are sharing case studies. For example, our enterprise architects and our community of practice is showing case studies of success stories and, more importantly, failure stories, best practices, what works, what doesn’t work? We have even had sessions on how to influence project managers and product managers in the line of business to understand business strategies in general, rather than think of us as “the guy who fixes my Treo.”

We received a lot of feedback from CIOs and CTOs during the [early] summits that said this is very important. We had a Fortune 100 CIO who came into the New York summit. This person is CIO of a multi-billion dollar travel organization, and the opening gambit that we heard was, “Look, this is just a technology play, and if one of my technology guys hadn’t told me I had to be here, I wouldn’t be here. I’ve already told the CEO that SOA is a technical thing, and we’ll take care of it.”

At the end of the summit, this particular CIO stayed an extra half hour and said, “The most important thing I learned is that I can now understand how I can position this as -- rather than a technology play -- a business agility play. That will support the efforts that I am making to make our business processes understood, to write them down in a way that’s reusable and discoverable, and in a way that I can make them more efficient. And, I am going to go back to the CEO and say it’s not a technology play.”

[Editor's note: More news has come from the SOA Consortium since this podcast recording.]

Gardner: Well, this gentleman obviously had not been listening to our podcast series. Let’s go to the panel.

Steve Garone, we’ve talked about advocacy and evangelism, and the intersection of the business and technology values around it for quite sometime now, and we’ve mentioned that politics is an important aspect of this cultural shift. Do you think an advocacy group like this is a good thing for the politics, in terms of getting people on the same page? And, what would you pose as some of the necessary ingredients for success for an activity like this?

Garone: It’s a great question, Dana. First of all, Richard, that sounded like a great case study, and certainly makes the case that this group is going in the right direction. The issues that seem to surface come from two directions. One, and I know, Richard, from some of the information I’ve seen in this alliance, that you guys have considered this, is that many organizations that have gone through some SOA activities up to this point. These have focused primarily, and in some cases exclusively, on cost saving and not business agility. Getting that message across I think is a very important issue, in terms of getting acceleration around SOA adoption.

Obviously, it's very important to convince the higher-ups within an organization that this is something that they can benefit from, from a business standpoint. One of the key issues also is that there tends to be sort of a push-pull, or a lack of communication and understanding, between the business functions within an organization, and that, from the line of business standpoint, can certainly benefit business agility and the IT folks. Of course, there's been a lot of activity around tools, standards, and technologies to help bridge that gap, but I think it’s still a pretty important issue. So, those are the major areas that I would look at, and it sounds like you guys are addressing them to some extent.

Soley: The first is a very important issue for us, and second is a really tough one to get past. IT has traditionally focused in most organizations on what are the right tools to achieve what lines of business are telling us we need to achieve. Sure, there are going to be tools and there are going to be technologies and there are going to be frameworks to help you implement the SOA strategy, but it’s the other way around. It’s "What is it we need to achieve?" And, what we need to achieve is fairly easy to explain, right? What we need to achieve is capturing business processes, so that we can find them, so that we can make them more efficient, and so that we can reuse them -- and this is nothing new.

What’s new here is the message that we are not just talking about workflow. We are not just talking about processes that can be automated. We are talking about any of the processes, especially customer-facing, but any value-chain processes within the organization that we might want to reuse.

Gardner: I'd like to encourage any of the analysts to kick in with their questions. I'd just like to start off with a quick one. Richard, one of the things we come up against a lot, when we talk to our guests and we examine some of the events that are unfolding, is complexity.

People are baffled in that there’s just so much, and the more you dig down, it seems daunting. It seems difficult to manage things horizontally, and therefore you relegate it to projects and pilot types of affairs. Is there anything that you expect to be doing through an advocacy role, inasmuch as you understand and are participating in this, that can deal with helping people manage the complexity issues for SOA?

Soley: You know, that’s a great point. I would like to answer in two different dimensions. First, as you can see, we are making top-down advocacy the core of what we do. If you start with your developers and try to work your way up, you are not going to change the way that company thinks about business process, and you are not going to have an effect on business agility. So, that’s why we're having the CIO Summits. And we will be continuing to do those.

Starting in June we are planning on doing them quarterly with a small number of CIOs and CTOs, government agencies, large corporations, as well as non-governmental organizations (NGOs). We actually had an NGO participate in our San Francisco event. We'll use those events not only to make sure we stay on track, but also to get the word out about what we are trying to do here, which is a top-down focus on business process and business agility.

By the way, that’s working. The participants at the events we had were very enthusiastic about the consortium. There was active participation throughout the sessions. In fact there was so much interaction that the round table discussion, which was supposed to be after the presentation, was embedded within SOA Consortium presentation at every stop. So, that’s one, and I’ve lost the thread for the second. I should have written it down.

Gardner: That it was kind of complex.

Soley: Yes, there is complexity involved in capturing the business processes in a way that makes them reusable and discoverable and to make them more efficient, but you always are going to have that complexity, and the question is, "Where is the complexity best spent? Is it best spent upfront, so that I’ve got a description of the process that I can reuse, find, and make more efficient, or is it best spent by the people trying to implement the process, looking at an ambiguous description of a process, in, at best English, and trying to figure out every single time, what in the world it means?"

I would rather do that once, capture it upfront in a rigorous fashion, rigorous both from the standpoint of how it’s captured a formal language, but also the way that it’s captured, having the methodology in place -- spend that extra money upfront and have the savings every time the process is carried out and reused.

Gardner: Anyone else out there have some questions for Richard?

Kobielus: There’s definitely a value for an advocacy organization like this to spread best practices regarding SOA and SOA deployment and management. You mentioned that one of the functions of these – for lack of better term, dog and pony shows -- meetings in various cities is for the CIOs to share both the success stories and the failure stories regarding SOA deployment. How eager are CIOs to share their failures and their screw ups in implementing SOA?

Soley: You saw how carefully I didn’t mention even the gender of the CIO who made that comment in New York. I will admit there was one time we had to turn off the tape recorder, which we were using just to have notes so we can get the quotes right later on. They are willing to share. We find this at the level of CIOs and CTOs, as well as at the level of enterprise architects. They are willing to share failure studies, if they have the safety and security of knowing they are not going to be quoted, it’s not going to be on their performance reviews, and they know that others in the room are going to do the same.

Listening to one of these stories, actually it was in San Francisco, gave me an instant flash to my kids high school in Lexington, Mass. It blew me away the first time I saw this. There's an enormous board in one of the major cafeterias. It’s labeled "The Board of Rejection," and all the kids post their rejection letters up there, and I thought, "My God. I never could have done that 30 years ago, when I was graduating high school."

But kids write notes on them and say, "They don’t know what they missed," and "You’ll get accepted somewhere else." And, they really help each other out. I think they all understand that failure stories are just as important as success stories. In fact, more important, because it’s very difficult to justify cost savings. It’s far easier to justify increased revenue. So, they do it and I will admit that the enterprise architect level folks do it more readily.

Kobielus: Which leads me to another question, I am looking at the initial membership of the SOA Consortium and I don’t see any consultants or a professional services firms.

Soley: Yes, systems integrators (SIs).

Kobielus: Those are the folks who see the broadest range of SOA implementations, successes and failures and they themselves quite often are a key component of those successes and failures. Why don’t you have the SIs involved in the consortium?

Soley: That’s a great question. In the three weeks since we’ve been live; you are only the second person to think of that. So, well done. In fact, amazingly, the entire idea for these summits was from one of the big four, a very active person who has been participating in all of the meetings. Unfortunately, their entire management restructured the day the membership agreement was supposed to be signed. So, we are talking to all of them obviously, and, in fact, unsurprisingly, IBM is participating from two different parts of the house, and one of them being, whatever IBM Global Services is called -- today is Friday, so it must have a new name.

I expect to be able to make an announcement about another major one in the next couple of weeks. We are talking to all of them. Come along to a meeting. Maybe you will see the one that I am talking about, but I really shouldn’t mention them until they can get their own processes back in order and get involved. It was really depressing to have this gentleman come to all the meetings, actually lay out the entire structure, idea, and plan for the CIO Summits and then not be able to participate in them.

Kobielus: I'll bet it was frustrating.

Soley: It was very extremely frustrating for me and I think intensely frustrating for him.

Gardner: Seeing these individuals participating in the sharing back and forth of stories, methodologies, and lessons learned, sounds a little bit conceptually like an open-source project. I didn’t see in the initial release any mention of some of these SOA open-source projects involved, whether it’s SOA Tools Project within Eclipse, or Tuscany within Apache, or some of the success in the field, such as ServiceMix. Is there a role for open-source projects within this consortium?

Soley: I'm going to go out on a limb here. Didn’t I say SOA is not a technology? When I hear "SOA tool," or "SOA development tool," or "SOA testing tool," I have to wrap my mind around that, because SOA is not a technology. It’s a business strategy.

So, I think what you really mean is "tools for implementing processes that are defined using the SOA approach." These are tools for testing implementations of processes that are defined using a SOA approach. If what we're talking about is business strategy, then software is an implementation technology. It’s not the strategy, right?

Gardner: Well, they still have a relationship?

Soley: Yes. So, let’s look at any of those. Commercial products, by the way, are no different. They implement processes that are defined by a methodology that’s part of your SOA strategy, or maybe they help you implement the methodology itself. There are tools to do that as well, and some of those are going to be open source and some are going to be commercial. There is definitely room for participation, and these vendors that have put money into the creation of the SOA Consortium obviously want to sell products and services. The good news, however, from the point of view of the end-users is that the purpose of the organization is not to help them decide what product to buy.

I will tell you, sitting around the table, enterprise architects share experiences of which products have worked for them and which haven’t, and I have seen marketing reps from our vendor participants scribbling down notes, because they want to sell more product -- and more power to them. I'm a capitalist. But whether it’s open source or commercial, software is an enabler, software is an implementation technology, but it’s not a business strategy.

Garone: I wanted to follow up on Dana’s question, because I was thinking in the background as you were talking about what the Consortium is actually doing and who is participating. Given its charter, what's in it for the vendors and how they are participating, if, in fact, this is not about generating standards that all the vendors can leverage, and it’s not about selling product, which of course it shouldn’t be and it isn’t?

I am sure that they get value out of being there, out of being in front of CIO’s and other end-users, out of taking notes, as you said, learning where their products are selling and where they aren’t. But I'm interested in the mechanics of how they participate, what they bring to the table, and how they interact with the CIOs in a way that brings them benefit?

Soley: First of all, I should mention that at the summits none of the vendors were allowed. In fact, none of the members were allowed. They were run as focus groups, because we wanted the CIO-level executives to be able to talk completely openly about their case studies, their success stories and failure studies as well. And, we wanted their honest feedback on the organization. So, no one else was in the room, except for the executives that were able to come and two OMG staffers, including me and Brenda Michelson from Elemental Links, who is the consultant who put together the vision-mission strategy goals and tactics document. She then presented that to these executives and then ran focus groups to get results and is now finalizing those documents, which we call the core documents about the organization.

The vendors have been in the room at all the other meetings, of course, and they have their own SOA strategies to implement and their own business processes that interest them, but there’s money coming from marketing departments and they want to get out in front of these users and say, "Look. We are leaders in this field, we understand how to implement an SOA, we have tools to help you with the implementation of your architecture, and we have run-time executables to manage the implementation."

Those go from anything such business-process description languages as BPMN to capture business processes, SOA governance product for keeping track of what processes you have, and making sure they follow the corporate rules and implementation of technologies.

It's no surprise that IBM mentions WebSphere, and that BEA mentions WebLogic and AquaLogic, and so forth. The group from Cisco, for example, the AON group, is all about capturing SOA and implementing it on your network. The group from SAP is changing completely the way that they implement their own products and integrate them with the other products they find in their customers, to be able to say to their customer base, "Look, we are leaders in SOA and one of the proof points is that we took sponsorship positions in the consortium."

Gardner: You know, Richard, one of the problems that we have encountered in the field around SOA is that it’s hard to measure success. There are long-term and soft-types of implications, and I suppose that the same could be said for something like this consortium. How do you measure the success of what you’re doing and have you put any milestones out there for what you'd like to attain?

Soley: That's an extremely good point, and actually one that came up at every single one of the executive summit events. We worked on that for a long time and came up with the loosey-goosey measure of self‑identification.

So, the overall goal, which you see on our Website, is 75 percent of the global 1,000 self identify SOA successes by 2010. There is an asterisk that mentions that we are also talking 50 percent of medium‑sized businesses and 50 percent of major government agencies. Because we couldn’t pull some measure of success off the shelf, we went with self identification, and at every single one of the summits we were told, "No, you are going to have to try harder. You’re going to have to deliver some metrics of success."

I don’t have any for you today, but I can tell you that that is something that we got very clear direction on from the CIOs and CTOs who participated in the summits. Also, they wanted us to look specifically, for example, at connections between SOA and Lean, Six Sigma, and ITIL best practices, all of which have metrics of maturity and success.

Gardner: Any other questions?

Kobielus: I think the industry is looking at the SOA Consortium or OMG to be a third-party certifier -- maybe that’s overstating your mission -- of enterprises' success or lack thereof in implementing SOA. So, it’s the extent to which you are going to be mapping these SOA best practices back to such recognized frameworks as ITIL, Six Sigma, and so forth that would be essentially what the industry is looking for you guys to do -- to catalyze that kind of mapping.

Soley: Yes, that’s a very good point, and, Dana, I thought you said that I wasn’t going to be get any hard questions.

Gardner: Sorry.

Soley: The SOA Consortium is looking to not only OMG, but other standards consortia, to deliver standards, mappings, and validation endorsement certifications where appropriate. In fact, it’s in the mission statement that the SOA Consortium is not a standards organization, but it will deliver requirements to standards organizations and where we were talking about modeling things, those requirements would be handed to OMG.

One of the 10 largest banks in the world sent an executive to one of our meetings, and this person said, that all they care about in terms of metrics of success are Lean and Six Sigma, so we're going to need to connect SOA to that world in order to be successful at that bank. I think that’s part of it, but there’s more than that. There are going to be metrics that are not yet in the stack when you fly through the ITIL, Six Sigma and Lean documents.

OMG, as it happens is moving into the direction of maturity models anyway. We are just starting work on a business-process maturity model. You may have read about it. It’s not a standard yet, but it was just starting. What were talking about is a maturity model for business process adoption that measures organizations and their ability to capture business processes. That’s very strongly related to SOA, but again, that’s a standard and belongs in OMG and not in the SOA Consortium.

Kobielus: One last question. Are you developing a maturity model for master data management (MDM)?

Soley: First of all, the SOA Consortium wouldn’t be delivering any maturity models at all. OMG has never delivered maturity models before, although we’ve expanded many times over our history, which is frankly why I am still there. This is a new area for us. We have to learn not only how to deliver the standard that specifies business process maturity, but how to deliver that, which means how to certify people, so that they can certify organizations at the five different maturity model levels that we are contemplating. So, no, we have never delivered any other maturity models and although there are lots on the books as potentials, let’s wait for 2008 to see what develops.

McKendrick: You talk about the SOA Consortium, and there’s a lot of discussion about business process management (BPM) and SOA. Obviously, these two areas need to converge as we go forward. As I have heard and seen, though, over the years, especially in recent years, that the BPM professionals and the IT or the SOA professionals tend to be in two different camps and kind of follow their own separate sets of disciplines. It would seem a challenge from the perspective of the SOA Consortium in bringing these two camps together. Do you see that as a challenge?

Soley: You bet, but that’s one of the results that we learned during the events. We are very worried about that. Obviously, I strongly believe that BPM -- and now I am not talking about technology, just managing business processes -- is a key part of the SOA business agility message. I also believe that BPM technology, like our own BPMN standard, implemented by 40 some vendors, is a great way to capture business processes. But, we have been worried since day one that you’ve got your business process owners, your Six Sigma experts, and business process offices in companies, and they seem to be different from the IT definition of BPM.

One of the things that we heard in every event from all the participants is that the CIO and CTO participants did not artificially separate SOA and BPM by the underlying technology. They see business processes and services tied to a cohesive enterprise architecture foundation as a major message of SOA. That message has been received at the high level, and what we have to do is help the C-suite, get the message down into the lines of business and down into the IT organization, that a business process viewed as a methodology by business process improvement office and business process viewed as a business process notation in the IT departments are the same thing, and they ought to be working together more closely.

Gardner: Great. Well, thank you, Richard. Obviously, there are so many constituencies involved inside of organizations, and then also involving their communities, and there are vendors that are herding the cats, as it were, toward SOA as a worthwhile, important, and difficult activity.

Soley: Yeah, no problem, though. These are cool cats.

Gardner: I wish you well. Moving on to our second subject, I just came back from EclipseCon in Santa Clara, Calif. [in March] and there were few announcements there I would like to go over quickly. Tony, you wrote about the Oracle move with its Java Persistence API. Tell us very quickly about that.

Baer: Well, it’s been an interesting strategy, because the fact is that Eclipse was initially known for IDEs, and Oracle with JDeveloper is one of the few major Java players, outside of Sun, who is not migrating its IDE to Eclipse.

In the past year or so, Oracle has been involved in a number of Eclipse projects. I think putting its feet in the water. What’s interesting is that they are now ramping up to board level by saying, "No, we are not going to IDE. We are going to instead work on Java persistence and essentially they are trying to coalesce it around top tier, which is their implementation of the Java Persistence API.

It’s actually the update of what is essentially about a 10-year-old product, and what the interesting thing is not so much what Oracle is doing, but it’s more reflection of Eclipse saying, "We’re more than about IDEs."

Gardner: This is runtime material, right?

Baer: Exactly, and that begs the question that I have asked the Eclipse folks as well. If you’re not just IDEs, which is what we’ve associated you with, what are you? What is your mission, and where do you draw the bounds on it? Their answer to that was, "Well, we didn’t initially form ourselves to develop an IDE. It was the idea of trying to be a proof of concept to show that you can have an extensible framework to this plug-in model."

Gardner: Around OSGi?

Baer: Well, OSGi came later. They initially tried their own plug-in model and realized, "Why are we re-inventing wheel?" OSGi just happens to work. The whole rest of the field just discovered OSGi, kind of by chance, in the same way that all the AJAX folks discovered you can use Java Script, XML and a whole bunch of other stuff together and get rich clients on the Web.

That was not the original intent of OSGi. It was supposed to be basically a home box, which would essentially Java-enable your toaster or refrigerator, and we can see how far that’s gone. But, what we have found is that it’s actually a very effective, hot-swappable component model. So, that’s what Eclipse has really capitalized on, and they are seeing that as being some of their proofs of concept to say, "Now, let’s see how far we can take this."

Gardner: I had two take-a-ways, one was that this seems like mission creep for Eclipse, that they are getting more into runtime, and not just on the client with their rich-client platform, but now, increasingly on the server. The second thing was this. Oracle, as a major vendor is going to be driving a lot of the innovation around this project. The proposed project under Eclipse has moved the project in the sense out of GlassFish and around the Java community, and they will keep it as a Java reference implementation. But the innovation will be happening at Eclipse. And then any of the changes will only then move downstream into Java.

So, my take-a-way was: one, mission creep for Eclipse into runtime, but secondarily some diminishment of the role of the Java environment for innovation. Anybody have reaction to that?

Kobielus: Actually before everybody else jumps in, I just want to top that. You have mission-creep for Eclipse, and it sounds like you could also say "mission accomplished" for IBM, because I think one of the original goals in getting Eclipse going was to essentially move the center of gravity in the Java world away from Sun.

Gardner: That seems to be happening, doesn’t it? Richard, what do you think of that?

Soley: This goes back to the conversation we were informally having at the beginning of the call, about mission creep and expansion of Eclipse goals, and where the organization goes. I think there’s sufficient demand in all of these areas, that some organization has got to get their arms around it and deliver. As long as that delivery happens, I think it’s the right thing for the user base.

Gardner: I'm not sure I understand.

Soley: Whether it’s commercial or open source -- and you hear me say "whether it’s commercial or open source" a lot -- you need product that delivers against a user requirement. My response in this was something I was saying earlier to Tony’s note this morning about results of EclipseCon is that expansion of mission is perfectly fine as long as you continue to deliver on each of the elements of that mission.

Gardner: Well, one thing I can tell you as an observation is that this is a very energetic environment. A lot of developers that had the feel of what Java 1.0 was about seven or eight years ago, and many, many vendors that I speak to, recognize that the Eclipse community is a force to go with and not to ignore. Many of them are creating plug-ins -- be they commercial or open source -- in order to ride the marketing machine that the Eclipse involvement has become. So, this is something that’s got a lot of momentum, and at a time, as I think Tony pointed, out that Java is losing momentum?

Soley: You can’t have both of those at the same time, right? A big message of Eclipse is the Java message. Eclipse supports other programming languages as well, but the success of Eclipse is the continued success of Java. So, let’s be fair.

Kobielus: One thing we have to distinguish is Java versus the Java community process. I think that’s really what they’ve meant.

Soley: Okay, fair enough.

Gardner: Where did the innovation take place? Is that kind of the point?

Soley: The open-source model has proven to be a very successful one in the Java community.

Gardner: Well thank you everyone for joining, we’ve had an interesting discussion, and again I want to wish the SOA Consortium well, and OMG as a participant in that. I guess you’re taking a leadership role in this Consortium. Is that fair?

Soley: I am the executive director of the consortium, yes.

Gardner: Well, thanks everyone. We’ve been talking again about SOA, your SOA Insights Edition, Volume 14; our guest has been Dr. Richard Soley, chairman and CEO of OMG. Thanks for coming, Richard.

Soley: No, thank you for arranging. It was a pleasure, Dana.

Gardner: Also joining have been Steve Garone, Joe McKendrick, Tony Baer, Jim Kobielus -- thanks everyone for joining. I am your host and moderator, Dana Gardner. Thanks for listening.

Listen to the podcast here. If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.

Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 14. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.