Edited transcript of BriefingsDirect[TM/SM] podcast with Dana Gardner, recorded April 3, 2007. Podcast sponsor: Borland Software.
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 sponsored podcast discussion about the development of software as a managed business process, about seeking to gain more insight, more data and metrics, and more overall visibility into application development -- regardless of the parts, the components, the platforms, or the legacy. It’s really about gaining an operational integrity view of development, from requirements through production, and bringing it all into a managed process.
To help us through this discussion of Application Lifecycle Management (ALM) and the future of ALM, we have with us Carey Schwaber, a senior analyst at Forrester Research. Welcome to the show, Carey.
Carey Schwaber: Thank you.
Gardner: We're also going to be talking with Brian Kilcourse. He is the CEO of the Retail Systems Alert Group, and a former senior vice-president and CIO of Longs Drug Stores. Thanks for joining, Brian.
Brian Kilcourse: Thanks, Dana.
Gardner: Also joining us, an executive from Borland Software, Marc Brown. He is the vice president of product marketing. Welcome, Marc.
Marc Brown: How are you?
Gardner: Doing well, thanks. We want to talk about the "professionalism" of development. Some people have defined software development as an art or a science -- sometimes even a dark art. And to me that means a lack of visibility and understanding. Many times the business side of the house in an organization that’s doing software is a little perplexed by the process. They see what goes in as requirements, and then they see what comes out. But they often don’t understand what takes place in between.
I want to start off with you, Marc. Tell us a little bit about ALM as a concept and what Borland Software, in particular, has been doing in terms of evolving this from mystery into clarity?
Brown: Dana, that’s a great question. What Borland has been doing over the last several years is really focusing on how to help organizations transform software delivery or software development into a more managed business process. We think this is critical. If you look at most businesses today, IT organizations are expected to have very managed processes for their supply-chain systems and for their human resources systems, but when it comes to software delivery or software development, as you mentioned, there is this sense that software is some sort of an art.
We would really like to demystify this and put some rigor to the process that individuals and organizations leverage and use around software delivery. This will allow organizations to get the same predictability when they are doing software as when they are doing the other aspects of the IT organization. So our focus is really about helping organizations improve the way they do software, leveraging some core solution areas and processes -- but also providing more holistic insight of what’s going on inside of the application lifecycle.
Gardner: In January of 2007, you came out with a new take on ALM. You call it "Open ALM." I am assuming that that is opposed to "closed." What is it that’s different about Open ALM from what folks may have been used to?
Brown: Well, getting back to helping organizations with software development, it's Borland’s assertion that we need to do it in the context of how organizations themselves have developed or invested their own technology stack over time. So for us the way that we can help organizations apply more management and process-rigor to the application lifecycle is to give them insight into what’s going on. We do that through providing metrics and measurements, but in the context of their technologies, their processes, and their platforms. That is versus proposing a new solution that causes them to do a rip-and-replace across each of the vertical slices of the software development lifecycle.
Gardner: It sounds like an attempt to give the developers what they want, which is more choice over tools, new technologies -- perhaps even open-source technologies. And at the same time you give the business more visibility into the ongoing production and refinement of software. Is that a fair characterization?
Brown: It sure is. What we are all about with Open ALM is providing a platform that provides the practitioners of ALM the tools, processes, and choices they need or are skilled in, and then provide the transparency across that lifecycle to be able to collect the metrics necessary for the management team to actually manage those resources more predictably.
Gardner: Okay. My sense is that there are more options for companies when it comes to the tools and the utilities that they bring into the software development process. Let’s take a look at the state of the art of ALM. Carey Schwaber, can you give us a bit of an overview about ALM? And am I correct in assuming that there are more parts and therefore the potential for more complexity?
Schwaber: You're right. There certainly are. ALM isn't just about developers. It’s really about all the roles that come together to ensure that software meets business requirements -- from business analyst, to the architect, to the developer, to the project manager, the tester.
It just goes on and on. And it feels like every year we end up with more specialized development teams than we had the year before. Specialization is great, because it means that we have more skilled people doing jobs, but it also means that we have more functional silos. ALM is really about making sure that every one of those silos is united, that people really are marching toward the same goal -- to the same drumbeat. ALM is about helping them do that by coordinating all of their efforts.
Gardner: Are there some mega trends going on? It seems to me that offshoring, globalization, outsourcing, and business process management (BPM) add yet another layer of complexity.
Schwaber: There aren't many trends that you can’t tie back to a greater need for ALM, where we have so many things going on that are increasing the degree to which our software is componentized. SOA is just one way in which our software is more componentized. Dynamic applications are also leading toward more componentized software, and that really means that we have more pieces to manage.
So in addition to functional silos, we've also got technology silos where we have a front-end in .NET, a back-end in Java, and maybe we're using a BPM tool to create the entire composite application. There are just so many ways that this gets more and more complex. Then, in addition to managing roles, you also have to manage all of these different components and their interdependencies.
Gardner: A major component of ALM is managing complexity. You came out with a report in August of 2006 that coined the term "ALM 2.O." What did you mean by that?
Schwaber: That’s actually about something that we see as a shift in the ALM marketplace. In the past, vendors have collected ALM solutions over time by acquiring support for each role. They’d acquire a tool that supported business analysts in the work that they do. Then, they’d acquire a tool that supported testers or test leads and the work that they do. They’d integrate the two, but that integration never ended up being very good. That integration is where ALM comes in. ALM lives in coordinating the work that the tester, the business analyst, and all the other roles involved really accomplish, to make sure that software meets business needs.
What we have seen is a trend where vendors are stopping the accumulation of piece-parts of ALM solutions, and starting to design platforms for ALM that really integrate any tool that the company happens to be using with something over the platform that provides ALM almost as a service to the tools. People have the option of choosing a tool for their business analysts from one vendor, a development environment from another vendor, and a testing tool from a third vendor. They are plugging into the same ALM platform, knowing that they'll all work together to ensure that those roles are in harmony -- even if the vendors that produced the tools that support them are not in harmony.
Gardner: So even if we take a platform approach to ALM, it sounds like what you are saying is that heterogeneity -- when it comes to the moving parts of application and software development -- is no longer necessarily a liability, but if managed properly, can become an asset.
Schwaber: That is definitely one of the goals of ALM 2.0, to assume that integrating lots of different functional silos shouldn’t require that we go to a single vendor, because that’s not always possible. There may be a best-of-breed tool in a certain area that happens to be from a vendor that doesn’t have great support for the rest of the lifecycle. So the vision with ALM 2.0 is that you shouldn’t have to make that trade-off. You should be able to choose best-of-breed and integration.
Gardner: I assume then that this also affects people, IT, and process. How would an enterprise that buys into this vision get started? Do you have to attack this from all angles, or is there a more pragmatic starting point?
Schwaber: Hopefully the vendors will make it easy on you and you won’t have to buy everything in one fell swoop. The whole idea is that if you purchase one tool from a vendor that has an ALM 2.0 platform, the platform essentially comes with that. Any tools that happen to plug in to that are ones that also enable better and more flexible ALM, where the platform provides services like workflow, collaboration, reporting, and analytics. Maybe even some more infrastructure things like identity management or licensing could be in the platform, and those would be available to any tools that wanted to consume them and were designed to consume them.
Gardner: Let’s go to Brian Kilcourse. Brian, you have been in the field as a CIO. Is ALM 2.0 vision-creep or is this real-world, in terms of how you want to approach software development?
Kilcourse: It sounds very real-world to me. As most CIOs have done, I spent untold amounts of money trying to turn the software development process from an artistic activity to an engineering activity. There were a bunch of good reasons for that. One of them is that commercial computing is now over 60 years old. And one would think, at this point, that we would have figured out a way to commoditize it and make it more reliable.
But it still remains, even after this long period of time, that software development is easily the most unreliable part of the whole value delivery equation that the IT department brings to the organization. So in broad-brush strokes, it makes great sense. The other thing that is important to underline, as Carey already mentioned, is that people like me have already spent a lot of money on tools. And just because there’s a new and better definition of how to approach those tools doesn’t mean that I am going to throw everything away.
Organizations that had quite a bit of time to get these tools embedded into their practices may have silos of expertise that aren’t going to be easily displaced. All of these things argue against stopping your business while you figure out a better way to develop software. What is important is that we desperately need a way to be able to track a development from the initial conception of the requirements, all the way through to delivery, production, and beyond.
There has to be a way to do that, and it has to be an overarching process that we can observe, measure, and report on. To that end it requires that all of these tools, whatever they are, be kept in sync, so that we can understand it and we can make it evident to the business -- so that the business can know that they are getting the right value for the right dollars. That’s always one of the biggest challenges that any CIO has -- how to show value.
Gardner: I suppose there’s been a kind of tension between sufficient openness and sufficient integration, and that they play off of one another. Is there anything about the state of the art now, where reaching this balance between sufficient openness and the ability to integrate and manage, comes into some sort of a harmonic convergence? Is there anything different about ALM today?
Kilcourse: The fact that we are talking about ALM 2.0 is a big step in the right direction. In our business applications we need to be able to integrate at the information level and the data level, even if they are different code sets or physically different databases. From the business perspective we need to come up with one coherent answer to any kind of a business question. No matter what the toolsets are, we have one way to see them from a business perspective. I think that’s very encouraging.
We know from our business application stack that this is possible. So if it’s possible for the business, why isn’t it possible for the IT organization? You can call this a "cobbler’s children" problem. Why don’t we have for ourselves what we promise to deliver to our business associates?
Gardner: Let’s take that back to Marc Brown at Borland. I assume that your goals with Open ALM are similar to the goals envisioned in ALM 2.0, and that you want to help CIOs get that visibility to demonstrate value. Do you see something new and different in the marketplace now about reaching this balance between openness and integration?
Brown: You know, I do. To extend what we were just talking about, one of the core differences that organizations are talking about today versus 10 years ago is that in the past we talked a lot about making sure we had optimized role-based solutions. We talked a lot about supporting specific activities and specific roles in a lifecycle. What we are finding today when we talk about application lifecycle, and I think Carey brought this up, the real critical piece is understanding the core processes that drive the overall lifecycle activities and assets between the individuals that make up a software delivery team.
So for Borland one of the unique aspects in the way we are approaching this is that we are really focused on the process-driven integration from a technology perspective. We're really looking at the individual processes, such as portfolio and project management, where requirements definition management, understanding those processes, bringing the technologies to bear to support those processes, and providing the integrations between those individuals supports the horizontal software processes.
The other aspect is understanding that we need to do this, not just in a constrained set of tools that Borland brings to market, but also in the context of the tools that customers want to use and leverage. That means Borland technologies, other third-party technologies, and open-source technologies.
Gardner: I suppose one of the hurdles to getting this visibility in the past was that a lot of these components, tools, and testing environments have very different technologies and formats for how they apply and transfer data. What is it that Borland has done with Open ALM to allow the majority of these parts to work together? Is this about building modules and components? What does it take to get these things to actually be herded, if you can use the analogy of trying to herd cats?
Brown: The starting point is understanding that we need to deliver a platform based on an ALM meta-model, something that we can utilize and leverage to define all the various activities and assets that flow through the application lifecycle. Then we need to provide a set of core services that will use that meta-model and will support add-ons that are lacking today. One of the critical things is providing more comprehensive ALM-centric metrics and measurements that span the lifecycle -- versus being very vertically focused for a particular role and job. A lot of this is based on having an ALM data description that represents all the activities and data that are going to be passed through a lifecycle.
Gardner: So there’s an immediate tactical benefit of getting the data from the various parts, and there’s a larger strategic value of then analyzing that data, because you've got it in the holistic process-driven environment, a common environment. What sort of data and metrics do you expect companies to be able to derive from this, and how can they instantiate that back into the process?
Brown: The critical thing that businesses will be able to do is be able to demystify what software development really is. It's about removing the "black box," and having data consolidation or aggregation so they can in fact measure what’s going on. Then they can determine what areas of the processes are working, what areas potentially are bottlenecks or are deficiencies. They can utilize the data that’s being collected across the ALM, and filter that out to the broader business intelligence activities that the IT business is doing to see what’s actually working, and what’s not working, within the IT organization.
Gardner: We're going to be able to give non-IT people some real visibility into timetables, quality assurance curves, dates for completion, and that sort of thing, which to me seems essential. If you are putting a new product or a new service in the market, you are going to be ramping up your marketing, ramping up inventory and supply chain, and are going to be looking into manufacturing, if that's the basis of the product. You really need to coordinate all these things with development, and that has been haphazard.
Am I reading more into this, or do you really plan to be able to give non-IT people these dials, and this kind of a dashboard by which to run their entire business -- but with greater visibility?
Brown: That is exactly what we are proposing. Borland is very committed right now on Open ALM to deliver a platform that allows organizations to leverage their own configured processes and technologies to gain the insights necessary to really start having confidence in what they are doing. That confidence is going to be increased by providing them the tools and technologies so they can track, measure, and improve their processes.
Gardner: Let's take it back to Carey Schwaber. Carey, in your analysis of the market is there a potential for a significant productivity boost by bringing visibility into software development and activities into the larger context of business development and go-to-market campaigns?
Schwaber: I think there is. And there is a great degree of redundancy that happens to a lot of development efforts that have already been accomplished, or just redundancy of documentation. Even when it’s not redundancy, the problem is that people are pursuing different goals -- when you have testers who are testing against out-of-date requirements, and the business analyst wants them testing against the newer requirements. We've got the problem of an overlap of efforts. Then we've got the problem of misaligned efforts. Together those really eat away your productivity and waste precious development dollars.
There are a couple of ways you can use better ALM practices to improve productivity. The first is to get numbers about what you are really doing today to measure how often these things are happening. That is the first step that you need to take before you can take remedial action. The second one is just making sure that you have people working off of common data, that there is one way to represent the truth -- not just about one part of the lifecycle, but the entire lifecycle. You have to have the appropriate correlation between those disparate parts.
Gardner: Brian Kilcourse, to your point about CIOs trying to demonstrate value in real terms -- to be viewed as a productivity center and not a cost center -- do you think that this visibility into application development can give you, as a CIO, the tools you need to go to the CEO and say, “Here is what we are going to do, and when we are going to do it.”
Kilcourse: Certainly, if you as a CIO can map specific IT activities back to the business requirements that drive them, you have a much stronger set of metrics to indicate your alignment to the business than you have otherwise.
There is a huge disconnect between the front of a development process, which is always driven by business requirements, and the back-end of the process, which is always post-production maintenance. Between those two spaces there are a lot of things that go on. Somewhere along the line, in what I characterize as the business technology handoff, there is a big disconnect. Even with the best intentions, because of the complexity of the technology solutions available, the business really does lose track of what those guys down in IT are doing. The ability to overcome that chasm would go a long way toward solving the historical distrust between the two organizations.
Gardner: Do you sense that there are any particular vertical industries or even types of development projects that would benefit from an approach like Open ALM better or first? Where is the low-hanging fruit for this?
Kilcourse: That’s a great question. No business that I am aware of starts from scratch, either with a technology group or with the business that it supports. So any business that is trying to infuse the business process with the information asset in new ways is a candidate for this. I focus a lot on retail. And I can tell you from my experience in retail that those organizations are ripe for this kind of capability. There is a tremendous amount of distrust between the executive side of the house and the IT side of the house in that particular industry. I see it in other industries as well. But even in such obviously highly correlated industries like financial services there is still a tremendous room for improvement.
Gardner: Do you think Open ALM makes more sense for those organizations that are in fast-moving markets? Retail, of course, is like that because they have to anticipate, sometimes months in advance, the desires of a culture or a human fashion-driven impetus to buy. And then they have to act on that. Do you think that for those companies that are involved with fast time-to-market that this would be particularly important?
Kilcourse: Certainly fast time-to-market causes fast marketplace changes. The problem in IT across so many factors is that the IT organization cannot respond quickly enough to changes in the business environment. That's not particular to retail. It happens everywhere. To the extent that you can eliminate the friction that exists in the delivery process within the IT organization -- so that the company actually is getting the maximum amount of traction for their investment dollars -- it's going to help.
Carey pointed out, and I thought it was a really good point, that there is a lot of wasted activity that goes on because of rework and focusing on the wrong requirements that might not have the biggest benefit -- but might be the thorniest problem that somebody faces. We don’t always have visibility into that. We find out only at the end when we tally up the score and find out where the dollars really went and why we had to go to Phase 2, Phase 3 and Phase 9 of a project, because we couldn’t get it all done in the first shot.
The ability to focus IT energy where it really matters most to the business is a big goal of most CIOs that I know.
Gardner: Carey, back to you. Do you concur that the fast time-to-market is a major impetus? If so, what other ones do you see in terms of where common views of practices and processes for application development are super-important?
Schwaber: I agree that fast time-to-market or any time-to-market pressure is definitely a reason you would need to have your ducks better aligned up front. But I don’t know any companies that don’t want to do a better job of satisfying their business customer’s demands for the same software in less time. That's a pretty universal desire, no matter whether you have a lot of time-to-market pressure in your industry or not.
So, I would say that we all want more for less. On top of that, I would add compliance requirements, where you need to confirm that the software you are developing does what the business wants it to, so that you know that you are producing accurate financial reports, or even that you have some kind of internal compliance requirement.
You know you are looking to get toward Capability Maturity Model® Integration (CMMI) Level 2 or Level 3, and you want some proof that you are actually going to do that. ALM capabilities can really help you in that area. So those kind of pressures really matter. But any time we get away from the old halcyon ideal of the business customer telling the developer what to write, and then the developer immediately implementing it, we have opportunities for miscommunication. The more people, geographies, and technologies we involve, the more complex it all gets, and the more we really need help keeping track of all the dependencies between the things that we are doing. That is really describing any project these days.
Gardner: Of course, software seems to be playing a larger role in how companies operate. The technology, in a sense, becomes the company.
Schwaber: How many business processes are there that aren’t automated by IT, either today, or plan to be automated by IT within the next five years? Business processes that we can’t even imagine will be embodied in software eventually.
Gardner: Let’s get back to Marc Brown. Marc, at Borland you have come out with this Open ALM approach and you have had a lot of experience in development over the years. Do you have any metrics? Do you have any sense of what the pay-off here is through some of your existing customers -- maybe some beta examples? Do you have any typically "blank" percentage of savings? What are the initial payoffs from embracing Open ALM?
Brown: We certainly have seen the benefits with many organizations, which see the value in a number of ways. First, many organizations, because they are trying to improve their overall process, are attacking their deficiencies incrementally. We've got some organizations that have found their key issue today is poor requirements definition and management. They simply can't get requirements written accurately and in a way that they are testable up-front. This creates a huge amount of rework downstream.
We've got some really good examples where we have gone in and helped organizations improve their requirements definition and management process, and we found really dramatic improvements. On one occasion, an organization was able to achieve a 66 percent improvement just on the analysis side -- when they were going through, looking at a legacy system, trying to define the "as-is" business processes, and then taking that work and collaborating with the business stake-holders to construct the "to-be" business process. That was typically taking the organization anywhere from 12 to 20 weeks. They saw a 66 percent decrease in that time by leveraging not only the process guidance we were giving them, but also other technologies that we could apply to that area of the process.
Gardner: So that’s a substantial opportunity, and that was only, I suppose, a partial embrace of Open ALM.
Brown: Yeah, and that’s the way a lot of people are looking at this. We are going out and helping organizations first of all pinpoint their largest areas of deficit or gap. That could fall into any of the four critical solution areas that we're helping organizations around project and portfolio management, or, as I mentioned, requirements definition and management, or lifecycle quality management. We are helping them understand where they have gaps or deficiencies today, and then incrementally improving that over time to embrace Open ALM as an incremental philosophy and approach.
Gardner: How has this so far impacted distributed types of development, where the organization has a number of development centers around the world, where perhaps you are outsourcing, and your outsourcing organizations are spread around the world? What’s the potential payback for those sorts of highly distributed development activities?
Brown: The real benefit we are seeing, and we will see more of this over time, is through the increased visibility. Again one of the biggest problems with organizations that are outsourcing today is the inability to aggregate or consolidate data from the outsourcer, the supplier, and the vendor, and to bring that together into a view, to have confidence that what’s happening from the outsourcer aligns with the overall business goals and original project plans. With our ability to help overlay our platform to bring together both the outsourcer’s technologies and data -- and then bring that together with the internal data -- we are able to bridge the gaps that they are having today, so that they have more confidence in the data they are seeing.
Gardner: How about Services Oriented Architecture (SOA)? It seems to me that as you break things down into services -- if we eradicate more of the silos around runtime environments -- we are at the same time knocking down silos in design-time. We might be able to get into some sort of a virtuous cycle, whereby we can adjust development to suit what’s going on in the field, which then is able to adapt to business requirements. That seems to be a big pay-off from SOA.
Let me throw that out to the crowd. What do you think is going to be the impact of SOA on development?
Brown: I'll take the first crack at this, Dana. I do think that SOA will certainly provide a lot of benefits, because it is one of the first practical approaches to help organizations realize the benefits of reuse. It's something that a lot of organizations had talked about time and time again. But there has been a lack of a common infrastructure or communications to bridge how that really happens over time. Many organizations simply said, “Look, my project’s not budgeted to create reusable code. We've got tight deadlines, and we have got a lot of work to do, and I am not going to have the time to do it in a reusable fashion.”
SOA gives people a good framework for how to actually structure applications to provide interoperability over time. I think this is a good approach for organizations to finally see the benefits of reuse, but it requires a lot of management and due-diligence when they are developing and deploying particular components. Because as they develop new versions or new components to supplement existing ones, they have to have more visibility in the usage levels, on who is using what, and so on.
Gardner: How about you, Brian? How do you see the evolution and maturation of ALM and the burgeoning ramp-up to SOA working either together, or perhaps at odds?
Kilcourse: Actually I don’t see them at odds at all. Because, first of all, SOA is an architectural concept, whereas Open ALM is a process concept or process model. In my company we just finished a piece of research on SOA and retail. What we found out is, if I could characterize something as a curiosity-understanding ratio, there is a lot of curiosity and very little understanding of what SOA really means in terms of how you get from "here" to "there."
As it relates to ALM -- going back to the original discussion that ALM covers everything from requirements all the way through post-production -- the notion of SOA breaking things down into reusable components or objects, business rules or metadata that can be redeployed almost at will as the business needs change, is a very powerful notion, especially in an environment such as the one that I service, where the business environment changes quite dramatically.
The challenge, of course, is taking something as broad as a business requirements and breaking them down into tiny service-level objects that then can be understood and implemented by the IT organization. If you don’t have some way to map that to the business requirements, you could have a worse bowl of spaghetti than you have now. In that context, these things are very tightly interwoven.
Gardner: How about you Carey? A last word on SOA and ALM?
Schwaber: Well, a lot of the great words have already been taken. But what I would add is that SOA introduces more dependencies among development projects then we are used to. It really requires us to have some way of coordinating our efforts across projects. In the past, projects often used completely different technologies for managing their lifecycles.
So this is yet another impetus for us to have a better way of connecting disparate tools from different vendors that use different technologies. Otherwise we end up not communicating the right data at the right time about services, about service levels, about service quality -- and we end up chasing our tails, trying to figure out what it is we have to do to build services that other people can reuse in effective ways that map to the business processes we are looking to automate.
Gardner: I suppose that quality and quality assurance are important when we go into these more componentized services. It seems to me that history has borne out that quality comes from getting it right the first time, and that really means business requirements.
Schwaber: SOA really does make quality that much more of an issue. We aren’t that good at it for basic, monolithic applications. Imagine how bad we’ll be at it with SOA?
I really see SOA giving us an opportunity to do better, because in every service a defect is propagated to every single application that consumes that service. But if the service is high-quality, that quality level is propagated, too. Essentially we have a mandate to do a much better job on quality in our services because the stakes are so much higher. We really need to bulletproof services that are built for reuse.
Gardner: Marc, to you now. As the stakes are getting higher, Borland has identified an important initiative. What is it that puts Borland into position to lead in this segment? Is it because of your heritage, acquisitions, the position you’ve taken on openness, or is it because of a "secret sauce?" What is it about Borland that makes you able to rise to this challenge?
Brown: It’s a couple of things. First, Borland in its overall business strategy is completely focused on helping organizations transform the way they do software, and we are not promoting any particular type of platform or development environment. We are all about helping people understand how to manage the actual processes that govern ALM. I think we have got a little bit of a secret sauce, because we are somewhat neutral from the platform or development-environment perspective. There are other vendors in this space who certainly have specific ties with a particular platform or development environment.
One thing that really distinguishes us from the others in the game is the fact that we are really focused on helping customers solve their true pains, which is giving them the metrics and measurements they need to be more successful at software. And at the same time, we support their current investments and future investments. So for us we’ve got full focus on ALM, and we are committed to supporting the platforms, the development environments, and the processes that organizations use today -- and those that they are going to use in the future.
Gardner: Great. Well, thanks very much. This has been a BriefingsDirect podcast discussion, a sponsored podcast about Application Lifecycle Management and the evolution of software development into a managed business process.
We’ve been joined by Carey Schwaber, a senior analyst at Forrester Research. Thanks, Carey.
Schwaber: My pleasure.
Gardner: Brian Kilcourse is the CEO of Retail Systems Alert Group, and a former senior vice president and CIO at Longs Drug Stores. Thanks, Brian.
Kilcourse: Thanks for having me.
Gardner: And Marc Brown is the vice president of product marketing at Borland. Thanks, Marc.
Brown: Thank you.
Gardner: This is Dana Gardner, your host and moderator, and the principal analyst at Interarbor Solutions. Thanks for listening.
Podcast Sponsor: Borland Software.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect podcast on Open ALM and ALM 2.0. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment