Edited transcript of BriefingsDirect[TM/SM] podcast with Dana Gardner, recorded April 17, 2007.
Listen to the podcast here. Sponsor: UPS.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, a sponsored podcast discussion about visibility into supply chains and distribution networks. It’s about effective information-sharing across the spectrum of transportation options and during the distribution of goods.
"Do you know where your stuff is?" is the big question and, most importantly, "Do your customers know where their stuff is?"
Helping us to sort through this important area for ecommerce and for small- and medium-sized businesses (SMBs) and their retail operations, we have an expert in the area of supply chain management. We are joined today by Jim Rice, director of the Integrated Supply Chain Management Program at MIT. Thanks for joining us, Jim.
Jim Rice: My pleasure.
Gardner: We also have Stephanie Callaway, director of customer technology marketing at UPS in Atlanta. Hello, Stephanie.
Stephanie Callaway: Hello, Dana.
Gardner: We also have users and practitioners of this emerging art. Frank Deen is the shipping manager at Rackmount Solutions in Garland, Texas. Hello, Frank.
Frank Deen: Hello, Dana.
Gardner: And lastly, joining us from Saline, Michigan is John Schaffer, president of TrueWave, the distributor and creator of the Wadia line of high-end audio products. Thanks for joining us, John.
John Schaffer: Glad to be here, Dana.
Gardner: As I mentioned, this visibility issue is a part of the information revolution and the knowledge economy, whereby at some point either folks who are end-users buying goods or folks in the distribution channel are looking for reductions in cost, efficiency improvements, and reduced time to distribution -- all of which can substantially reduce the total cost of an overall production and distribution activity.
I want to go first to Jim Rice. Jim, help us understand the state of the art here today. What are we talking about in terms of business drivers and technology drivers in this search for higher efficiency and distribution?
Rice: Thanks, Dana. Let me start by talking about the business drivers. If we were to ask companies and leaders what their concern was, they would be talking about a number of things. They'd be talking about continuity -- business continuity. We saw that destructions like Hurricane Katrina and 9/11 caused a lot of companies to start recognizing that their supply chains are genuinely at risk.
A lot of vulnerabilities were always there, but weren’t very apparent or evident. So, there's a fair amount of recognition about this vulnerability. Right now, there is some work going on in that some companies are planning to make their supply chains more resilient and trying to actively manage risks.
Similarly, companies are aware of security as an issue, although many are talking about it, but aren't taking much action. In part, that's because it’s very difficult to show a return on investment from security investments. The trick question is, "What happens when supply chain security investment is successful?" Of course, the answer is "nothing," because it prevents something from happening.
The companies are concerned with optimal supply chain design, and this takes in the aspect of outsourcing. How much outsourcing do we use? How much of that do we even think of putting offshore, trying to reduce cycle time, cost, and uncertainty in the system? That will ultimately enable them to be much more responsive to spikes and drops in demand.
Companies continue to squeeze their supply chain to lean it out, and make it more efficient and more effective. There are a lot of drivers in the industry right now that affect the price of sundry industries differently.
Gardner: We want to have this clarity in the best of times and also in the worst of times. Is this essentially a data integration and availability exercise? What are the core issues to enable folks to get the information they need about supply-chain activities?
Rice: It’s not just about data, but certainly data is a central and a critical issue.
A lot of it comes down to having relationships with customers and suppliers. They would be open and free to share the information that ultimately will help both organizations to make better decisions, reduce uncertainty in the system, and take out some of the cost and uncertainty. That makes the system potentially much more efficient.
Gardner: I suppose this has to do with levels of trust. There are interdependencies -- "You help me, and I help you" -- in terms of making the customer at the end of the process happy. How has that gone? Has there been trust? Have people recognized a quid pro quo and have they been willing to share?
Rice: Yes. I go back to that quote by Ronald Reagan: “Trust, but verify.” There’s certainly some inherent trust that exists between individual parties, and there maybe some trust that exists over the long term between organizations, but ultimately the trust is backed up by systems or processes that enable regular engagement coordination. They are backed up by contractual agreements, or at least agreements in principle, whereby one party is going to make the other party whole in the event of some disruption or some eventuality that they hadn’t planned for.
Gardner: Before we go to UPS to learn about some of the things they are doing, what should we expect in the future? Is this a mature and fully baked technology and business approach, or are there more efficiency, visibility, and innovation to come?
Rice: I think we are just on the cusp of lots of great potential. I can’t tell you whether the potential will be realized tomorrow, next year, or in five years, but I think we are getting really close. Probably as far back as 10 or 15 years ago, you had some pundits who were saying, "Oh, in the future our systems will be fully integrated and completely synchronized." It hasn’t happened yet to a large extent. There are isolated instances. Some individual companies have demonstrated the capability of being synchronized, organized, and coordinated.
Some of these capabilities are becoming more readily available for large companies, and hopefully in the near term, to small- and medium-sized enterprises. The challenges aren't simple, but I think there are some tools and processes emerging that are going to make this much more possible in the future, and therefore get us a little closer to that Nirvana of the synchronized supply chain.
Gardner: Thanks. Let’s go to Stephanie Callaway at UPS. Stephanie, you’ve heard about the need and desire for looking for data and visibility in the best of times and the worst of times. UPS sits in a very advantageous position between all these players. Tell us a little bit about what’s been going on for the last several years to try to improve on this activity?
Callaway: Okay, Dana, thanks for having me. UPS started with tracking on the Web in the early '90s and since then we have evolved our portfolio to include a broad set of visibility solutions that address the very diverse needs of our customers.
Today, we support tracking in 63 countries, and that serves the basic visibility needs of our shippers, receivers, importers, and exporters -- both residential and commercial. Our emphasis today is on more than our traditional U.S. small package business. That's available outside of the U.S., but we also provide visibility through tracking to our UPS Freight, Air, and Ocean Freight Services.
Gardner: Jim mentioned about this trust issue for verification? Have you been playing a larger role in trying to broker these relationships or get people to shake hands and agree on visibility?
Callaway: From the perspective of our relationship with our customers, we provide full visibility of shipment status from the time they tender their package to us to the time it is delivered to their customer. We have other visibility solutions, such as Quantum View, that provide proactive information, even when the package encounters trouble along the way. Whether it’s a weather delay or an incorrect address, we can provide that information proactively to our customers, so that they can provide that information to their customers and improve customer satisfaction.
Gardner: So, you are the picks and shovels, and your customers are out there mining these relationships. Tell us a little bit about small- to medium-sized businesses in particular. Is this a high-growth area for your goods and services? Where in the whole business spectrum are these things being used the most? Then, secondarily, where do you think the larger uptake is in the future?
Callaway: Customers of all sizes take advantage of our visibility portfolio. I mentioned tracking on the Web. Even with tracking, some of our customers prefer to integrate that information into their own Web sites. We have XML tools that customers of any size who have an IT organization can take advantage of to integrate information about package status into their Web sites.
We also have this suite of Quantum View solutions that can be used by customers of all sizes. Typically, smaller customers who don’t have large information technology (IT) functions or large IT budgets would take advantage of our ready-to-go solutions, like Quantum View Notify, which is an email notification. Customers can select that at the time of shipping, and proactively notify their own customers about important shipping events, such as exceptions and deliveries. That helps them save time and increase customer satisfaction by reducing the number of calls that they receive.
We also have Quantum View Manage, which is a visibility dashboard that customers of all sizes can use to see where their packages are in transit. That would be any packages they are shipping out, any that are coming into them, or any that they’ve paid for, along with some special capabilities to help importers with compliance.
Gardner: Without going too far into the weeds on application development and integration, Web services and APIs, and that sort of thing, it sounds like you’ve got a spectrum of approaches for those who aren't interested in getting into too much of the technology, perhaps using the email alerts approach. I imagine you also will allow for those who do have application developers at their disposal to bring in the visibility benefits, and mash-up your tracking, information, and data services right into their portals for self-help and for customers to track what’s going on with their retail purchases. Is that right?
Callaway: Exactly. As I was saying earlier, we believe we have to address a broad set of diverse customer needs. I mentioned the online tools for tracking, but we also have Quantum View Data, which lets data about package status information flow proactively from UPS to customers. They can integrate that however they see fit into their own internal applications, whether it’s for their own use within their customer-service department, or whether they want to proactively share that with their customers.
Gardner: I suppose as a customer or a partner, you’re elevating yourselves to an information-sharing value, not just the logistical and transportation value?
Callaway: That’s true, and our customers expect that of us.
Gardner: Okay, let’s talk to some customers. Let’s go to Frank Deen at Rackmount Solutions. First, Frank, tell us a little bit about Rackmount, the history of the company and what you do.
Deen: Dana, we started out about five years ago as strictly an Internet company. We sell racks for IT solutions, file servers, and different types of peripheral equipment that goes into IT rooms. We ship those all around the country. Our business has grown to the point where we have a warehouse here and stock quite a number of the items ourselves, but because of the magnitude of the type of things we sell, we ship from probably a dozen locations around the country, depending upon what the item is.
If the quantity someone is purchasing makes it impossible for us to ship it from here, we have to have it drop shipped. That, in itself, has been a challenge, because our shipments are going from so many different locations. We are usually selling to people who come in over the Internet or call us direct, so everything we have does get shipped out. Being able to track and know where our packages are is very, very important to us.
Gardner: So, you have been managing fast growth. People have been building out data centers and modernizing their infrastructure for their IT departments. You’ve also been dealing with complexity in terms of the number of points that you are distributing from and the number of points that you are trying to get your things to. Specifically, what sorts of visibility services have you been using to manage this high growth and complexity?
Deen: Initially, when we started doing this, because we were shipping from so many locations, even though it was being shipped on our account, we would have to contact each one of those shipping points, each warehouse, each manufacturer to get tracking numbers to send to our customers. Of course, now we are able to have that information sent directly to the customer when the product ships. They get an email with that information.
Plus, on Quantum View, we are able to pull up a report every day that shows everything that has been shipped out on our account, whether from our local warehouse or any of those other locations. We're able to have that tracking number and see the exact progress of that package -- when it was picked up, where it’s at currently, when it’s expected to be delivered, and the address that it’s expected to be delivered to. When a customer calls and asks a question about it, we are able to go to that and immediately give them an answer that provides a comfort level that we are keeping track of their merchandise that they are waiting to get.
Gardner: So, using some of the UPS services, you're giving your call-center folks visibility. When they've got hopping-mad customers saying, "Where are my goods? I've got to build out this data center. I need these racks," you’ve given visibility to your call center, but do you take it to the next step? Do you have a Web site where these people can track their own goods? How does that work, when you face too much cost and too much traffic into your call center?
Deen: That really hasn’t been a problem for us. The fact that they have the information themselves, the tracking numbers, all customers can go in and do the tracking and look at it themselves. That has reduced the amount of calls that come into us, because people are able to see that.
The other issue is that with Quantum View, we are able to find out quite often if there is a problem with the outgoing package, and whether it’s been delayed for some reason. We get that information before the customer calls and complains about it. The call center will be proactive in dealing with the customer, and letting him know that we are out there serving his needs. That’s very big, because sometimes in the past, we didn’t know if there was a problem until the customer called, asking "Hey, where’s my package? It should have been here already." Being proactive helps us provide better customer service.
My feeling is that there is a lot of competition out there for what we do. There's a lot of competition for every business out there. Customer service makes the difference whether that customer is going to come back to see you or not, because there’s only so much difference in price that businesses can generally give. When we can do these things to show customer that we care about when they get their product and that we are going to be right there with them all the way through, until they’ve got it and it’s being used by them, that makes them want to come back to us.
Gardner: I want to check in with Jim Rice. Is there anything you heard from Frank Deen that illustrates some of the trends that we talked about, or perhaps some of them we didn’t? It seems that customer service and the trust element is pretty prominent.
Rice: I was biting my tongue here, because I wanted to ask Frank a bunch of questions. I think the example illustrates, in great part, dealing with uncertainty. Because Frank now has pretty good understanding where his materials are, he’s able to make commitments to his customers that will then allow them to be more sure of when they can expect to get their materials. That means they can take out a lot of uncertainty in their planning process.
The question I have -- and maybe it’s for another time -- but when someone has less uncertainty in their supply chain, does it make it possible then to take inventory out of the system, because inventory is basically there as a buffer to deal with uncertainties?
Maybe Frank has chosen to keep his inventory levels the same and ensure higher customer-service levels, or possibly he has reduced inventory based on the ability to have a much higher level of certainty. I think it’s a really good example, and I think it illustrates something that I didn’t mention -- the importance of maintaining high service for your customers to maintain those customers.
Gardner: How about it Frank? Have you been able to whittle down your inventory as a result, and is there some cost savings there for you?
Deen: Jim’s right in the fact that we have a comfort level, so when we need a product for a customer, we can have it directly drop-shipped to that customer and know that it’s going to get there. That means we don’t have to keep a large amount of each kind of item. We keep enough for when someone calls and wants one, two, or three of something, but when they need 20 of it we don’t have to be worried, because we know that we can go right to our supplier and have that drop-shipped and serve that customer’s need. We know it’s going to happen.
Gardner: I have a sneaking suspicion that customer satisfaction is important to John Schaffer, as well. John, tell us about TrueWave and the Wadia products. Then let’s get into how this ability to satisfy customers throughout the transportation phase of a purchase works.
Schaffer: Sure, Dana, you hit the nail on the head there. Customer service is everything to us, as well. One of the great things about the tools that UPS has provided for companies like ours is the ability to offer a higher level of customer service through the visibility that Frank was discussing.
TrueWave manufactures a product under the Wadia brand, basically high-end consumer electronics, and specifically what most people would think of as CD players and high-end stereo equipment. We have the enviable position of a brand that is very well received throughout the world. Our challenge with shipping and satisfying our customers has to do with not just the United States, but satisfying countries overseas, working with distributors throughout Asia and Europe, and North America as well.
Our challenges are a little bit different. What UPS has been able to provide for us has really given us advantages. Previously, we would work with freight forwarders quite often. They are pretty good at handling the customs side of things, but the visibility was very poor, and we would have significant delays in getting packages from point A to point B. What we have enjoyed in our relationship with UPS is the ability to have the packages transported across borders seamlessly, and have visibility throughout the process.
Gardner: So, you’ve been able to enter and then satisfy markets that you probably wouldn’t have been able to get to?
Schaffer: No, we could get to the markets, but we couldn’t do in a way that allowed our customers to have visibility into the process. There’s a lot of uncertainty when you are shipping internationally. When you have visibility into the process from point A to point B, it really changes the dynamic quite a bit. One of the tools that Stephanie was discussing, Quantum View Manage, allows us to see if there are problems along the way. Then we can communicate with our customers in such a way that we can set the proper expectations.
Communication is the secret to customer success, and visibility into all aspects of the supply chain has really changed the way that we’ve operated our business. I think for the better. Our customers are very satisfied with how we are able to offer them now a clear expectation of what they’ll get and when they’ll get it, thanks, in large part, to the tools that UPS has been able to develop and offer to us. As a small company, that’s really valuable.
Gardner: I suppose the whole notion of customer satisfaction also involves exception management, or even returns, if someone decides that it wasn’t exactly the right fit for them. Does this visibility and these tools help you in terms of managing, "I’d like another one right away," or "This one didn’t work out for me." This is working in reverse -- getting stuff from the customer back to you.
Schaffer: Oh, yeah. It does help us when packages have to come in for service, an upgrade, an exchange, or for whatever reason. It allows us to again control the situation and set the proper expectations for our customers.
It’s very helpful for us in planning for things. For example, if we have a product coming in for an update, now we can track the product back to us, have an understanding of when that will hit our dock, prepare the service department, make sure that our inventory of the parts that are needed to updated are available, and just really control the whole process in a better way. It’s really created a great benefit.
Similarly, with incoming components for manufacturing, sometimes we’ll have a supplier send products to us cash-on-delivery (COD). If we have visibility into the shipping process, we can have finance prepare the payment in advance, so that we are efficient in how we manage the process at the dock. That’s been really valuable.
The new Quantum View tools -- Quantum View Notify -- has allowed our customers to have a good understanding of when their product has shipped and how it's proceeding to their destination. Then, the Quantum View Manage has helped us quite bit with giving us visibility into both outgoing and incoming parts and products. It has really benefited us, and we are happy that, to have been able to partner with UPS and take advantage of such powerful tools.
Gardner: Let’s bounce that again off of Jim Rice, the expert. It sounds like when you’re receiving goods and you can plan for payments and schedules and manage your own manufacturing processes, that's another opportunity to reduce risk, improve efficiency, and cut your total cost.
Rice: What we just heard from John is another example of how getting additional visibility into the system gives the company a lot of power. It gives them the power to decide whether to increase the amount of service they are going to provide. They can provide products and materials on a shorter cycle time and possibly take cost out of the system, because there is much less uncertainty. In the pervious example, when Frank Deen was talking about being able to ship direct with the knowledge of where the materials were, this just allows the company to say, "All right, here’s where we need to put our capital."
Now, the confidence that they have, knowing that they are going to have this information that tells them where their products are, is very powerful for the company. It gives the companies lot of tools and lot of power to say, "Here is how we are going to chart our own destiny, and we are going to squeeze some efficiencies out of that. We are going to reduce the uncertainty and the cycle time." This is good news.
As I suggested in the beginning, companies are trying to reduce the uncertainty. They are looking for ways to take cost out of the system, and these are pretty good examples of that. I want to underscore that this is not easy. It’s hard work, and it takes working very closely with customer and supplier and really leveraging whatever systems and processes you have, so that you have a robust solution. It sounds like they’ve been able to create that.
Gardner: Even relatively smaller companies without a whole lot of resources?
Rice: That’s the beauty of some of the technologies. It doesn’t necessarily require a huge fixed-cost. That’s where this big advantage is now, as we see in many companies, outsourcing some of the capabilities, because of the firms who are providing outsourcing services. In this particular case, UPS has made huge investments to develop these very competent and capable systems that, for a piece price, individuals and small- and medium-sized enterprises can take advantage of.
Gardner: Let’s go back to Stephanie Callaway. Stephanie, how do companies get started with this? We heard that it requires a lot of work. How do companies get started to enjoy some of these benefits?
Callaway: On www.ups.com, if anyone is interested in more information on Quantum View, they can search for Quantum View. There's an online demo that describes the various Quantum View products and their benefits to help customers recognize their own business process pain points and identify the solution that will work best for them.
We also have a sales force, so customers who have an account executive can speak with their account executive about their specific business process pain points to be registered for something like Quantum View Manage or Quantum View Data. The things that are more sophisticated, such as the online tools that I mentioned for tracking, are available on our Website, and customers just need to login and register to access those tools.
Gardner: Jim mentioned earlier that we are perhaps just scratching the surface on what’s going to be possible. I’d like to throw this out to the entire group. If you have a wish list, if you like to see some things down the pike a little bit, what would they be? Where can we go next with this? How about one of our users John Schaffer or Frank Deen? What’s on your wish list for the next stage?
Schaffer: I think UPS has done a good job of anticipating the needs. In some cases, they have changed the way that we’ve thought about supply chain visibility and have really done a great job of leading the way there. One of the things that I think would be interesting -- and I know UPS has begun to explore this -- is in fostering relationships.
This goes back to the trust issue, but in fostering better business relationships with offshore manufacturers and suppliers, there’s a financial component that goes along with that, and UPS has set up some programs to address that. But, I think there are some additional programs that could be built to allow the issues that arise from language barriers, etc. to be broken down more. They could have financial control of the situation to go along with the control of the shipping, the movement of parts. I think that’s something that UPS has begun to explore but it’s something that we would like to see more of.
Gardner: How do you react to that Jim? Is that along your lines of what the next stages will be?
Rice: I think that the next stages are going to have lots of different pathways. What we’ve just heard from John is one example. We just don’t know what’s going to be coming, and this is one of the exciting things. We try to predict and expect these things, and we always get surprised. I think it’s through innovation in small- and medium-sized enterprise, because these are organizations that are not rich with resources, but they are very deep in innovative approaches to solutions. This is one good example, and there probably would be plenty of others.
Gardner: Are there any gee-whiz technologies still to come? We’ve heard about GPS and RFID chips. Are we going to take this a step further in terms of what the technology can provide?
Rice: I think that the gee-whiz technology that is often talked about -- and you just made a brief reference to it, Dana -- is RFID technology. In many ways, this has been oversold. It has great power in a limited number of instances and environments. Potentially, this has lots of broader application, but there is an awful lot of standardization development that needs to be done in order to make this more broadly and widely acceptable and usable.
The future is really bright, but it’s a little way off for that. The synchronized supply chain is going to come as a result of organizations working closely together using technologies like radio frequency or cobbling together a variety of different technologies. Whether it’s GPS or more sensors for security applications and containers, to software packages that allow deep analysis of rich data from RFID tags, it’s going to require a lot of hard work to pull these things together, but the potential I think is significant.
So, that’s why a lot of people continue to make investments in those areas. But I do think it’s a ways off, before the capability of those technologies to work network-wide comes to fruition.
Gardner: So, perhaps the future will have more data and more data points for us, and the ability to analyze it, but it’s the relationships and the efficiency and innovation of companies in the field that is where the biggest payoff is, at least the short term.
Rice: There’s going to be a tsunami of data that’s going to be available, and the challenge is going to be how we actually analyze all this and then do something with it. Even if you can’t do something with that data, current systems are not fully capable of responding in ways that you otherwise would like them to respond. But, by using technologies like the visibility systems we’ve been talking about today, as well as designing systems to be more resilient, it will increase the ability of supply chains and company supply chains to be more responsive. Then, when the tsunami of data does come and tells us, "Hey, here’s a forecast. We know it’s going to happen tomorrow," it will allow the company’s system to actually respond in time for tomorrow.
I remember talking with a manufacturer not long ago who sells to Wal-Mart. Their folks said, "Well, we get an 80 percent accurate forecast 10 days out from a shipping due date, but we can’t do anything with that because we need six weeks in advance to be able to respond to that." So, that's going to require some responsive systems in order to be able to utilize all that data.
Gardner: Well, great. I want to thank our panel. This has been an interesting discussion. I’ve certainly learned more about what’s possible and what’s going to be probable.
We have been talking with Jim Rice, director of the Integrated Supply Chain Management Program at MIT. Thanks Jim.
Also Stephanie Callaway, director of customer technology marketing at UPS. And Frank Deen, shipping manager of Rackmount Solutions, as well as John Schaffer, president of TrueWave/Wadia. Thanks again.
This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect podcast.
Listen to the podcast here. Sponsor: UPS.
Transcript of Dana Gardner’s BriefingsDirect podcast on UPS's solutions for supply chain visibility. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Monday, May 21, 2007
Sunday, May 20, 2007
Transcript of BriefingsDirect Podcast on IBM's Upcoming Jazz Collaborative Development Framework
Edited transcript of BriefingsDirect[TM/SM] podcast with host Dana Gardner, recorded April 24, 2007.
Listen to the podcast here.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, a podcast discussion about application lifecycle management (ALM), collaboration, and the productivity of developers in teams. We are going to be discussing an upcoming product announcement -- perhaps maybe we should call it a community announcement -- by the IBM Rational Software division.
They are going to be announcing in June at their Rational Developer Conference in Orlando, Fla., a technology set called "Jazz." And here to tell us more about it and describe the benefits and issues around new collaborative approaches to development is Scott Hebner, the vice president for marketing and strategy for IBM Rational Software. Welcome to the show, Scott.
Scott Hebner: Thank you, Dana, glad to be here.
Gardner: First, collaboration has always been dicey issue with developers. There is a tension between individuals and small teams, and then groups of small teams, and then many groups of teams. What is the problem set that we are really addressing here with Jazz?
Hebner: Well, first of all, Jazz should be really thought of as a project to drive technology innovation in the whole space of collaborative, process-driven software engineering. It is a project that’s being managed by Rational in partnership with the IBM Research division to try some really deep innovation. We want to put some deep thought into the whole notion of how to help teams that are delivering software be more effective. And increasingly we will be opening up that technology project into an open community that more and more of our business partners and our customers and developers in general that can participate in.
In a nutshell, what Jazz is really all about is how to drive greater efficiencies, cost savings, and the ability to deliver software more effectively -- particularly in a world that’s becoming increasingly geographically diverse, increasingly modular. As customers move to things like services oriented architecture (SOA), it just drives the need to enhance the ability for teams to collaborate and gain access to the real-time information on the health of the project.
We're seeking to integrate the various services involved in managing the lifecycles of these projects. It's an evolution, but a profound one -- given where we are today.
Gardner: So we are describing this in terms of a community approach, a framework? Are there going to be contributions and plug-ins, something like Eclipse? Should we be looking at the Eclipse framework and foundation as a model for this?
Hebner: Yes, actually, I would. What is Jazz? I think maybe a good place to start would be there.
As I've said before, it is a major investment by IBM to create an innovative, collaborative software development technology base. It will not only will drive the evolution of our product for future years, but it’s also going to drive the evolution of many elements of the marketplace.
Another way of looking at it is Jazz is a market accelerator that will help customers implement some of the key trends that we see them moving toward. That includes the ability to manage software delivery more effectively, to leverage the supply chain, and to more effectively use software that’s being used to create and deliver software. You need a whole notion of community, modularity and empowerment to the path of a governance model.
To your point, I would think of Jazz as being the next big thing, if you will, beyond Eclipse in terms of shaping the IBM portfolio -- but also the marketplace. As you may know, Eclipse has more than two million users around the world. It's just had its fifth-year anniversary, and I think it's fair to say that the innovation behind Eclipse has really driven change in the marketplace. It has facilitated a lot of customer value in terms of the ability to integrate products within a lifecycle more effectively.
Eclipse did a lot on the client side, the user side, to integrate the desktop. You can think of Jazz as being a similar approach, but on the back end -- or the server side -- where the teams need to have the same ability to collaborate more effectively and to gain integration.
One of the more important things about Jazz is that it’s truly in the Eclipse way. In other words, if you think about Eclipse, it perhaps is one of the most successful software development projects in history. Over the last five years they have delivered really high-quality code. They have not missed a project milestone. They’ve been on time. It's a very efficient community that’s building and delivering software.
Jazz is being brought to us by the team that helped to lead Eclipse. What they are trying to do now is automate the lessons of this proven, open-collaborative model that Eclipse represents. And so I think we have learned a lot about how to facilitate collaboration. We have passive governance [to manage] a project that expands across multiple geographic locations and is always changing, is very dynamic. We are trying to "tool" that, if you will, to automate that, and take what we learned in that development project.
Gardner: Yes, we’d have to say that Eclipse has not only been successful on its own right, but has actually provided a great example, or model, for how community projects development should be done and governed.
Hebner: Exactly. I think many customers are looking at it and saying, "Well, there’s a lot of value in enhancing a community approach in how they develop and deliver the software. You can share skills more effectively, you can share assets, you can collaborate much more effectively around this model -- and gain a more open approach.
Right now such openness may be just within the company, or it may be within different departments in different locations. You know, we talk about globally diverse environments. But we should also talk about organizationally diverse environments, because more and more customers are outsourcing different elements of software delivery.
They may be testing in India. They may be outsourcing different parts of their project development. But ultimately you need to manage it all as one major project that needs to have some level of lifecycle management governance around it. And so, again, to go back to your original question, Jazz is being built from the team that brought us Eclipse. It is leveraging a lot of Eclipse technology as a foundation. If you think of Eclipse as sort of on the client, then Jazz is more on the team side of things.
Gardner: Okay. Now thinking about application lifecycle management as a topic, is that the large issue that we are addressing here? Is this really an application lifecycle management function, or is this more still of a development environment approach?
Hebner: I think it’s the broader notion of governance and lifecycle management -- service management, if you will. It focuses on how to help teams to be effective and to collaborate and to communicate more effectively. It also helps teams of teams. Right? And I think that’s where its ability to scale over time is going to be an important thing. I also think it’s something that Agile teams are really going to like. I mean it involves the whole notion of Agile development -- yet with the ability to scale.
So, in many ways, it is a lot more than software development. It’s really about team collaboration around the delivery of software. It's about lifecycle management, automating lifecycle management. It's about traceability of relationships between artifacts, automation of high-level processes, visibility into the processes and then reporting against it.
Jazz also helps to learn and deal with compliance issues, whether it's Capability Maturity Model® Integration (CMMI), or whether it's some regulatory issue like Sarbanes-Oxley compliance. I think it deals with the notion of integration -- of real-time access to information about the project in terms of collaboration and automation. Those are the kinds of buzz words that really starts to define what the next generation of a application lifecycle management platform needs to be.
Gardner: We are also starting to hear some things in the market around software development as a service. Are there any on-demand aspects to Jazz? Or is Jazz in a position to allow for more utilization of on-demand elements within a development lifecycle?
Hebner: Well, that’s a good question, and actually an intriguing one. I think as time rolls on much of what this technology base will do for products, and the ability to facilitate collaboration -- particularly in a geographically diverse environment -- will lend itself to doing things more effectively as software as a service (SaaS).
What I mean by that is that a part of the value of this technology is going to be greater collaboration and visibility into the process of software delivery. As I said before, you may have people that are part of broader teams in different time zones, different countries. They may be in different organizations in other companies that you are outsourcing to. And you want to be able to manage that as an integrated project, gain a lifecycle view of it. Then you will be able to manage it much more effectively, to get all those geographically distributed people in the projects to actually work together.
There is going to need to be some degree of hosting and Web access around Web 2.0 clients, or Eclipse clients, or whatever it may be. And if you think about that, in many ways it’s almost an internal software-as-a-service model.
For example, perhaps you’re providing a business partner with access to some of the key software development assets of your business so they can test against it. But you only want them to have access to certain aspects of it, and you don’t necessarily need to roll out to them all of your assets. And so how do you manage them? So I think an application of this technology over time will be the ability to better facilitate software as a service models for software development.
Gardner: Interesting. And at the same time, Scott, you mentioned a little earlier SOA. And as organizations are looking not to just create individual services, but to then aggregate, composite, and orchestrate these services, is this environment something that we could take to a higher process-level as well?
Hebner: Yes. I think SOA is a key driver behind the need for this. There is no doubt, at least in our minds, that we are seeing our customer base move to SOA. I think we’re beyond the hype-curve now. It’s just a degree of how much SOA, if you will. So I think more and more customers are moving to this notion of modularity, componentization, and reuse to align more effectively the IT investments with the business imperatives. They also want to lower costs and create greater efficiencies. And they want to address labor costs by automating things more effectively. So there are a lot of benefits to SOA.
What comes with that, though, is a lot of additional modularity in the components -- the notion of a supply chain of components -- that are then used to create applications, and then a lot more change. In the old days, it used to be quite straight forward. You built the applications from top to bottom as monolithic. You did everything from testing to requirements management, pretty much contained within your team.
Now you may have a component, a service, that’s being used in an application, and that’s also being used in 10 other applications. And then one of those applications has a change request against that one service. How do you ensure that that doesn’t adversely affect the other ones? And what governance model do you have in place to govern who makes decisions on requirements and changes?
So facilitating more and more modularity also drives more and more change. How do you manage all that? I think what it comes down to is you have to work effectively as a team. You need to be able to collaborate and communicate better. You need to be able to act as a team within these processes in ways that are flexible and actually take on the unique characteristics of how the team actually works. And I think you need to integrate the various elements of the lifecycle more effectively so that you have traceability of the artifacts; so that you have the ability to manage and gain access to the assets. You need to be able to have access to the real-time health of the project based on the real work that’s going on at that particular time.
Gardner: So developers are not only going to have to manage the creation of the code, but how that code behaves in production. But there are also going to be policies, rules, and governance set up around of variety of these services. And so they’re going to have to manage, in essence, those rules?
Hebner: Well, I think there’s really no way around it when you have a governance model, and a lifecycle management set of processes and policies in place. As you begin to componentize and reuse things, you’re setting up a situation where you can have quality problems.
Gardner: So we’re going to basically have governance lifecycle management?
Hebner: Yes, and I think the governance models, the procedures, and the decision rights are going to be the overriding definition of the lifecycle processes. But, you know, governance is one of those things that developers and development teams may not like the sound of.
Gardner: They usually thought about that as happening in the operational phase, after they’ve gotten rid of it right?
Hebner: Oh, Exactly. And we think this all can be a very empowering thing for the developers in the development teams. Because if you think about it, if you’re going to automate the governance model in the lifecycle policies -- in the actual infrastructure, so that the developers in the teams don’t actually have to do anything -- it’s all being done as part of the infrastructure. And then you operationalize it, and you automate it, and it then becomes what we call "passive governance."
That’s going to take a lot of paperwork off the developers’ backs, and they’re not going to have to really pay attention too much to it because the system is automated. If you want to make a change request, or you’re taking on a change request for a particular piece of software, the system will help keep track of the paperwork, the auditing, and who made the right decisions. We'll be able to do all that on behalf of the developer.
What we’re hearing from many of our customers is that the deeper we get into this notion of passive governance it actually empowers the teams to be more effective. It gives them more time to be able to really focus on applying their skills, which in most cases is building really good software. Where you don’t automate, it then becomes a burden.
So governance does not mean paperwork and policies. I think the goal is to automate it. And that’s what I think this Jazz technology is going to help us do more and more efficiently over time -- to automate and "operationalize" how processes in lifecycle management are made to work, and to do it in a way that facilitates collaboration and communications. It’s really nice when everyone in the project has the ability to get access to real-time information about the health of the project.
Gardner: It sounds like a strategic approach to governance -- about the relationship from design time to runtime, and perhaps a feedback loop between them.
Hebner: Yeah, it’s going to facilitate that, exactly. I think Jazz is fundamentally a technology investment around facilitating three things:
Gardner: One of the things that is also a concern to developers is that they like to use the tools they are familiar with. They don’t like to be told what to do. Is Jazz going to be inclusive of a variety of different tools and approaches? Is this going to support the Rational products, like ClearCase and ClearQuest and RequisitePro, and also be something that you can plug in other tools and approaches to? How open should we expect this to be?
Hebner: It’s going to be very open. Just as you would go out today and become part of a community with Eclipse, you’ll be able to join and become a part of a community with Jazz. What comes with that community is access to a software development platform for actually building products -- as well as extensions, plug-ins, and processes, all based on the technology. So over a period of time, people will be able to build with partners plug-ins and products based on the Jazz technology, just like they can build based on Eclipse.
Gardner: If you do have a commercial product that you want to allow to work within this framework, can you feel free to build the modules or connectors to them, or to use what’s available in the market?
Hebner: Yes, exactly. There’ll be different degrees of this. We’re still working that out. It’s not going to be completely an open source project like Eclipse, but there are going to be key elements of that. The idea is exactly as you just said. You’ll be able to open up the parts that make sense, those that have to do with adapters and interfaces and how you communicate. We want to bridge the ecosystem of developers and partners who are building plug-ins, extensions and products based on this technology base.
By doing that, a customer that starts to leverage any products -- including commercial products -- that are being delivered based on some of this technology will be able to integrate it with other services or products built by non-IBM companies. So that’s the whole idea of it being able to integrate. Think of it as an integration of a structure. Obviously you need to have an adaptor and a plug-in capability, otherwise why are you integrating?
Gardner: One of my industry colleagues, Carey Schwaber at Forrester Research, has coined the term "ALM 2.0." And a big part of that is to be able to be inclusive, to use many tools and components across a development process, or lifecycle. And you can then gain a larger value from coordinating and managing all of that.
Hebner: This is exactly right on. This is exactly what we are referring to here. ... This is middleware, if you will, for better integrating the various services involved with how you manage the lifecycle of your projects. The whole idea of the integration bus, in layman’s terms, is the ability to plug-in different products that you may want to use as a customer that make up your software development and delivery platforms, and all the lifecycle capabilities. That’s not all going to come from IBM. We would never think that.
Another part of your question was about the IBM Rational portfolio, and I think of Jazz as being a technology innovation that we are going to use to shape the direction of our products in our portfolio for years to come. It’s going to inspire and infuse new features and functions and technology capabilities into our portfolio. So Jazz is a reason to buy ClearCase and ClearQuest, for example. It’s not -- this isn’t about replacing anything, it’s about infusing new technology and innovation. It's about the collaborative, process-driven characteristics that we talked about. So it’s an extension of the value of our current product set, and doing what Eclipse did on the client, for the teams on the back end.
Gardner: I suppose another thing has been missing in the previous one-offs and smaller monolithic approaches is analytics across the entire process. Is this coordinating effect -- even coordinating at the governance and policy and services level -- going to give us more data, more insight, more metadata into how development works well, or not well? Will it help foster a constant, iterative improvement-based approach to development?
Hebner: Yes, absolutely. That’s what I meant by the process-enactment and the access to real-time help. The idea here is that you have visibility and gain collaboration into the software development process. And so what are some of the key value points that this technology will provide to customers?
I’ll tell you. The first one is that it will enable development teams to collaborate in real time, in the context of the work they are doing, and especially in globally diverse environments. The second thing is it enables projects to be managed more effectively by providing visibility into accurate, real-time project health information, effectively drawn from the actual work that’s going on. Obviously, there is a lot of reporting that goes around that.
Building on that, it automates traceability and auditibility my managing the artifacts and/or inter-relationships -- across the lifecycle, which, as I was saying before, empowers the teams to deliver more value. So you don’t have to worry about managing auditibility issues and traceability.
The system will do it for the development teams. And, finally, I think the final key piece of value here is that Jazz provides a customizable process design enactment, a kind of capability for rules-based process guidance. It becomes a lot easier to automate, to find check points. It allows you to enact processes that take on the unique characteristics of how a team has been operating. It kind of evolves and changes and learns from what works and what doesn’t work. This is a very Agile, real-time, collaborative kind of model.
I look at it sometimes and I think, Is this going to enable a developer portal? Is it going to enable a business-process engine for software delivery in lifecycle management? Or is it an integration infrastructure for the different products and services that make up what customers think of as lifecycle management?
The truth of the matter is that it’s all three. It’s not just a portal. It’s not just a process engine. And it’s not just integration infrastructure. I think it’s really all three integrated together, optimized for software delivery in helping development teams collaborate more effectively. Again, keep in mind that Jazz is a technology infrastructure. It’s a base of technology that will then be used to infuse new capabilities, new integration and new value into our current portfolio.
Gardner: Is Jazz a project name, a code name, or is this going to be the long-term nomenclature around this?
Hebner: It’s a project name. And whoever is listening to this can go out to www.jazz.net right now, and you can see the beginnings of the community. So, www.jazz.net will be the name of the community, which is already out there. And the key formal unveiling of this, where customers and you and others can get a lot more detail, will be at the Rational Software Development Conference, the first of which is in Orlando, Fla. on June 10-14, 2007.
If anyone is interested, go out to our website at www.ibm.com/rational and you’ll get information on the conference. We are also going to be having them in India, China and Israel. And there’s a bunch of other places where we will have these events throughout the year. But come June, that’s when we are going to focus a lot more on what we are doing around visibility and collaboration in the software development process. There will be a lot more detail about what we are talking about then.
Gardner: Is this going to be in beta until it comes out in an official sense later in the year? What’s the timetable for the full, official debut?
Hebner: Well, I think you are going to start to see a lot of that articulated at the conference. But in June there will be the ability for customers to begin to get involved and get their hands on this stuff. Not only the technology and the community, but it’s likely that there are going to be betas rolling out around other new products from IBM. And obviously the details of all that, and what that all really means, is part of what we are going to be talking about at the conference.
Gardner: So there will be a series of new IBM, and I assume Rational, products that debut in conjunction with the rollout of Jazz?
Hebner: Very likely. I’d go to conference and find out, but yes, we are doing this to really enrich the value of our portfolio. So clearly there will be new products. There will be new features and functions and capabilities infused into what we have today.
This is about enriching and involving our portfolio of products that make up the Rational Software delivery dlatform into this notion, as you said before, of ALM 2.0 and collaborative, process-driven software engineering. This is the next big thing, we would like to think, in software engineering -- beyond what Eclipse delivered five years ago.
Gardner: Will there be IBM products beyond the Rational portfolio involved with Jazz?
Hebner: I think it’s likely.
Gardner: WebSphere, perhaps?
Hebner: It’s point-to-point. Well, keep in mind you have Lotus, which is all about collaboration and people-productivity, and they have Lotus Designer. So some of those things will play in this, right?
Gardner: So this could be for scripting developers, Web developers, as well as C++ and Java developers?
Hebner: Yes, it’s a team environment for managing projects and assets in facilitating communications. Part of that may be building the portal applications that you may be using Lotus Designer to do. I think your point on WebSphere is right too. And already we have some pretty good integration with WebSphere Business Modeler, and the ability to leverage that to design processes. And then from there someone has to build an architecture that allows the delivery of services to implement those processes.
So I think those linkages get enhanced over time. I think Tivoli is another important element here, in that, when we talk about lifecycle management in governance, that doesn’t stop at the delivery of the software that flows into your operational state. And many of the change requests that get created actually occur in an operational setting -- from a user, for example. Right now there is a lot of labor cost associated with getting that change into the software development process, and to the requirements.
The more we can automate that and create collaboration that extends beyond just this core software development team, the more you can address labor costs and help customers in a broader notion of managing the lifecycle of their projects. And not only in delivering productions, but also in operations. Think of it as one massive lifecycle. This is the way it should be, right?
Gardner: Compress the time from development to deployment.
Hebner: Exactly. And the labor cost associated to that, too. There is a lot of labor that goes into that hand-off, in the communications between the operational team and the development team. And you have to have the testing in the middle there. There is a lot of automation that could be done in the communications and collaboration enhancements that really can drive the bottom line for customers in terms of cost.
Gardner: Sure. Now we talked earlier about how this compares interestingly to Eclipse. It also sounds like it compares interestingly to what Java was attempting to do 10 years ago. Is there some commonality between what Java accomplished as a development framework, and what now we are talking about with Jazz?
Hebner: I think at the very high level, yes. You are onto this notion of an open infrastructure.
Gardner: Sure, automating and bringing together elements that have been very disparate and difficult to manage.
Hebner: Exactly. So we had the idea of J2EE, for example, that was facilitating Web-based transactions and an enterprise platform for building enterprise applications that, by definition, integrate with other applications across an open world, right? And the more companies that would adopt that model, and build J2EE applications, the easier it was to share skills. And it was the whole idea of an open infrastructure model, right?
Gardner: A de facto industry standard.
Hebner: Exactly. Even though it wasn’t technically open in the sense that Sun Microsystems controlled a great deal of it. But Eclipse, conceptually, was the same kind of idea. Which is, if you really want to facilitate customer ability to integrate different tools at the desktop and enhance the ability to customize them and to build an ecosystem of all these tools that are more interchangeable -- then one company could not do that. You need to have an open model. I think the same would be true with Linux, and the same would be true of Apache.
Gardner: You need to have buy-in by the people who cooperate, as well as compete.
Hebner: Yes. Our thought here is learning from those experiences over the last 10 years -- going all the way back to Linux and Java, and even prior to that. The notion here is integration of a lifecycle, collaboration and communications, particularly in globally diverse and organizationally diverse environments. By definition, if you don’t take an open approach to that you are never going to be able to integrate all of that, and to automate it. It has to be open.
Gardner: One of the other things that’s been a bugaboo for developers is the whole complexity around check-in and check-out. And developer seats. And who is a simultaneous user and who isn’t. And how you charge for use. And how you audit for that, and license for it.
How are you going to charge for something like this? And does it perhaps have some impact on managing the whole process of the payments and usage of other aspects of development?
Hebner: Well, that’s a tricky question. And I don’t have all the answers for that.
I would say a couple of things here. One would be that -- keep in mind that a lot of this value, the incarnation of the value will be in our current product set to some degree. So if I am an IBM Rational ClearCase customer right now, this is going to add value to that installation. It’s going to add additional collaborative capabilities -- sort of a collaborative developer portal that allows you to get more value out of ClearCase.
In many ways there is already a model for how you buy and pay for ClearCase, right? As I was saying before, as new things come out, though, the pricing models for those and how they work ... Well, I just am not sure that we have all the answers ready to go out on that.
Gardner: How then would someone purchase or subscribe to Jazz, or how do you expect you’ll charge for it?
Hebner: We can say that Jazz is a technology project, right? So you will be able to get access to the www.jazz.net environment. How commercial entities -- whether they be IBM or some other company out there that chooses to use the technology -- how would they decide to deliver and price commercial products that leverage the Jazz innovation and the technology? By server, by user, or simultaneous -- all those things you brought up are legitimate questions. I don’t think we have all the answers on how Jazz is going to affect all that.
Gardner: But Jazz itself is not something that you are going to charge directly for?
Hebner: As far as the community?
Gardner: Yes.
Hebner: No. That’s not the current thought. We don’t want to announce anything that we haven’t gotten to the point of rolling out. But the idea is to facilitate open community and get access to the different elements of it. We want this to be an open, commercial development expression. We want our customers to share and participate. And how we evolve and develop our products, and the key way of doing this is through www.jazz.net.
Gardner: One last question, because we are about out of time. I suppose something this large, this impactful, this strategic, needs to appeal to a variety of different constituencies -- developers should probably be enticed to it and have a buy-in element. There should be architects enticed to it in some fashion, as well as the business side. Do you expect that you can address all of these constituencies? In a quick summation, what’s in it for each of them?
Hebner: I think each one of them should keep in mind that Jazz is an innovation technology project, and that innovation would get infused across the elements of our software delivery platform, which tends to be roles-based. In your requirements management, there’s going to be additional value in that, and that’s going to help you all collaborate and communicate more effectively with other parts of your software delivery team.
If you are a developer or an architect, you are going to be able to get better real-time information with different parts of the development team that are building different elements. You can have real-time access to who's doing what. And you can have traceability. You have the ability to better manage what’s actually going on.
If you are the project manager, or the executive in charge of the effort, you are going to have greater visibility, auditibility and traceability -- what’s actually going on in the project. You can then really predict more effectively, is it going to be a 12-month project or a 13-month or a 14-month one, right? And how are you progressing against those milestones? You are going to have more improved access to the real-time health of the project and where the milestones are, right?
So I think what it’s going to do is it's going to infuse these new capabilities into a variety of different parts of the portfolio that would then appeal to different roles at a customer. I think the overriding thing is that we have to better integrate, and have all those different roles work together and collaborate in delivering software. Because obviously they all are interdependent on each other. I think most customers would tell you today that they could always improve the ability for these people to work more effectively together, for different teams to work more effectively, and share assets, and make decisions more effectively, and not get into wars over which requirements, and so forth, and so on.
Gardner: It's really about communication, isn’t it?
Hebner: It’s about communication and collaboration in a real-time environment, so that you have real-time information to make better decisions. It’s really integrating and automating. I think these are the keywords here. So, automating how these people work with each other. It’s not just communications, but it’s automating how you work together with each other, and put a little bit more predictability and management into how it all comes together.
Gardner: It sounds very exciting, very impactful, and very ambitious. I'm glad we had a chance to talk about it.
We have been discussing the new Jazz approach to software development collaboration and application lifecycle management with Scott Hebner, the vice president of marketing and strategy for IBM Rational Software. We look forward to learning more about this in the coming months, and in June at the Rational Developer Conference. And for now, people can find out more about this at www.jazz.net.
Scott, thank you very much for your time and information. I'm sure this is a subject we’ll be discussing quite a bit over the next few years.
Hebner: You bet. Thank you very much, I appreciate it.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a BriefingsDirect podcast. Thanks for joining.
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.
Transcript of the BriefingsDirect podcast on the IBM Jazz collaborative application development and deployment framework. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Listen to the podcast here.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, a podcast discussion about application lifecycle management (ALM), collaboration, and the productivity of developers in teams. We are going to be discussing an upcoming product announcement -- perhaps maybe we should call it a community announcement -- by the IBM Rational Software division.
They are going to be announcing in June at their Rational Developer Conference in Orlando, Fla., a technology set called "Jazz." And here to tell us more about it and describe the benefits and issues around new collaborative approaches to development is Scott Hebner, the vice president for marketing and strategy for IBM Rational Software. Welcome to the show, Scott.
Scott Hebner: Thank you, Dana, glad to be here.
Gardner: First, collaboration has always been dicey issue with developers. There is a tension between individuals and small teams, and then groups of small teams, and then many groups of teams. What is the problem set that we are really addressing here with Jazz?
Hebner: Well, first of all, Jazz should be really thought of as a project to drive technology innovation in the whole space of collaborative, process-driven software engineering. It is a project that’s being managed by Rational in partnership with the IBM Research division to try some really deep innovation. We want to put some deep thought into the whole notion of how to help teams that are delivering software be more effective. And increasingly we will be opening up that technology project into an open community that more and more of our business partners and our customers and developers in general that can participate in.
In a nutshell, what Jazz is really all about is how to drive greater efficiencies, cost savings, and the ability to deliver software more effectively -- particularly in a world that’s becoming increasingly geographically diverse, increasingly modular. As customers move to things like services oriented architecture (SOA), it just drives the need to enhance the ability for teams to collaborate and gain access to the real-time information on the health of the project.
We're seeking to integrate the various services involved in managing the lifecycles of these projects. It's an evolution, but a profound one -- given where we are today.
Gardner: So we are describing this in terms of a community approach, a framework? Are there going to be contributions and plug-ins, something like Eclipse? Should we be looking at the Eclipse framework and foundation as a model for this?
Hebner: Yes, actually, I would. What is Jazz? I think maybe a good place to start would be there.
As I've said before, it is a major investment by IBM to create an innovative, collaborative software development technology base. It will not only will drive the evolution of our product for future years, but it’s also going to drive the evolution of many elements of the marketplace.
Another way of looking at it is Jazz is a market accelerator that will help customers implement some of the key trends that we see them moving toward. That includes the ability to manage software delivery more effectively, to leverage the supply chain, and to more effectively use software that’s being used to create and deliver software. You need a whole notion of community, modularity and empowerment to the path of a governance model.
To your point, I would think of Jazz as being the next big thing, if you will, beyond Eclipse in terms of shaping the IBM portfolio -- but also the marketplace. As you may know, Eclipse has more than two million users around the world. It's just had its fifth-year anniversary, and I think it's fair to say that the innovation behind Eclipse has really driven change in the marketplace. It has facilitated a lot of customer value in terms of the ability to integrate products within a lifecycle more effectively.
Eclipse did a lot on the client side, the user side, to integrate the desktop. You can think of Jazz as being a similar approach, but on the back end -- or the server side -- where the teams need to have the same ability to collaborate more effectively and to gain integration.
One of the more important things about Jazz is that it’s truly in the Eclipse way. In other words, if you think about Eclipse, it perhaps is one of the most successful software development projects in history. Over the last five years they have delivered really high-quality code. They have not missed a project milestone. They’ve been on time. It's a very efficient community that’s building and delivering software.
Jazz is being brought to us by the team that helped to lead Eclipse. What they are trying to do now is automate the lessons of this proven, open-collaborative model that Eclipse represents. And so I think we have learned a lot about how to facilitate collaboration. We have passive governance [to manage] a project that expands across multiple geographic locations and is always changing, is very dynamic. We are trying to "tool" that, if you will, to automate that, and take what we learned in that development project.
Gardner: Yes, we’d have to say that Eclipse has not only been successful on its own right, but has actually provided a great example, or model, for how community projects development should be done and governed.
Hebner: Exactly. I think many customers are looking at it and saying, "Well, there’s a lot of value in enhancing a community approach in how they develop and deliver the software. You can share skills more effectively, you can share assets, you can collaborate much more effectively around this model -- and gain a more open approach.
Right now such openness may be just within the company, or it may be within different departments in different locations. You know, we talk about globally diverse environments. But we should also talk about organizationally diverse environments, because more and more customers are outsourcing different elements of software delivery.
They may be testing in India. They may be outsourcing different parts of their project development. But ultimately you need to manage it all as one major project that needs to have some level of lifecycle management governance around it. And so, again, to go back to your original question, Jazz is being built from the team that brought us Eclipse. It is leveraging a lot of Eclipse technology as a foundation. If you think of Eclipse as sort of on the client, then Jazz is more on the team side of things.
Gardner: Okay. Now thinking about application lifecycle management as a topic, is that the large issue that we are addressing here? Is this really an application lifecycle management function, or is this more still of a development environment approach?
Hebner: I think it’s the broader notion of governance and lifecycle management -- service management, if you will. It focuses on how to help teams to be effective and to collaborate and to communicate more effectively. It also helps teams of teams. Right? And I think that’s where its ability to scale over time is going to be an important thing. I also think it’s something that Agile teams are really going to like. I mean it involves the whole notion of Agile development -- yet with the ability to scale.
So, in many ways, it is a lot more than software development. It’s really about team collaboration around the delivery of software. It's about lifecycle management, automating lifecycle management. It's about traceability of relationships between artifacts, automation of high-level processes, visibility into the processes and then reporting against it.
Jazz also helps to learn and deal with compliance issues, whether it's Capability Maturity Model® Integration (CMMI), or whether it's some regulatory issue like Sarbanes-Oxley compliance. I think it deals with the notion of integration -- of real-time access to information about the project in terms of collaboration and automation. Those are the kinds of buzz words that really starts to define what the next generation of a application lifecycle management platform needs to be.
Gardner: We are also starting to hear some things in the market around software development as a service. Are there any on-demand aspects to Jazz? Or is Jazz in a position to allow for more utilization of on-demand elements within a development lifecycle?
Hebner: Well, that’s a good question, and actually an intriguing one. I think as time rolls on much of what this technology base will do for products, and the ability to facilitate collaboration -- particularly in a geographically diverse environment -- will lend itself to doing things more effectively as software as a service (SaaS).
What I mean by that is that a part of the value of this technology is going to be greater collaboration and visibility into the process of software delivery. As I said before, you may have people that are part of broader teams in different time zones, different countries. They may be in different organizations in other companies that you are outsourcing to. And you want to be able to manage that as an integrated project, gain a lifecycle view of it. Then you will be able to manage it much more effectively, to get all those geographically distributed people in the projects to actually work together.
There is going to need to be some degree of hosting and Web access around Web 2.0 clients, or Eclipse clients, or whatever it may be. And if you think about that, in many ways it’s almost an internal software-as-a-service model.
For example, perhaps you’re providing a business partner with access to some of the key software development assets of your business so they can test against it. But you only want them to have access to certain aspects of it, and you don’t necessarily need to roll out to them all of your assets. And so how do you manage them? So I think an application of this technology over time will be the ability to better facilitate software as a service models for software development.
Gardner: Interesting. And at the same time, Scott, you mentioned a little earlier SOA. And as organizations are looking not to just create individual services, but to then aggregate, composite, and orchestrate these services, is this environment something that we could take to a higher process-level as well?
Hebner: Yes. I think SOA is a key driver behind the need for this. There is no doubt, at least in our minds, that we are seeing our customer base move to SOA. I think we’re beyond the hype-curve now. It’s just a degree of how much SOA, if you will. So I think more and more customers are moving to this notion of modularity, componentization, and reuse to align more effectively the IT investments with the business imperatives. They also want to lower costs and create greater efficiencies. And they want to address labor costs by automating things more effectively. So there are a lot of benefits to SOA.
What comes with that, though, is a lot of additional modularity in the components -- the notion of a supply chain of components -- that are then used to create applications, and then a lot more change. In the old days, it used to be quite straight forward. You built the applications from top to bottom as monolithic. You did everything from testing to requirements management, pretty much contained within your team.
Now you may have a component, a service, that’s being used in an application, and that’s also being used in 10 other applications. And then one of those applications has a change request against that one service. How do you ensure that that doesn’t adversely affect the other ones? And what governance model do you have in place to govern who makes decisions on requirements and changes?
So facilitating more and more modularity also drives more and more change. How do you manage all that? I think what it comes down to is you have to work effectively as a team. You need to be able to collaborate and communicate better. You need to be able to act as a team within these processes in ways that are flexible and actually take on the unique characteristics of how the team actually works. And I think you need to integrate the various elements of the lifecycle more effectively so that you have traceability of the artifacts; so that you have the ability to manage and gain access to the assets. You need to be able to have access to the real-time health of the project based on the real work that’s going on at that particular time.
Gardner: So developers are not only going to have to manage the creation of the code, but how that code behaves in production. But there are also going to be policies, rules, and governance set up around of variety of these services. And so they’re going to have to manage, in essence, those rules?
Hebner: Well, I think there’s really no way around it when you have a governance model, and a lifecycle management set of processes and policies in place. As you begin to componentize and reuse things, you’re setting up a situation where you can have quality problems.
Gardner: So we’re going to basically have governance lifecycle management?
Hebner: Yes, and I think the governance models, the procedures, and the decision rights are going to be the overriding definition of the lifecycle processes. But, you know, governance is one of those things that developers and development teams may not like the sound of.
Gardner: They usually thought about that as happening in the operational phase, after they’ve gotten rid of it right?
Hebner: Oh, Exactly. And we think this all can be a very empowering thing for the developers in the development teams. Because if you think about it, if you’re going to automate the governance model in the lifecycle policies -- in the actual infrastructure, so that the developers in the teams don’t actually have to do anything -- it’s all being done as part of the infrastructure. And then you operationalize it, and you automate it, and it then becomes what we call "passive governance."
That’s going to take a lot of paperwork off the developers’ backs, and they’re not going to have to really pay attention too much to it because the system is automated. If you want to make a change request, or you’re taking on a change request for a particular piece of software, the system will help keep track of the paperwork, the auditing, and who made the right decisions. We'll be able to do all that on behalf of the developer.
What we’re hearing from many of our customers is that the deeper we get into this notion of passive governance it actually empowers the teams to be more effective. It gives them more time to be able to really focus on applying their skills, which in most cases is building really good software. Where you don’t automate, it then becomes a burden.
So governance does not mean paperwork and policies. I think the goal is to automate it. And that’s what I think this Jazz technology is going to help us do more and more efficiently over time -- to automate and "operationalize" how processes in lifecycle management are made to work, and to do it in a way that facilitates collaboration and communications. It’s really nice when everyone in the project has the ability to get access to real-time information about the health of the project.
Gardner: It sounds like a strategic approach to governance -- about the relationship from design time to runtime, and perhaps a feedback loop between them.
Hebner: Yeah, it’s going to facilitate that, exactly. I think Jazz is fundamentally a technology investment around facilitating three things:
- Collaboration and communications among the development team.
- The ability to have customers enact business processes for the teams that can take on the unique characteristics of how those teams are operating and need to operate, so an Agile-kind of capability.
- And thirdly it’s about an infrastructure that will help customers better integrate the various services involved in managing the lifecycle to their assets and projects.
Gardner: One of the things that is also a concern to developers is that they like to use the tools they are familiar with. They don’t like to be told what to do. Is Jazz going to be inclusive of a variety of different tools and approaches? Is this going to support the Rational products, like ClearCase and ClearQuest and RequisitePro, and also be something that you can plug in other tools and approaches to? How open should we expect this to be?
Hebner: It’s going to be very open. Just as you would go out today and become part of a community with Eclipse, you’ll be able to join and become a part of a community with Jazz. What comes with that community is access to a software development platform for actually building products -- as well as extensions, plug-ins, and processes, all based on the technology. So over a period of time, people will be able to build with partners plug-ins and products based on the Jazz technology, just like they can build based on Eclipse.
Gardner: If you do have a commercial product that you want to allow to work within this framework, can you feel free to build the modules or connectors to them, or to use what’s available in the market?
Hebner: Yes, exactly. There’ll be different degrees of this. We’re still working that out. It’s not going to be completely an open source project like Eclipse, but there are going to be key elements of that. The idea is exactly as you just said. You’ll be able to open up the parts that make sense, those that have to do with adapters and interfaces and how you communicate. We want to bridge the ecosystem of developers and partners who are building plug-ins, extensions and products based on this technology base.
By doing that, a customer that starts to leverage any products -- including commercial products -- that are being delivered based on some of this technology will be able to integrate it with other services or products built by non-IBM companies. So that’s the whole idea of it being able to integrate. Think of it as an integration of a structure. Obviously you need to have an adaptor and a plug-in capability, otherwise why are you integrating?
Gardner: One of my industry colleagues, Carey Schwaber at Forrester Research, has coined the term "ALM 2.0." And a big part of that is to be able to be inclusive, to use many tools and components across a development process, or lifecycle. And you can then gain a larger value from coordinating and managing all of that.
Hebner: This is exactly right on. This is exactly what we are referring to here. ... This is middleware, if you will, for better integrating the various services involved with how you manage the lifecycle of your projects. The whole idea of the integration bus, in layman’s terms, is the ability to plug-in different products that you may want to use as a customer that make up your software development and delivery platforms, and all the lifecycle capabilities. That’s not all going to come from IBM. We would never think that.
Another part of your question was about the IBM Rational portfolio, and I think of Jazz as being a technology innovation that we are going to use to shape the direction of our products in our portfolio for years to come. It’s going to inspire and infuse new features and functions and technology capabilities into our portfolio. So Jazz is a reason to buy ClearCase and ClearQuest, for example. It’s not -- this isn’t about replacing anything, it’s about infusing new technology and innovation. It's about the collaborative, process-driven characteristics that we talked about. So it’s an extension of the value of our current product set, and doing what Eclipse did on the client, for the teams on the back end.
Gardner: I suppose another thing has been missing in the previous one-offs and smaller monolithic approaches is analytics across the entire process. Is this coordinating effect -- even coordinating at the governance and policy and services level -- going to give us more data, more insight, more metadata into how development works well, or not well? Will it help foster a constant, iterative improvement-based approach to development?
Hebner: Yes, absolutely. That’s what I meant by the process-enactment and the access to real-time help. The idea here is that you have visibility and gain collaboration into the software development process. And so what are some of the key value points that this technology will provide to customers?
I’ll tell you. The first one is that it will enable development teams to collaborate in real time, in the context of the work they are doing, and especially in globally diverse environments. The second thing is it enables projects to be managed more effectively by providing visibility into accurate, real-time project health information, effectively drawn from the actual work that’s going on. Obviously, there is a lot of reporting that goes around that.
Building on that, it automates traceability and auditibility my managing the artifacts and/or inter-relationships -- across the lifecycle, which, as I was saying before, empowers the teams to deliver more value. So you don’t have to worry about managing auditibility issues and traceability.
The system will do it for the development teams. And, finally, I think the final key piece of value here is that Jazz provides a customizable process design enactment, a kind of capability for rules-based process guidance. It becomes a lot easier to automate, to find check points. It allows you to enact processes that take on the unique characteristics of how a team has been operating. It kind of evolves and changes and learns from what works and what doesn’t work. This is a very Agile, real-time, collaborative kind of model.
I look at it sometimes and I think, Is this going to enable a developer portal? Is it going to enable a business-process engine for software delivery in lifecycle management? Or is it an integration infrastructure for the different products and services that make up what customers think of as lifecycle management?
The truth of the matter is that it’s all three. It’s not just a portal. It’s not just a process engine. And it’s not just integration infrastructure. I think it’s really all three integrated together, optimized for software delivery in helping development teams collaborate more effectively. Again, keep in mind that Jazz is a technology infrastructure. It’s a base of technology that will then be used to infuse new capabilities, new integration and new value into our current portfolio.
Gardner: Is Jazz a project name, a code name, or is this going to be the long-term nomenclature around this?
Hebner: It’s a project name. And whoever is listening to this can go out to www.jazz.net right now, and you can see the beginnings of the community. So, www.jazz.net will be the name of the community, which is already out there. And the key formal unveiling of this, where customers and you and others can get a lot more detail, will be at the Rational Software Development Conference, the first of which is in Orlando, Fla. on June 10-14, 2007.
If anyone is interested, go out to our website at www.ibm.com/rational and you’ll get information on the conference. We are also going to be having them in India, China and Israel. And there’s a bunch of other places where we will have these events throughout the year. But come June, that’s when we are going to focus a lot more on what we are doing around visibility and collaboration in the software development process. There will be a lot more detail about what we are talking about then.
Gardner: Is this going to be in beta until it comes out in an official sense later in the year? What’s the timetable for the full, official debut?
Hebner: Well, I think you are going to start to see a lot of that articulated at the conference. But in June there will be the ability for customers to begin to get involved and get their hands on this stuff. Not only the technology and the community, but it’s likely that there are going to be betas rolling out around other new products from IBM. And obviously the details of all that, and what that all really means, is part of what we are going to be talking about at the conference.
Gardner: So there will be a series of new IBM, and I assume Rational, products that debut in conjunction with the rollout of Jazz?
Hebner: Very likely. I’d go to conference and find out, but yes, we are doing this to really enrich the value of our portfolio. So clearly there will be new products. There will be new features and functions and capabilities infused into what we have today.
This is about enriching and involving our portfolio of products that make up the Rational Software delivery dlatform into this notion, as you said before, of ALM 2.0 and collaborative, process-driven software engineering. This is the next big thing, we would like to think, in software engineering -- beyond what Eclipse delivered five years ago.
Gardner: Will there be IBM products beyond the Rational portfolio involved with Jazz?
Hebner: I think it’s likely.
Gardner: WebSphere, perhaps?
Hebner: It’s point-to-point. Well, keep in mind you have Lotus, which is all about collaboration and people-productivity, and they have Lotus Designer. So some of those things will play in this, right?
Gardner: So this could be for scripting developers, Web developers, as well as C++ and Java developers?
Hebner: Yes, it’s a team environment for managing projects and assets in facilitating communications. Part of that may be building the portal applications that you may be using Lotus Designer to do. I think your point on WebSphere is right too. And already we have some pretty good integration with WebSphere Business Modeler, and the ability to leverage that to design processes. And then from there someone has to build an architecture that allows the delivery of services to implement those processes.
So I think those linkages get enhanced over time. I think Tivoli is another important element here, in that, when we talk about lifecycle management in governance, that doesn’t stop at the delivery of the software that flows into your operational state. And many of the change requests that get created actually occur in an operational setting -- from a user, for example. Right now there is a lot of labor cost associated with getting that change into the software development process, and to the requirements.
The more we can automate that and create collaboration that extends beyond just this core software development team, the more you can address labor costs and help customers in a broader notion of managing the lifecycle of their projects. And not only in delivering productions, but also in operations. Think of it as one massive lifecycle. This is the way it should be, right?
Gardner: Compress the time from development to deployment.
Hebner: Exactly. And the labor cost associated to that, too. There is a lot of labor that goes into that hand-off, in the communications between the operational team and the development team. And you have to have the testing in the middle there. There is a lot of automation that could be done in the communications and collaboration enhancements that really can drive the bottom line for customers in terms of cost.
Gardner: Sure. Now we talked earlier about how this compares interestingly to Eclipse. It also sounds like it compares interestingly to what Java was attempting to do 10 years ago. Is there some commonality between what Java accomplished as a development framework, and what now we are talking about with Jazz?
Hebner: I think at the very high level, yes. You are onto this notion of an open infrastructure.
Gardner: Sure, automating and bringing together elements that have been very disparate and difficult to manage.
Hebner: Exactly. So we had the idea of J2EE, for example, that was facilitating Web-based transactions and an enterprise platform for building enterprise applications that, by definition, integrate with other applications across an open world, right? And the more companies that would adopt that model, and build J2EE applications, the easier it was to share skills. And it was the whole idea of an open infrastructure model, right?
Gardner: A de facto industry standard.
Hebner: Exactly. Even though it wasn’t technically open in the sense that Sun Microsystems controlled a great deal of it. But Eclipse, conceptually, was the same kind of idea. Which is, if you really want to facilitate customer ability to integrate different tools at the desktop and enhance the ability to customize them and to build an ecosystem of all these tools that are more interchangeable -- then one company could not do that. You need to have an open model. I think the same would be true with Linux, and the same would be true of Apache.
Gardner: You need to have buy-in by the people who cooperate, as well as compete.
Hebner: Yes. Our thought here is learning from those experiences over the last 10 years -- going all the way back to Linux and Java, and even prior to that. The notion here is integration of a lifecycle, collaboration and communications, particularly in globally diverse and organizationally diverse environments. By definition, if you don’t take an open approach to that you are never going to be able to integrate all of that, and to automate it. It has to be open.
Gardner: One of the other things that’s been a bugaboo for developers is the whole complexity around check-in and check-out. And developer seats. And who is a simultaneous user and who isn’t. And how you charge for use. And how you audit for that, and license for it.
How are you going to charge for something like this? And does it perhaps have some impact on managing the whole process of the payments and usage of other aspects of development?
Hebner: Well, that’s a tricky question. And I don’t have all the answers for that.
I would say a couple of things here. One would be that -- keep in mind that a lot of this value, the incarnation of the value will be in our current product set to some degree. So if I am an IBM Rational ClearCase customer right now, this is going to add value to that installation. It’s going to add additional collaborative capabilities -- sort of a collaborative developer portal that allows you to get more value out of ClearCase.
In many ways there is already a model for how you buy and pay for ClearCase, right? As I was saying before, as new things come out, though, the pricing models for those and how they work ... Well, I just am not sure that we have all the answers ready to go out on that.
Gardner: How then would someone purchase or subscribe to Jazz, or how do you expect you’ll charge for it?
Hebner: We can say that Jazz is a technology project, right? So you will be able to get access to the www.jazz.net environment. How commercial entities -- whether they be IBM or some other company out there that chooses to use the technology -- how would they decide to deliver and price commercial products that leverage the Jazz innovation and the technology? By server, by user, or simultaneous -- all those things you brought up are legitimate questions. I don’t think we have all the answers on how Jazz is going to affect all that.
Gardner: But Jazz itself is not something that you are going to charge directly for?
Hebner: As far as the community?
Gardner: Yes.
Hebner: No. That’s not the current thought. We don’t want to announce anything that we haven’t gotten to the point of rolling out. But the idea is to facilitate open community and get access to the different elements of it. We want this to be an open, commercial development expression. We want our customers to share and participate. And how we evolve and develop our products, and the key way of doing this is through www.jazz.net.
Gardner: One last question, because we are about out of time. I suppose something this large, this impactful, this strategic, needs to appeal to a variety of different constituencies -- developers should probably be enticed to it and have a buy-in element. There should be architects enticed to it in some fashion, as well as the business side. Do you expect that you can address all of these constituencies? In a quick summation, what’s in it for each of them?
Hebner: I think each one of them should keep in mind that Jazz is an innovation technology project, and that innovation would get infused across the elements of our software delivery platform, which tends to be roles-based. In your requirements management, there’s going to be additional value in that, and that’s going to help you all collaborate and communicate more effectively with other parts of your software delivery team.
If you are a developer or an architect, you are going to be able to get better real-time information with different parts of the development team that are building different elements. You can have real-time access to who's doing what. And you can have traceability. You have the ability to better manage what’s actually going on.
If you are the project manager, or the executive in charge of the effort, you are going to have greater visibility, auditibility and traceability -- what’s actually going on in the project. You can then really predict more effectively, is it going to be a 12-month project or a 13-month or a 14-month one, right? And how are you progressing against those milestones? You are going to have more improved access to the real-time health of the project and where the milestones are, right?
So I think what it’s going to do is it's going to infuse these new capabilities into a variety of different parts of the portfolio that would then appeal to different roles at a customer. I think the overriding thing is that we have to better integrate, and have all those different roles work together and collaborate in delivering software. Because obviously they all are interdependent on each other. I think most customers would tell you today that they could always improve the ability for these people to work more effectively together, for different teams to work more effectively, and share assets, and make decisions more effectively, and not get into wars over which requirements, and so forth, and so on.
Gardner: It's really about communication, isn’t it?
Hebner: It’s about communication and collaboration in a real-time environment, so that you have real-time information to make better decisions. It’s really integrating and automating. I think these are the keywords here. So, automating how these people work with each other. It’s not just communications, but it’s automating how you work together with each other, and put a little bit more predictability and management into how it all comes together.
Gardner: It sounds very exciting, very impactful, and very ambitious. I'm glad we had a chance to talk about it.
We have been discussing the new Jazz approach to software development collaboration and application lifecycle management with Scott Hebner, the vice president of marketing and strategy for IBM Rational Software. We look forward to learning more about this in the coming months, and in June at the Rational Developer Conference. And for now, people can find out more about this at www.jazz.net.
Scott, thank you very much for your time and information. I'm sure this is a subject we’ll be discussing quite a bit over the next few years.
Hebner: You bet. Thank you very much, I appreciate it.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a BriefingsDirect podcast. Thanks for joining.
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.
Transcript of the BriefingsDirect podcast on the IBM Jazz collaborative application development and deployment framework. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Thursday, May 03, 2007
Transcript of BriefingsDirect Podcast on SOA and Open Source Community Development
Edited transcript of BriefingsDirect[TM/SM] podcast with host Dana Gardner, recorded March 27, 2007. Podcast sponsor: IONA Technologies.
Listen to the podcast here.
Dana Gardner: Hello, this is Dana Gardner, principal analyst at Interarbor Solutions and you are listening to a sponsored BriefingsDirect podcast. Today, a discussion about Services Oriented Architecture (SOA) and open-source software -- how incubation projects and the development of community-based code are a big part of the ongoing maturation of SOA. We’re specifically going to be discussing the incubation Apache CXF project. And here to help us profile and understand this project, its goals and its implications are two representatives from IONA Technologies.
First, we have Dan Kulp. Dan is a principal engineer at IONA Technologies, and he’s been concentrating on Java and Web services technologies. He is also a community lead for IONA’s open-source initiatives, and is furthermore a committer on the Maven Project for plug-ins, Apache Tuscany and Apache Yoko projects.
Also joining us is Debbie Moynihan, the director of open source programs at IONA. I want to welcome both Dan and Debbie.
Debbie Moynihan: Thank you, Dana.
Dan Kulp: Thank you.
Gardner: As we mentioned, there’s an interesting -- and perhaps unprecedented -- intersection between the maturation of SOA as a concept, a philosophy and an approach to computing, and also the role of open source in community-based development. Many times in the past, we’ve seen the commercial development of products that are spun off into open-source projects of a similar nature. But with SOA it seems that things are different. We’ve got a fairly wide variety of projects happening simultaneously as many of the commercial vendors are also putting together products, approaches, frameworks, standards and specifications to help companies develop and manage SOA.
So tell us a little bit about the playing field for open source and SOA, and particularly CXF, which is an ESB project. First let me go to Dan. We’ve seen a variety of different products out there. Why do you think it is that SOA is different from the past, and why do we have so many open source projects simultaneous with commercial products?
Kulp: The open source projects are providing a unique opportunity for developers to get their hands dirty and learn a little bit about the field, as well as contribute back some of their ideas in a form that is very healthy for new technologies like SOA. With SOA being very new, there are a lot of ideas flying around, and people are coming up with new ideas and technologies just about every day. The open-source communities that are popping up are very good places to foster those ideas and solidify them into something that’s maybe not just usable by that particular developer’s applications, but also across a wide variety of customer- and user-driven problems.
Gardner: We’re also seeing a combination of best-of-breed, more discreet components standing on their own for SOA activities, as well as more of an integrated stack or suite approach by many vendors. At the same time, we’re seeing open source and commercial. So, there’s a real mixture, a hodgepodge of code, component and infrastructure for those that are evaluating and working toward SOA. Why is that? Is it that SOA is, by definition, more of a componentized undertaking? I’ll throw this out to either Debbie or Dan.
Kulp: It definitely is. If you look at the goals of SOA, you may have some older legacy systems that you want to expose into your SOA, so that newer applications or newer development efforts can talk to those, but you also have all this new stuff that’s popping up. You have all these brand new AJAX applications and other applications that basically present a whole new set of challenges, a whole new set of connectivity options -- just a lot of technologies to connect all these things.
That’s why you see a bunch of these stacks producing different types of connectivity options. Obviously, a lot of commercial vendors are creating large stacks that are designed to target their customers with things that they have supported in the past, and obviously they have to bring their customers up to the newer technologies. When you look toward the open-source stuff, it’s more about connecting newer systems and newer technologies that are really hot and sexy today.
Gardner: So, a little bit of the old and the new -- the more the merrier.
Kulp: Exactly.
Gardner: I suppose that the good news is that it’s "the more the merrier," and there are lots of options, but I think for some people who are traditional IT folks that that many options and that much choice can be daunting and confusing. How do we look at the current landscape of best-of-breed and suites of open-source and commercial and make some sense of that?
Moynihan: Well, one of the things we're trying to do at IONA is help users with the best-of-breed SOA infrastructure technologies that are out there in open source, and to integrate those together in a certified and tested package. This makes it easier for them to leverage multiple projects together. Because there are quite a few best-of-breed approaches and there are a lot of different options. The other thing is that certain communities seem to attract SOA types of technologies, and we participate in each of those -- Apache, Eclipse Foundation, ObjectWeb, to name three of them -- and that’s a good place for people to start. I think with SOA also there are a lot of loosely coupled components, and that actually lends itself well to best-of-breed, and it allows multiple vendors to participate, with each providing what they're really good at.
Gardner: Maybe we should point out here that CXF has a certain legacy and heritage that is close to IONA. Why don’t we briefly give an overview, Debbie maybe from you, on the lineage and history of CXF?
Moynihan: Sure, about a year and a half ago IONA made a proactive decision to initiate the creation of an open-source project called Celtix in the ObjectWeb community to focus on building an open-source ESB. We got that to the first milestone and got a really good foundation. It was following along the same architectural path as IONA’s other offerings, a lightweight, standards-based approach, allowing you to lay on top of any technology that you already have in place, rather than taking a stack type of approach. At one point we wanted to grow the community. We had a lot of interest from other projects in the Apache community. And there was another project called XFire, with which we had a lot of synergies and shared goals.
That led to some discussions, and we eventually made the decision to merge XFire with Celtix and moved them over to the Apache community. We thought it made sense to start a new community with the merged project, and that evolved into CXF. Dan can go into a lot more detail about where we are with the CXF project, but we’ve taken what we had with Celtix and XFire and brought the best of both of those together. And we continue to make a lot of progress there.
Gardner: One thing I want to understand is why open source is a strong approach for the development of certain products, in this case SOA-type products. As I said, I looked at the incubator page for CXF and I see the goals are, "support for standards," "multiple transports," "bindings," "data bindings," "formats," "flexible deployment," and "support for multiple programming languages."
It seems as if, by nature, an open-source approach to SOA has advantages. A commercial vendor and private-code vendor might have some of these goals as well, but they are also going to be mindful of their heritage and their legacy. Is there, from an open-source community level, an advantage to developing an ESB, for example, in a more inclusive way -- to create an ecology, to create a community, where people will contribute? And let me throw that out to Dan.
Kulp: Oh, definitely. There’s a lot of functionality that ends up in a lot of open-source projects that really wasn’t a priority -- or even sometimes a consideration -- when those projects where originally created by the various vendors that push to get these projects started. One of the things about closed-source projects is anything that’s really developed is specific to that vendor’s customers. If their customers have various requirements, that’s what gets developed. They're trying to get new customers. That’s always a goal. But if one of their customer says, “Hey, I need this now,” a lot of other things don’t get developed.
Whereas one of the goals of an open-source community is to bring new developers in. And a lot of times those new developers have different priorities or different ideas of what an ESB should do. They can provide a lot of expertise and new and fresh ideas that can make the open-source project a bit different than closed source, and provide some unique features.
Gardner: I suppose one of the tricky parts about any private source or closed source or commercial development and requirements phases is where we draw the line. We’ve got a deadline to meet, there are only certain things we can do within that timeframe, and those are going to be dependent upon our business goals. That’s fine -- there's nothing wrong with that. But it’s a different beast when you’re developing your requirements within an open-source ecology of contributors.
Kulp: Definitely. One of the most fascinating things about the open-source community is something may not be my number-one requirement. But if it’s one of the other developer's number-one requirements, they’re more than welcome to work on it and get it done. So in my mind it would have slipped. But in his mind it would have gotten done. It’s a fascinating environment.
Gardner: I suppose it’s also a two-way street. If there’s an ecology that contributors can bring into these definitions and capabilities, they can have many more integration points, many more approaches of how this relates to different implementations in the field. That’s one direction. The other direction is that developers can say, "Listen, we want to be able to work with what this project produces -- and we happen to be of a certain flavor of development" ... like, "I am a Spring developer" or "I am a J2EE developer."
Tell us a little bit about why this makes sense for developers. They can set this project up so that they can better take advantage of what it does, right?
Kulp: Right. You bring up a good example with the Spring stuff that you just mentioned. Originally, when we were doing a lot of the Celtix stuff, we were still in ObjectWeb, and Spring wasn’t really one of our priorities. From IONA’s standpoint, it’s not something that we’ve really experienced much with our customers. But as part of the merge with XFire, that user base was a little different than the Celtix user base.
Priorities got shifted, and we started developing more flexible models for deployment that allow the use of Spring, if you’re a Spring person. If you’re not a Spring developer, we have other options that are available to deploy your applications in a very different format. That provides a lot of flexibility when you get that broad community throwing ideas out there.
Gardner: I suppose that many times, from a commercial perspective, you’ll get the vendor saying, "Here are the tools we’re going to use."
Kulp: Exactly.
Gardner: Let’s dig a little more deeply into Apache CXF. Explain what it encompasses. I referred to it earlier as an ESB, but it seems that with this expanding definition set that it might be larger than that.
Kulp: There are definitely a lot of features being added that target a variety of users and use cases that really work into our original definition of what CXF was going to be. If you take a look at that Apache incubation project page, there’s a list of stuff. It was the original design of what this project was going to be. It’s going to have multiple bindings and multiple transports. We do have that, and that’s good. But with our growing list of cool features that developers keep coming up with, we’ve been adding all these multi-deployment capabilities. We’ve been adding a lot of these new WS specs like WS-Addressing and WS-Reliable Messaging.
Some of them weren’t even really anywhere close to final specs when we started the Apache CXF project. It’s a never-ending battle of more ideas coming at us, which is great -- there are no complaints about that. But there’s definitely a lot of work to be done and a lot of new ideas. So, it’s a growing project with a growing list of features.
Gardner: So we’re getting one of those good-news, bad-news things, right? The good news is that we’ve got a lot of people interested, and they want lots of different things. The bad news is that we've got to try to address all those different things.
Kulp: Right, but being open source if we don’t have time to do something and they want to devote some resources to it we definitely welcome that.
Gardner: Who are the primary contributors and innovators within the CXF project? Obviously, we have IONA involved, but are there any others that you can share with us?
Moynihan: We also have Envoi Solutions participating. We have individuals from various Apache projects, like Geronimo, who are also contributing, because they would like to integrate their projects with CXF. At Apache it’s really more the individual versus a particular corporation.
Gardner: There seems to be quite a bit of other ancillary development in terms of Yoko, Tuscany, and ServiceMix that bring a whole other family of contributors into it. Right?
Kulp: Definitely. One of the other neat things about Apache is how many top-level projects they have. It’s in the 30s now, and a lot of the top-level projects have subprojects. So, there’s a lot of various functionality and different projects. One of the things that we’re trying to do from Apache’s success standpoint is reach out to some of those other communities, get involved with them, and help them get involved with CXF. Hopefully, we can work together to figure out the gaps that we have. Maybe we can use some of their technology, and they can use some of the CXF stuff.
That’s one of the fascinating things about Apache. There’s a lot of neat stuff there.
Gardner: Going back to that earlier point about so many choices in the marketplace today, if I am a chief technology officer or enterprise architect and I am moving toward SOA, I am going to be evaluating projects and products and looking at best-of-breed versus suite and so forth. I would want to know the flavor of CXF as an ESB? How does it fit and compare to others? What characterizes this as an ESB? Is this a high-performance or is it a low-latency? What is it designed for?
Kulp: CXF is really designed for high performance, kind of like a request-response style of interaction for one way, asynchronous messaging, and things like that. But it’s really designed for taking data in from a variety of transports and message formats, such as SOAP or just raw XML. If you bring in the Apache Yoko project, we have CORBA objects coming in off the wire. It basically processes them through the system as quickly as possible with very little memory and processing overhead. We can get it to the final destination of where that data is supposed to be, whether it’s off to another service or a user-developed code, whether it’s in JavaScript or JAX-WS/JAXB code.
That’s the goal of what the CXF runtime is -- just get that data into the form that the service needs, no matter where it came from and what format it came from in, and do that as quickly as possible.
Gardner: So, breadth, versatility, high performance -- are these adjectives that we would use here?
Kulp: Oh, definitely, yes.
Gardner: What are some others?
Kulp: Flexibility. The CXF runtime provides a lot of flexibility. We have a lot of interceptor points where core developers, who really know what they're doing, can intercept various points of that message as it’s going through the system to do some partial processing or validation. We have some work in progress to do, like partial message encryption on some of the XML stuff. That’s done via some of these flexibility touch points, where developers can just take a part of the message and say, "Okay, we are going to encrypt this." So, flexibility is another big word that’s important from a developer’s standpoint.
Gardner: So, we have this rich canvas, and we’ve got lots of different oils and paint that we can apply to it and come up with our own unique painting, if you will, for various use-case scenarios. I'm curious as to what vertical, either industries or use-case scenarios, you think that this level of flexibility and versatility is best designed for? Is this something that an ISV will gravitate to? Is this what a software-as-a-service (SaaS) organization should be looking at? If I'm a business applications systems integrator and I'm looking to pull these together in an SOA, what’s the best fit for this as it is evolving in the current incubation process?
Moynihan: Well, we've definitely seen interest from a few different types of developers and other vertical industries. IONA traditionally has had a lot of customers in telecommunications, financial services, and manufacturing. From our engineers' perspective, they bring a lot of those requirements to the project, but we have also seen interest from a lot of different industries. So I wouldn’t say it's specific to a particular industry. From a developer perspective, what’s nice about the technology is that it's really flexible, as Dan said, in that there are multiple programming models that it can apply to. Also, from a deployment perspective, if you are a developer who is implementing it, you can deploy it in a lot of different types of technology.
Whether you like Spring or you are really focused on application servers and have a deep knowledge of JBoss, you can leverage CXF within any of those types of environments. I do think there is a huge opportunity for ISVs to look at this as something that they could include within their products. That’s something that we have seen with Celtix. So definitely that will be interesting. I hope that we see a lot of people joining and providing feedback on the types of requirements we need to continue to develop for that market as well.
Gardner: I suppose the CXF project has the performance characteristics and flexibility that can be taken in a number of directions, and it’s up to the market where they want to take it.
Kulp: Exactly. Obviously the developers who are contributing have a large say in that. But, if a user is going to get more involved, we definitely encourage them to start looking at our mailing list and our Website and start providing extra suggestions of where they think we are deficient or lacking something that they need, and we’ll address it.
Gardner: I suppose that’s another benefit of open source -- you don’t have a big SKU drop to develop to. It’s an ongoing journey, right?
Kulp: Exactly. It’s not big leaps like you have in your commercial versions. They come out every six months with big leaps with them. With open source, if somebody wants to commit something today, they’re obviously able to download the source, build it themselves, and they would have a solution for themselves today. They wouldn’t have to wait two or three months for the commercial vendors to spin the whole release and do all of the stuff that's required for release.
Gardner: For those folks who now have their appetite whetted a little bit and want to learn some more as to why this might be applicable for their needs, can we get into a little bit about what’s technically going on in terms of inclusiveness and adaptation to what’s new and interesting in the market these days? There has been a lot of interest around rich Internet applications (RIAs) and Web 2.0-types of interfaces and applications. Dan, tell us a little bit about what’s going on in that direction.
Kulp: We’ve been working on some new features that we haven’t had in some of the previous generations of IONA’s SOA tool. Some of the main ones we have are the REST integrations. If you are not familiar with the Web 2.0/REST stuff, AJAX is the popular word that actually uses it. It’s a different style of interaction, where you do “gets” to get your XML data. Then it is a little bit processed on the client side, a little bit processed on the server side. There’s a lot of scripting going on in the marketplace today. There are a lot of JavaScript developers working with AJAX or doing other types of JavaScript, even on the server side. So, a lot of what we’ve done with CXF is to give those file developers some new tools to produce applications.
We’ve created a set of REST annotations. If you have existing Java services that you want to expose via REST capabilities, your AJAX clients can talk to them. You can annotate the code with these REST annotations, and CXF will pick up on them and do the REST or the SOAP interactions. We also provide support for writing your SOA applications in JavaScript. JavaScript is one of those neat interpreted things for rapid development, where you avoid some of that compile-repackage-redeploy cycle.
Gardner: It may be the most popular language in the history of development, right?
Kulp: The way the Web is today, maybe, yes. A lot of people out there are familiar with JavaScript. Having that capability built into the product opens up the project to a whole new breed of developers because we are not restricting it, saying, “Okay, you must know Java JDK 1.5 with JAX-WS."
We do support that too -- we’re not discounting that, but we’re not restricting you to that level of development. With the JavaScript capability, it’s a whole new breed of developers that this opens up to. We have some plans in place for adding things like Jython, and JRuby, and other scripting to broaden that and get more of those people in to open up the opportunities for a wider range of developers.
Gardner: How about specifications and standards? Has there been some more adaptation to what’s being asked for? I guess I’m thinking of some of the WS-* types of specs.
Kulp: Definitely. When we first started the Celtix project at ObjectWeb, JAX-WS itself and the Java API for XML Web Services, the JAX-WS 2.0 spec, wasn’t even finalized. Since then it’s been finalized, and there’s another revision coming up shortly that’s in final draft. Then there are a lot of new Web services specs such as WS-Reliable Messaging, WS-Security, WS-Policy. A lot of new specifications have come out in the last year and a half that provide a standard way of doing a lot of the things that we are trying to do in CXF.
CXF is trying to use those standards whenever possible. Right now in Apache CXF we do support JAX-WS and are working on trying to get it to pass the [compliance test]. It doesn’t right now, but it’s definitely a priority. We are supporting WS-Reliable Messaging, WS-Addressing and WS-Policy. We have started some discussions around WS-Context and WS-Transactions. So, there are a lot of Web service specifications that we are keeping our eyes on and following. As they evolve and finalize, we’re basically trying to get them into CXF.
Now, that said, a lot of those specifications that I just mentioned may or may not be finalized. All this Web service stuff evolves on a day-to-day basis, and it’s actually a lot of work to keep track of those. But from a user standpoint the fact that the project’s doing that, instead of the user doing it, is probably a good thing.
Gardner: Is it fair to predict that these things, when they are ready, would find themselves in CXF before they’d find themselves in commercial ESBs?
Kulp: Potentially, yes. With the commercial product there are release cycles of six months or a year, or something like that. A lot of commercial vendors try to figure out what’s going into a particular release six months before it’s even released. So if those Web services specs aren’t finalized six months before release, they may not make that release cycle. In an open-source environment, where you have a constantly evolving development, as soon as these things get finalized, it can be made available almost immediately.
Gardner: I suppose Eclipse is the most popular "belle at the ball" these days, as well as the SOA Tools project that’s going on there. What would be the relationship between what’s going with SOA Tools and Eclipse and the CXF incubation in Apache? How about to you, Debbie?
Moynihan: The SOA Tools project is geared to provide a broad spectrum of tooling based on the Eclipse platform. It provides a lot of different capabilities for building out SOA services and other types of infrastructure as well. Within that project there is a component that consists of tools that work with CXF specifically. Right now we have JAX-WS tooling, and we’ll continue to expand the tooling part of the SOA Tools project to work with the different capabilities that were built out in CXF.
What’s nice about the SOA Tools project is that it has a lot of other capabilities that are integrated -- like orchestration for BPEL, process modeling using the BPMN standard, and things like building up Service Component Architecture (SCA) tooling and other complementary capabilities; as you have talked about earlier, bringing together the best-of-breed.
Gardner: I suppose another thing we need to look at is the relationship between CXF and the IONA commercial products. I'm thinking of Artix and some of your other offerings. For those people listening who are trying to understand that, can you lay out the land in terms of the relationship between these two? What are your business goals by having such a large active role in the CXF project?
Moynihan: We would like to offer what our customers are looking for, and our customers are looking to elaborate the latest standards in open source. They also have some other needs, which are not being developed in open source. So we have a dual-strategy where we are doing open-source development and then also company-developed or commercial development. We look at both the open-source development and the commercial-development. It’s very complementary from an R&D perspective, in that we’d like to leverage the CXF technology within our commercial offerings.
Also we’d like for all of the Artix plug-ins to work with the open-source technology and to interoperate with the Artix runtime. From a development perspective, we may choose over time to move some of those capabilities into open source. We develop everything so that it can be moved into open source, if and when we decide that it makes sense.
Kulp: This comes back a lot to the flexible nature of the Apache CXF project. One of the design goals of Apache CXF, as I mentioned earlier, was to provide a lot of touch points for plugging in new functionality or to extend the system to customize a little bit. Part of what IONA is doing is using some of those touch points to provide more unique solutions for IONA-specific problems or problems that the IONA customers have been dealing with. The flexibility of Apache CXF provides a lot of capabilities to do that.
Gardner: Okay, who should be interested in CXF in terms of a deploying organization? We talked a little bit about the use-case scenarios. How do you get started, and whom would the people be to do that -- I guess a champion or a maven? Who is the decision-maker that this needs to be appealing to? And then how would those people start taking advantage of what CXF is offering?
Moynihan: What’s nice about CXF is it's small, flexible, and can be consumed in a lot of different ways. Individual developers can actually be the champions, and you see it accepted in their projects. So one group of key users would be corporate developers, people who are working within businesses and building applications and want to service-enable those. On the other end of the platform are people who want to receive and connect with those services.
If you have an application, you want to connect with these new services that are being created and that consume services. Also there are a lot of system integration firms out there who do this type of work.
Those will be the big ones. Then over time you may see more adoption of a particular standard across the organization as people learn about the flexibility and high-performance of the CXF project.
Gardner: To you, Dan ... I suppose if you are downloading an open-source component as a developer, you might be used to things a little less daunting or substantial as an ESB. Or am I reading this wrong? Perhaps there is a perception out there that needs to be adjusted, that it’s okay for me as an individual developer to download an ESB? Do you expect that to be the case? Or is this more of a larger architectural undertaking?
Kulp: It’s definitely good to be able to have a developer download it and get their hands wet immediately. Apache CXF does provide a lot of getting-started-type samples that walk you through the first steps of getting up and running as quickly as possible.
We try to provide a lot of capabilities for developers to get started very quickly with something that's simple, but at least get them started, and then from there to grow their capabilities slowly, and get them more into the advanced features. But you have to start small, and we’re trying to provide samples that will help you do that.
Gardner: That might be something that’s in the best interest of developers for their career. We're certainly seeing a lot of interest in SOA. One of the big question marks in looking at the landscape for SOA is whether there’ll be sufficient manpower or human resources for moving into the role of a SOA architect. One of the best trajectories toward that is from the developer perspective. They might have to learn a lot about a specific business, a domain, and the ins-and-outs of what’s going on in that business. But I would imagine that there are some significant career opportunities for folks who were able to take the developer role, embrace understanding of such products as CXF, and then take that into a business. Do you have any feedback on that in terms of the human resources potential?
Kulp: As in almost all cases, the more you learn, the more potential you have. So, if you can dig into various products and learn more capabilities -- with CXF supporting a bunch of the new Web services standards -- it does give you the opportunity to start using JAX-WS, WS-Addressing, WS-Reliable Messaging, and REST -- all these neat buzz words that you hear on a day-to-day basis.
For developers that aren’t familiar with these things, it does give an opportunity to learn about them and use them in something that’s relatively easy. Expanding their knowledge is always a good thing from a career perspective. The more you know, the better off you are.
Gardner: It's hard to argue with that. Well, we’ve had a good discussion on the Apache Incubator CXF project, an open-source ESB. We have been talking with two representatives from IONA technologies, Dan Kulp, principal engineer, and Debbie Moynihan, director of open-source programs.
You've been listening to a BriefingsDirect sponsored podcast. I'm your moderator and host, Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening.
Listen to the podcast here.
Podcast sponsor: IONA Technologies.
Transcript of Dana Gardner’s BriefingsDirect podcast on SOA and open source community development. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Listen to the podcast here.
Dana Gardner: Hello, this is Dana Gardner, principal analyst at Interarbor Solutions and you are listening to a sponsored BriefingsDirect podcast. Today, a discussion about Services Oriented Architecture (SOA) and open-source software -- how incubation projects and the development of community-based code are a big part of the ongoing maturation of SOA. We’re specifically going to be discussing the incubation Apache CXF project. And here to help us profile and understand this project, its goals and its implications are two representatives from IONA Technologies.
First, we have Dan Kulp. Dan is a principal engineer at IONA Technologies, and he’s been concentrating on Java and Web services technologies. He is also a community lead for IONA’s open-source initiatives, and is furthermore a committer on the Maven Project for plug-ins, Apache Tuscany and Apache Yoko projects.
Also joining us is Debbie Moynihan, the director of open source programs at IONA. I want to welcome both Dan and Debbie.
Debbie Moynihan: Thank you, Dana.
Dan Kulp: Thank you.
Gardner: As we mentioned, there’s an interesting -- and perhaps unprecedented -- intersection between the maturation of SOA as a concept, a philosophy and an approach to computing, and also the role of open source in community-based development. Many times in the past, we’ve seen the commercial development of products that are spun off into open-source projects of a similar nature. But with SOA it seems that things are different. We’ve got a fairly wide variety of projects happening simultaneously as many of the commercial vendors are also putting together products, approaches, frameworks, standards and specifications to help companies develop and manage SOA.
So tell us a little bit about the playing field for open source and SOA, and particularly CXF, which is an ESB project. First let me go to Dan. We’ve seen a variety of different products out there. Why do you think it is that SOA is different from the past, and why do we have so many open source projects simultaneous with commercial products?
Kulp: The open source projects are providing a unique opportunity for developers to get their hands dirty and learn a little bit about the field, as well as contribute back some of their ideas in a form that is very healthy for new technologies like SOA. With SOA being very new, there are a lot of ideas flying around, and people are coming up with new ideas and technologies just about every day. The open-source communities that are popping up are very good places to foster those ideas and solidify them into something that’s maybe not just usable by that particular developer’s applications, but also across a wide variety of customer- and user-driven problems.
Gardner: We’re also seeing a combination of best-of-breed, more discreet components standing on their own for SOA activities, as well as more of an integrated stack or suite approach by many vendors. At the same time, we’re seeing open source and commercial. So, there’s a real mixture, a hodgepodge of code, component and infrastructure for those that are evaluating and working toward SOA. Why is that? Is it that SOA is, by definition, more of a componentized undertaking? I’ll throw this out to either Debbie or Dan.
Kulp: It definitely is. If you look at the goals of SOA, you may have some older legacy systems that you want to expose into your SOA, so that newer applications or newer development efforts can talk to those, but you also have all this new stuff that’s popping up. You have all these brand new AJAX applications and other applications that basically present a whole new set of challenges, a whole new set of connectivity options -- just a lot of technologies to connect all these things.
That’s why you see a bunch of these stacks producing different types of connectivity options. Obviously, a lot of commercial vendors are creating large stacks that are designed to target their customers with things that they have supported in the past, and obviously they have to bring their customers up to the newer technologies. When you look toward the open-source stuff, it’s more about connecting newer systems and newer technologies that are really hot and sexy today.
Gardner: So, a little bit of the old and the new -- the more the merrier.
Kulp: Exactly.
Gardner: I suppose that the good news is that it’s "the more the merrier," and there are lots of options, but I think for some people who are traditional IT folks that that many options and that much choice can be daunting and confusing. How do we look at the current landscape of best-of-breed and suites of open-source and commercial and make some sense of that?
Moynihan: Well, one of the things we're trying to do at IONA is help users with the best-of-breed SOA infrastructure technologies that are out there in open source, and to integrate those together in a certified and tested package. This makes it easier for them to leverage multiple projects together. Because there are quite a few best-of-breed approaches and there are a lot of different options. The other thing is that certain communities seem to attract SOA types of technologies, and we participate in each of those -- Apache, Eclipse Foundation, ObjectWeb, to name three of them -- and that’s a good place for people to start. I think with SOA also there are a lot of loosely coupled components, and that actually lends itself well to best-of-breed, and it allows multiple vendors to participate, with each providing what they're really good at.
Gardner: Maybe we should point out here that CXF has a certain legacy and heritage that is close to IONA. Why don’t we briefly give an overview, Debbie maybe from you, on the lineage and history of CXF?
Moynihan: Sure, about a year and a half ago IONA made a proactive decision to initiate the creation of an open-source project called Celtix in the ObjectWeb community to focus on building an open-source ESB. We got that to the first milestone and got a really good foundation. It was following along the same architectural path as IONA’s other offerings, a lightweight, standards-based approach, allowing you to lay on top of any technology that you already have in place, rather than taking a stack type of approach. At one point we wanted to grow the community. We had a lot of interest from other projects in the Apache community. And there was another project called XFire, with which we had a lot of synergies and shared goals.
That led to some discussions, and we eventually made the decision to merge XFire with Celtix and moved them over to the Apache community. We thought it made sense to start a new community with the merged project, and that evolved into CXF. Dan can go into a lot more detail about where we are with the CXF project, but we’ve taken what we had with Celtix and XFire and brought the best of both of those together. And we continue to make a lot of progress there.
Gardner: One thing I want to understand is why open source is a strong approach for the development of certain products, in this case SOA-type products. As I said, I looked at the incubator page for CXF and I see the goals are, "support for standards," "multiple transports," "bindings," "data bindings," "formats," "flexible deployment," and "support for multiple programming languages."
It seems as if, by nature, an open-source approach to SOA has advantages. A commercial vendor and private-code vendor might have some of these goals as well, but they are also going to be mindful of their heritage and their legacy. Is there, from an open-source community level, an advantage to developing an ESB, for example, in a more inclusive way -- to create an ecology, to create a community, where people will contribute? And let me throw that out to Dan.
Kulp: Oh, definitely. There’s a lot of functionality that ends up in a lot of open-source projects that really wasn’t a priority -- or even sometimes a consideration -- when those projects where originally created by the various vendors that push to get these projects started. One of the things about closed-source projects is anything that’s really developed is specific to that vendor’s customers. If their customers have various requirements, that’s what gets developed. They're trying to get new customers. That’s always a goal. But if one of their customer says, “Hey, I need this now,” a lot of other things don’t get developed.
Whereas one of the goals of an open-source community is to bring new developers in. And a lot of times those new developers have different priorities or different ideas of what an ESB should do. They can provide a lot of expertise and new and fresh ideas that can make the open-source project a bit different than closed source, and provide some unique features.
Gardner: I suppose one of the tricky parts about any private source or closed source or commercial development and requirements phases is where we draw the line. We’ve got a deadline to meet, there are only certain things we can do within that timeframe, and those are going to be dependent upon our business goals. That’s fine -- there's nothing wrong with that. But it’s a different beast when you’re developing your requirements within an open-source ecology of contributors.
Kulp: Definitely. One of the most fascinating things about the open-source community is something may not be my number-one requirement. But if it’s one of the other developer's number-one requirements, they’re more than welcome to work on it and get it done. So in my mind it would have slipped. But in his mind it would have gotten done. It’s a fascinating environment.
Gardner: I suppose it’s also a two-way street. If there’s an ecology that contributors can bring into these definitions and capabilities, they can have many more integration points, many more approaches of how this relates to different implementations in the field. That’s one direction. The other direction is that developers can say, "Listen, we want to be able to work with what this project produces -- and we happen to be of a certain flavor of development" ... like, "I am a Spring developer" or "I am a J2EE developer."
Tell us a little bit about why this makes sense for developers. They can set this project up so that they can better take advantage of what it does, right?
Kulp: Right. You bring up a good example with the Spring stuff that you just mentioned. Originally, when we were doing a lot of the Celtix stuff, we were still in ObjectWeb, and Spring wasn’t really one of our priorities. From IONA’s standpoint, it’s not something that we’ve really experienced much with our customers. But as part of the merge with XFire, that user base was a little different than the Celtix user base.
Priorities got shifted, and we started developing more flexible models for deployment that allow the use of Spring, if you’re a Spring person. If you’re not a Spring developer, we have other options that are available to deploy your applications in a very different format. That provides a lot of flexibility when you get that broad community throwing ideas out there.
Gardner: I suppose that many times, from a commercial perspective, you’ll get the vendor saying, "Here are the tools we’re going to use."
Kulp: Exactly.
Gardner: Let’s dig a little more deeply into Apache CXF. Explain what it encompasses. I referred to it earlier as an ESB, but it seems that with this expanding definition set that it might be larger than that.
Kulp: There are definitely a lot of features being added that target a variety of users and use cases that really work into our original definition of what CXF was going to be. If you take a look at that Apache incubation project page, there’s a list of stuff. It was the original design of what this project was going to be. It’s going to have multiple bindings and multiple transports. We do have that, and that’s good. But with our growing list of cool features that developers keep coming up with, we’ve been adding all these multi-deployment capabilities. We’ve been adding a lot of these new WS specs like WS-Addressing and WS-Reliable Messaging.
Some of them weren’t even really anywhere close to final specs when we started the Apache CXF project. It’s a never-ending battle of more ideas coming at us, which is great -- there are no complaints about that. But there’s definitely a lot of work to be done and a lot of new ideas. So, it’s a growing project with a growing list of features.
Gardner: So we’re getting one of those good-news, bad-news things, right? The good news is that we’ve got a lot of people interested, and they want lots of different things. The bad news is that we've got to try to address all those different things.
Kulp: Right, but being open source if we don’t have time to do something and they want to devote some resources to it we definitely welcome that.
Gardner: Who are the primary contributors and innovators within the CXF project? Obviously, we have IONA involved, but are there any others that you can share with us?
Moynihan: We also have Envoi Solutions participating. We have individuals from various Apache projects, like Geronimo, who are also contributing, because they would like to integrate their projects with CXF. At Apache it’s really more the individual versus a particular corporation.
Gardner: There seems to be quite a bit of other ancillary development in terms of Yoko, Tuscany, and ServiceMix that bring a whole other family of contributors into it. Right?
Kulp: Definitely. One of the other neat things about Apache is how many top-level projects they have. It’s in the 30s now, and a lot of the top-level projects have subprojects. So, there’s a lot of various functionality and different projects. One of the things that we’re trying to do from Apache’s success standpoint is reach out to some of those other communities, get involved with them, and help them get involved with CXF. Hopefully, we can work together to figure out the gaps that we have. Maybe we can use some of their technology, and they can use some of the CXF stuff.
That’s one of the fascinating things about Apache. There’s a lot of neat stuff there.
Gardner: Going back to that earlier point about so many choices in the marketplace today, if I am a chief technology officer or enterprise architect and I am moving toward SOA, I am going to be evaluating projects and products and looking at best-of-breed versus suite and so forth. I would want to know the flavor of CXF as an ESB? How does it fit and compare to others? What characterizes this as an ESB? Is this a high-performance or is it a low-latency? What is it designed for?
Kulp: CXF is really designed for high performance, kind of like a request-response style of interaction for one way, asynchronous messaging, and things like that. But it’s really designed for taking data in from a variety of transports and message formats, such as SOAP or just raw XML. If you bring in the Apache Yoko project, we have CORBA objects coming in off the wire. It basically processes them through the system as quickly as possible with very little memory and processing overhead. We can get it to the final destination of where that data is supposed to be, whether it’s off to another service or a user-developed code, whether it’s in JavaScript or JAX-WS/JAXB code.
That’s the goal of what the CXF runtime is -- just get that data into the form that the service needs, no matter where it came from and what format it came from in, and do that as quickly as possible.
Gardner: So, breadth, versatility, high performance -- are these adjectives that we would use here?
Kulp: Oh, definitely, yes.
Gardner: What are some others?
Kulp: Flexibility. The CXF runtime provides a lot of flexibility. We have a lot of interceptor points where core developers, who really know what they're doing, can intercept various points of that message as it’s going through the system to do some partial processing or validation. We have some work in progress to do, like partial message encryption on some of the XML stuff. That’s done via some of these flexibility touch points, where developers can just take a part of the message and say, "Okay, we are going to encrypt this." So, flexibility is another big word that’s important from a developer’s standpoint.
Gardner: So, we have this rich canvas, and we’ve got lots of different oils and paint that we can apply to it and come up with our own unique painting, if you will, for various use-case scenarios. I'm curious as to what vertical, either industries or use-case scenarios, you think that this level of flexibility and versatility is best designed for? Is this something that an ISV will gravitate to? Is this what a software-as-a-service (SaaS) organization should be looking at? If I'm a business applications systems integrator and I'm looking to pull these together in an SOA, what’s the best fit for this as it is evolving in the current incubation process?
Moynihan: Well, we've definitely seen interest from a few different types of developers and other vertical industries. IONA traditionally has had a lot of customers in telecommunications, financial services, and manufacturing. From our engineers' perspective, they bring a lot of those requirements to the project, but we have also seen interest from a lot of different industries. So I wouldn’t say it's specific to a particular industry. From a developer perspective, what’s nice about the technology is that it's really flexible, as Dan said, in that there are multiple programming models that it can apply to. Also, from a deployment perspective, if you are a developer who is implementing it, you can deploy it in a lot of different types of technology.
Whether you like Spring or you are really focused on application servers and have a deep knowledge of JBoss, you can leverage CXF within any of those types of environments. I do think there is a huge opportunity for ISVs to look at this as something that they could include within their products. That’s something that we have seen with Celtix. So definitely that will be interesting. I hope that we see a lot of people joining and providing feedback on the types of requirements we need to continue to develop for that market as well.
Gardner: I suppose the CXF project has the performance characteristics and flexibility that can be taken in a number of directions, and it’s up to the market where they want to take it.
Kulp: Exactly. Obviously the developers who are contributing have a large say in that. But, if a user is going to get more involved, we definitely encourage them to start looking at our mailing list and our Website and start providing extra suggestions of where they think we are deficient or lacking something that they need, and we’ll address it.
Gardner: I suppose that’s another benefit of open source -- you don’t have a big SKU drop to develop to. It’s an ongoing journey, right?
Kulp: Exactly. It’s not big leaps like you have in your commercial versions. They come out every six months with big leaps with them. With open source, if somebody wants to commit something today, they’re obviously able to download the source, build it themselves, and they would have a solution for themselves today. They wouldn’t have to wait two or three months for the commercial vendors to spin the whole release and do all of the stuff that's required for release.
Gardner: For those folks who now have their appetite whetted a little bit and want to learn some more as to why this might be applicable for their needs, can we get into a little bit about what’s technically going on in terms of inclusiveness and adaptation to what’s new and interesting in the market these days? There has been a lot of interest around rich Internet applications (RIAs) and Web 2.0-types of interfaces and applications. Dan, tell us a little bit about what’s going on in that direction.
Kulp: We’ve been working on some new features that we haven’t had in some of the previous generations of IONA’s SOA tool. Some of the main ones we have are the REST integrations. If you are not familiar with the Web 2.0/REST stuff, AJAX is the popular word that actually uses it. It’s a different style of interaction, where you do “gets” to get your XML data. Then it is a little bit processed on the client side, a little bit processed on the server side. There’s a lot of scripting going on in the marketplace today. There are a lot of JavaScript developers working with AJAX or doing other types of JavaScript, even on the server side. So, a lot of what we’ve done with CXF is to give those file developers some new tools to produce applications.
We’ve created a set of REST annotations. If you have existing Java services that you want to expose via REST capabilities, your AJAX clients can talk to them. You can annotate the code with these REST annotations, and CXF will pick up on them and do the REST or the SOAP interactions. We also provide support for writing your SOA applications in JavaScript. JavaScript is one of those neat interpreted things for rapid development, where you avoid some of that compile-repackage-redeploy cycle.
Gardner: It may be the most popular language in the history of development, right?
Kulp: The way the Web is today, maybe, yes. A lot of people out there are familiar with JavaScript. Having that capability built into the product opens up the project to a whole new breed of developers because we are not restricting it, saying, “Okay, you must know Java JDK 1.5 with JAX-WS."
We do support that too -- we’re not discounting that, but we’re not restricting you to that level of development. With the JavaScript capability, it’s a whole new breed of developers that this opens up to. We have some plans in place for adding things like Jython, and JRuby, and other scripting to broaden that and get more of those people in to open up the opportunities for a wider range of developers.
Gardner: How about specifications and standards? Has there been some more adaptation to what’s being asked for? I guess I’m thinking of some of the WS-* types of specs.
Kulp: Definitely. When we first started the Celtix project at ObjectWeb, JAX-WS itself and the Java API for XML Web Services, the JAX-WS 2.0 spec, wasn’t even finalized. Since then it’s been finalized, and there’s another revision coming up shortly that’s in final draft. Then there are a lot of new Web services specs such as WS-Reliable Messaging, WS-Security, WS-Policy. A lot of new specifications have come out in the last year and a half that provide a standard way of doing a lot of the things that we are trying to do in CXF.
CXF is trying to use those standards whenever possible. Right now in Apache CXF we do support JAX-WS and are working on trying to get it to pass the [compliance test]. It doesn’t right now, but it’s definitely a priority. We are supporting WS-Reliable Messaging, WS-Addressing and WS-Policy. We have started some discussions around WS-Context and WS-Transactions. So, there are a lot of Web service specifications that we are keeping our eyes on and following. As they evolve and finalize, we’re basically trying to get them into CXF.
Now, that said, a lot of those specifications that I just mentioned may or may not be finalized. All this Web service stuff evolves on a day-to-day basis, and it’s actually a lot of work to keep track of those. But from a user standpoint the fact that the project’s doing that, instead of the user doing it, is probably a good thing.
Gardner: Is it fair to predict that these things, when they are ready, would find themselves in CXF before they’d find themselves in commercial ESBs?
Kulp: Potentially, yes. With the commercial product there are release cycles of six months or a year, or something like that. A lot of commercial vendors try to figure out what’s going into a particular release six months before it’s even released. So if those Web services specs aren’t finalized six months before release, they may not make that release cycle. In an open-source environment, where you have a constantly evolving development, as soon as these things get finalized, it can be made available almost immediately.
Gardner: I suppose Eclipse is the most popular "belle at the ball" these days, as well as the SOA Tools project that’s going on there. What would be the relationship between what’s going with SOA Tools and Eclipse and the CXF incubation in Apache? How about to you, Debbie?
Moynihan: The SOA Tools project is geared to provide a broad spectrum of tooling based on the Eclipse platform. It provides a lot of different capabilities for building out SOA services and other types of infrastructure as well. Within that project there is a component that consists of tools that work with CXF specifically. Right now we have JAX-WS tooling, and we’ll continue to expand the tooling part of the SOA Tools project to work with the different capabilities that were built out in CXF.
What’s nice about the SOA Tools project is that it has a lot of other capabilities that are integrated -- like orchestration for BPEL, process modeling using the BPMN standard, and things like building up Service Component Architecture (SCA) tooling and other complementary capabilities; as you have talked about earlier, bringing together the best-of-breed.
Gardner: I suppose another thing we need to look at is the relationship between CXF and the IONA commercial products. I'm thinking of Artix and some of your other offerings. For those people listening who are trying to understand that, can you lay out the land in terms of the relationship between these two? What are your business goals by having such a large active role in the CXF project?
Moynihan: We would like to offer what our customers are looking for, and our customers are looking to elaborate the latest standards in open source. They also have some other needs, which are not being developed in open source. So we have a dual-strategy where we are doing open-source development and then also company-developed or commercial development. We look at both the open-source development and the commercial-development. It’s very complementary from an R&D perspective, in that we’d like to leverage the CXF technology within our commercial offerings.
Also we’d like for all of the Artix plug-ins to work with the open-source technology and to interoperate with the Artix runtime. From a development perspective, we may choose over time to move some of those capabilities into open source. We develop everything so that it can be moved into open source, if and when we decide that it makes sense.
Kulp: This comes back a lot to the flexible nature of the Apache CXF project. One of the design goals of Apache CXF, as I mentioned earlier, was to provide a lot of touch points for plugging in new functionality or to extend the system to customize a little bit. Part of what IONA is doing is using some of those touch points to provide more unique solutions for IONA-specific problems or problems that the IONA customers have been dealing with. The flexibility of Apache CXF provides a lot of capabilities to do that.
Gardner: Okay, who should be interested in CXF in terms of a deploying organization? We talked a little bit about the use-case scenarios. How do you get started, and whom would the people be to do that -- I guess a champion or a maven? Who is the decision-maker that this needs to be appealing to? And then how would those people start taking advantage of what CXF is offering?
Moynihan: What’s nice about CXF is it's small, flexible, and can be consumed in a lot of different ways. Individual developers can actually be the champions, and you see it accepted in their projects. So one group of key users would be corporate developers, people who are working within businesses and building applications and want to service-enable those. On the other end of the platform are people who want to receive and connect with those services.
If you have an application, you want to connect with these new services that are being created and that consume services. Also there are a lot of system integration firms out there who do this type of work.
Those will be the big ones. Then over time you may see more adoption of a particular standard across the organization as people learn about the flexibility and high-performance of the CXF project.
Gardner: To you, Dan ... I suppose if you are downloading an open-source component as a developer, you might be used to things a little less daunting or substantial as an ESB. Or am I reading this wrong? Perhaps there is a perception out there that needs to be adjusted, that it’s okay for me as an individual developer to download an ESB? Do you expect that to be the case? Or is this more of a larger architectural undertaking?
Kulp: It’s definitely good to be able to have a developer download it and get their hands wet immediately. Apache CXF does provide a lot of getting-started-type samples that walk you through the first steps of getting up and running as quickly as possible.
We try to provide a lot of capabilities for developers to get started very quickly with something that's simple, but at least get them started, and then from there to grow their capabilities slowly, and get them more into the advanced features. But you have to start small, and we’re trying to provide samples that will help you do that.
Gardner: That might be something that’s in the best interest of developers for their career. We're certainly seeing a lot of interest in SOA. One of the big question marks in looking at the landscape for SOA is whether there’ll be sufficient manpower or human resources for moving into the role of a SOA architect. One of the best trajectories toward that is from the developer perspective. They might have to learn a lot about a specific business, a domain, and the ins-and-outs of what’s going on in that business. But I would imagine that there are some significant career opportunities for folks who were able to take the developer role, embrace understanding of such products as CXF, and then take that into a business. Do you have any feedback on that in terms of the human resources potential?
Kulp: As in almost all cases, the more you learn, the more potential you have. So, if you can dig into various products and learn more capabilities -- with CXF supporting a bunch of the new Web services standards -- it does give you the opportunity to start using JAX-WS, WS-Addressing, WS-Reliable Messaging, and REST -- all these neat buzz words that you hear on a day-to-day basis.
For developers that aren’t familiar with these things, it does give an opportunity to learn about them and use them in something that’s relatively easy. Expanding their knowledge is always a good thing from a career perspective. The more you know, the better off you are.
Gardner: It's hard to argue with that. Well, we’ve had a good discussion on the Apache Incubator CXF project, an open-source ESB. We have been talking with two representatives from IONA technologies, Dan Kulp, principal engineer, and Debbie Moynihan, director of open-source programs.
You've been listening to a BriefingsDirect sponsored podcast. I'm your moderator and host, Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening.
Listen to the podcast here.
Podcast sponsor: IONA Technologies.
Transcript of Dana Gardner’s BriefingsDirect podcast on SOA and open source community development. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Subscribe to:
Posts (Atom)
