Welcome to this IBM podcast, Ten Things I Hate. About Application Lifecycle Management, Part 1. I'm

Transcription

1 [ MUSIC ] Welcome to this IBM podcast, Ten Things I Hate About Application Lifecycle Management, Part 1. I'm Angelique Matheny with IBM. Software is the invisible thread powering an increasing number of products and services today, and in order to manage this complexity, you need a holistic, integrated and flexible software delivery solution that addresses the entire lifecycle. However, making sense of complex software delivery is often not easy and sometimes down right painful. It doesn't have to be that way. IBM Rational, the leader in application lifecycle management -- or, ALM -- can help. Unlike other vendors, Rational offers a complete ALM solution across all lifecycle phases and roles to help organizations deliver efficiencies and speed to market while cutting risks and costs, not results. Three cornerstones of Rational's ALM solution that differ from other vendor solutions are flexibility, increased business value and open collaboration. So today we welcome Eric Long, software engineer. He'll introduce us on how IBM Rational helps ease the pain of complex software delivery and why it will continue to be the leader in ALM. Hi, Eric. Welcome to the podcast. Thanks -1-

2 for joining us today. Hi, Angelique. Pleasure to be here. Thanks so much for having me. You know, we really have a lot to cover so let's jump right in. I'm going to start with this one what does ALM mean and how can it help me? Okay. Great question, great starting point. We get this question all the time, especially now that we see more and more from our competitors and in the news today about this term ALM, and that term meaning Application Lifecycle Management. So what is it and how can it help individuals in software delivery companies? To IBM, ALM really is the management of all assets or all facets, I should say, of the application delivery lifecycle. So starting from things like business analysis, high-level modeling, even capturing customer requirements, stakeholder requests... Following those types of activities all the way through development, through architecture, modeling of that, to build and deployment, through quality management, testing, all of those different phases inside of your application lifecycle

3 ...bringing all of those components together in a way that becomes transparent so that in different individuals or role players in your companies can understand and gain insight into your projects real time. And I think we're going to talk about that later today. So bringing all of your different phases in the lifecycle and being able to manage them effectively in a transparent way. You know, in this age of globalization and with project teams located across the globe, productivity and quality software without support from every team member no matter their location. So how does ALM help me with this? Again, a great question, because today's current reality in software delivery or software development is that when I was talking about those different phases in the application lifecycle, we aren't all, you know, nestled in the same location like perhaps in years passed we might have been. You know, we have business analysts in Europe. We might have developers in Brazil that might be internal to our own company. But we also might be outsourcing some development projects or testing projects. So as we begin to talk about globalization and how -3-

4 globalization is a fact that we deal with with regards to application lifecycle management, we need to have and ensure that we have offerings in our organization that enable us to kind of flatten the earth, as it were, to enable these different folks and different role players in our organizations to really come together. That means they can communicate together, they can collaborate together, and they can begin to build linkages that span those different realms. So, for instance, requirements experts can begin talking with development experts, using their own perspective tools and terminologies that they're accustomed to using. So, collaboration in that regard is really about bringing not only the phases of the lifecycle together but also the people that are in charge or that live through those phases day to day. Okay, Eric, what is artifact traceability? Why is it so critical, and what is the impact of not having it throughout the project lifecycle or end-to-end management? Okay. So that's, again, making this a little more granular. We've talked about phases. We've talked about the people in those phases, now we're talking about the actual artifacts that are created in those phases by -4-

5 those people. Whether they be developers, whether they be business analysts, testers, build and deployment managers you name it, right, the list goes on and on of the number of individuals inside of our application lifecycle. So traceability really refers to the fact of being able to bridge gaps or create linkages from a high level of abstraction to a low level of abstraction to a lower level of abstraction, et cetera. Starting with your high level types of business requirements, or even beyond that, you know, capturing conversations amongst stakeholders and business experts at that type of level. Taking those individual artifacts, whatever they may be, and linking them throughout your lifecycle. So to give a quick example here. If you've got a new requirement that comes in from a stakeholder, ideally you'll want to...or in a perfect ALM world, I should say, you'll want to capture that requirement and then as that requirement becomes implemented and persists throughout the application lifecycle, you'll want to be able to relate back to that requirement from different artifacts in your application lifecycle. -5-

6 So through your source code in your development world, or from a specific test case or even a test strip in the testing world. And everywhere in between. You know, that requirement will eventually be satisfied in some build of your application. So if we have the tools in place to create traceability from A to Z, it makes everything -- things like dealing with change, dealing with defects that come up -- much simpler in that you know how the dominos fall, meaning if a change request comes for a particular requirement, having that traceability allows you to go directly to a specific source code file or directly to a specific test and make those changes accordingly. So having the ability to react quickly to change is what traceability ultimately buys you. Eric, we all know accurate, reliable and timely access to and reporting of project information is critical to project success. Tell me how ALM addresses this critical success factor. So, when we start talking about reporting, we can even start mentioning some products here. When we talk about ALM from an IBM perspective, we're really talking about our Jazz products or our Jazz foundation. Three products in particular -- Rational requirements -6-

7 composer, Rational Quality Manager and Rational Team Concert -- these three products map to different realms of our application lifecycle, specifically Rational Team Concert or types of change and configuration management, Rational Quality Manager for quality management, and Rational Requirements Composer for requirements type of management. You can think of each of those three products as kind of hubs of information around their perspective realm. What's neat about the Jazz offerings is that every one is built or has a common reporting engine underneath it. We won't get into the details of how it actually works... But the point being that from each of these individual realms or hubs -- or offerings or products, whatever you want to call them -- they have reporting engines that enable you to report across realms, meaning you can report on requirements with relation to development artifacts and with relation to quality management artifacts. What's more is all of that's done dynamic and live via the reporting engine. In other words, it's effectively constantly monitoring all of the data across your lifecycle and automatically generating real dynamic reports on the fly. So you'll always have this type of transparency and ability to understand what's going on with your specific projects. -7-

8 I hear a lot of talk about Agile delivery practices. How may I understand the importance of Agile and scalability in ALM software delivery? We have heard a lot about Agile, and it most certainly is a popular type of development process, especially for smaller teams. One of the biggest, I guess, knocks against Agile has been it's questionable when you begin to scale and to enterprise types of development. Some of the key, I guess, misconceptions about Agile development is that it has to be done with smaller teams or co-located teams. What we have embedded in some of our products most notably Rational Team Concert, is templates to help grow Agile from beyond just small co-located teams into an enterprise-wide type of development practice. And we can do that because our products actually enable us to enforce these types of processes across development teams and even beyond. Again, extending into requirements teams and into quality management teams. Eric, I repeatedly hear how proprietary standards and processes handcuff project teams and stymie project progress. What's really going on here? And is there a better way? -8-

9 You're right. When you start hearing the dirty P word, Proprietary, you become a little worried that you're dealing with things like perhaps vendor lock-in or you purchased all these technologies or these products from different vendors and there's no good way to share those processes with other teams in your organization. We mentioned earlier this globalized way of life we're dealing with and how oftentimes, in fact, most times you're dealing with or working with companies that are building applications that have several different teams around the world following different methodologies and different processes and even using different tools. So how do we manage all of that? We manage all of that by doing exactly the opposite of proprietary standards. We break down those standards and open them up. And that's exactly what we've done with Jazz and IBM's ALM solutions, is we've adhered to open standards such as OSLC, C open services for lifecycles collaboration, and by doing so we enable other tools and processes to adhere to those standards, which helps make our job easier because we don't have to deal with those handcuffs. Right. And related platform dependency locks me in as well, and yet I have applications on a large -9-

10 variety of platforms to support. What are some of the alternatives? You're right. A perfect example of platform dependency is several of our competitors are very platform dependent on Windows-based machines or PCs. In the real world, what happens is you've got these distributed teams where you've got legacy software operating on a wide variety of platforms. And when you begin to get into an issue where your software just isn't working or has a specific platform dependency, it's doing the same thing as those proprietary standards are and those proprietary processes. They're really locking you in to a specific solution... In this case, with platform dependency you're talking about a hardware dependency that's limiting your options as you continue to grow or as budget becomes a concern and you might have to make perhaps cuts in the type of software you're using, you limit your options and your ways out of those options by handcuffing yourself. Okay. I have all these tools. But they don't talk to each other across the lifecycle. I don't want to give up control if I don't have to. And I'm tired of the run-around and finger pointing I get when I need help. -10-

11 There must be a better way. Yes, I mean, this is the biggest problem we have when we start talking to companies about application lifecycle management. They have all of these disparate products and they all can't communicate together. Companies will have a development-specific tools, maybe they're using open source tools or maybe they have outsource teams that are using open source tools and they themselves are using different types of development tools. How do you get those development tools to talk to each other? And it's actually much worse than just that simple example I gave, because that's only talking about the development realm. But what about things like the requirements realm and the quality management realm where you have even more tools that kind of add to this point-to-point integration. You begin to see that the more tools you have, the more point-to-point integrations you have. That's an exponential curve. So if you have to build these point-to-point integrations, what happens if one of the tools breaks or the company goes under and they no longer support the specific version you have, you begin to break all those other integrations that rely on that point-to-point integration. -11-

12 So there is a better way, and that's with IBM Rational and dealing with the Jazz platform. And again, going back to the open standards and processes that these solutions adhere to. They allow for integrations that are much more seamless and that are more reliable than the point-to-point integration. Eric, many delivery teams must use multiple tooling throughout their project lifecycle which can, of course, be quite challenging. What are the primary issues here, and how do Rational capabilities and solutions help? That's a great point. Many companies are already using their tools. They've got their requirements tools that they're very accustomed to using. They've got their development tools that they're very accustomed to using and they've got their quality management tools that they're very accustomed to using. And they're all different and they may not be interconnected or integrated yet. But they want to get to that point. But they also don't want to completely dump everything they have and start over with Rational. What's nice about the Rational ALM solution is that you have the ability to extend the hubs of information to other types of tools out there -- meaning, again, it kind of goes back -12-

13 to the vendor lock-in thing. You're not going to be locked into Rational-only products. Because these Rational offerings -- like specifically the three I mentioned earlier -- are built on these open standards, they allow you to plug and play with your own existing perhaps tools that you have as long as those existing tools adhere to the same standards. And we find that more often than not that is the case. So that really helps with this multiple tools and multiple locations types of issues that you're talking about. Okay. Open source versus open commercial what's the distinction, and why should I care? That's a great point there, and a great question. Because when we start talking about how IBM Rational is building their current and future products on this notion of open commercial development, a lot of people do confuse it with open source. I can assure you, we're not open sourcing all of our source code and giving away our software for free. But what we've done here is we've seen the popularity of open source software and the success that it's had. -13-

14 A perfect example is Eclipse. That is a piece of open source software that has just kind of exploded. So, what we wanted to do was take that notion of opening up development without kind of giving away all of our code there, of course, like Eclipse does, but take that success driven around this open concept and apply it to the commercial world. So what we've done with Jazz and jazz.net, you can actually see all of our Jazz-based products being worked upon in real time. In fact, it's a perfect example of eating our own dog food or drinking our own Kool-Aid, or whatever you want to call it. We're using our Jazz tools to build our next generation of Jazz tools, and in that regard we're making it very visible and transparent in our own development of the products themselves. So the difference again, open commercial meaning that we're building our commercial products in an open environment versus open source where that software is for free and also built in an open environment. Open commercial, again, is just a little more controlled in that regard. Eric, we're about out of time. Is there anything you'd like to add in closing? Yes, so a couple of points I want to add -14-

15 dealing with some of our competition. When we've talked about today, albeit very briefly, is again, application lifecycle management end to end and how our Jazz or IBM Rational solutions for ALM really are built on this notion of ALM. A lot of what you'll see today with our competitors is that they're trying to retrofit existing technologies and kind of slapping names on their products to make it appear as if they are, you know, ALM ready or whatever you want to call it. It's simply not the case. I'd like to ask everyone to if they're looking at competitors to really search under the covers and find out whether or not our competitors can actually handle the end-to-end ALM scenario. We're equipped today to fully handle end to end an ALM solution, and that's a very important thing that IBM can help you all out with. Eric, as always, thank you so much for sharing your time today. We really appreciate it. And of course, there's a Part Two of this podcast, so looking forward to working with you again very soon. Thanks, Angelique. Great to be here. That was IBM's Eric Long, talking about, Ten -15-

16 things I hate about ALM. This is Part One, Ease the pain and make sense out of complex software delivery. To share this podcast with your colleagues or if you're interested in more podcasts like this one, check out the Rational Talks To You Podcast page at We'll post a link to the ALM Everywhere Kit to help you get started, so be sure and check it out today. This has been an IBM podcast. I'm Angelique Matheny. Thanks for listening. Keep tuning in as Rational Talks To You. [ MUSIC ] [END OF SEGMENT] -16-