T3 Webinar:

Approaches for Integrating Configuration Management into Your ITS Project Development Processes

Question and Answer Transcript

Back to Webinar Files

Q. Paul Olson Asked: Please address the FUD [Fear, Uncertainty, and Doubt] spread by many vendors that claim you don't need SE [Systems Engineering] or CM [Configuration Management] because our product is COTS [Commercial-Off-The-Shelf]. Even though reality is that that COTS product is highly customized.

Frank Cechini: I'm going to address that from two points and then I'm going to let the others speak as well from systems engineering and CM. From a system engineering perspective, whether it's COTS or not, you are purchasing something to meet your vision of what you want to do and operate with and you do need and would want to look at just what are the requirements that make up the product that you want? Primarily so that when you do purchase a COTS, you've got something to test from. Did this COTS product provide you the service that you wanted? You do need to look at requirements just to establish some kind of testing that you can verify with. I could go on and on about that subject, but let's go to CM here for a second - Configuration Management. Again, from a perspective of say a local agency, I guess I would want to use it as an evaluation tool and I guess you would call it a discriminator for the vendors of COTS products that are coming at me. All those COTS vendors should have an internal CM process that's documented and they're following to put those products together. They should be willing to share that documented process with you, as a purchaser of their equipment. Version of software and hardware, the documentation version, notices of design changes and obsolescence that have been produced for that product. These are all good things that I think you would want to look at to assess whether this particular vendor's product is stable and can provide you the service and they - since you're purchasing their COTS product - they can provide you with support service through X number of years of life with that particular product. Ron or Mark or Chuck, do you want to add to that?

Chuck Larsen: This is Chuck. I would say that you very much need a configuration management, even for COTS products. All of our COTS products are in our configuration management system. I'll use a road weather information system as an example. Yeah, it's a COTS product, but it's still software that runs on a server that has a database that connects to field devices. You've got contact information about who you're going to call when you have problems with the vendor. So there's still a lot of information about that system that you need to know in order to have it in your environment. Today, as hard as it is to provide security for a network, the black box days of just install this and let us take care of it completely are kind of gone. You've got to know enough about that system to know that it fits within your environment and isn't going to cause problems.

Mark Morse: This is Mark. I've got a couple of comments I'd like to make. I think that Chuck kind of alluded that no matter where the product comes from, you the user need to manage it, keep track of it, know where it's installed. On the other hand, I think that the manufacturer, the vendor, needs to do configuration management and they may not necessarily give you that information. But it should be there so that if you need tech support and you've got a problem with a particular feature, they have access to that change information, so that they know which version that feature was added in and any changes to it. I think configuration management needs to be done on both sides of that sale.

Q. Howard Stoller Asked: What is your position on using a Configuration Management Database. Also, how much of CM have you taken from ITIL [Information Technology Infrastructure Library]?

Ron Ice: Frank, this is Ron. I have some familiarity with ITIL. It's basically an IT information library that was developed in Britain. It has a very good set of documentation on configuration management and a lot of other aspects of managing an IT system. Unfortunately, I am not that familiar with the library, but a lot of the things that it talks about, about configuration identification and having a repository for your configuration information, that is, a database, doing change management a lot of the theme that comes through in that ITIL also were picked up and were used in our presentation today. So I can kind of understand the question really. You were wondering if we were drawing from that library. Not really. At least, I wasn't. But a lot of the principles of configuration management, you'll see popping up again and again in different libraries. One thing I like about the ITIL suggestion is it kind of underscores the need for us as ITS and operations focused people to lean on our IT departments, because they have a lot of information out there, like ITIL, that we can apply to ITS.

Q. Michael Yeosock Asked: Is it preferable to evaluate several and specify one central system software during the design stage rather then use a non-proprietary spec during bidding?

Frank Cechini: This is a loaded question. I'm not sure how to frame an answer relating to configuration management on this. As just a general comment from a system engineering background, you aren't making that decision upfront. I think that's part of what you would be looking into in your concept of operations and walking into your high level functional requirement as to just how proprietary or nonproprietary you can live with the product that you're eventually going to acquire.

Q. Emiliano Lopez Asked: Can you give your perspective on how CM can supplement/benefit performance monitoring i.e. tracking of equipment life cycle, budgeting, etc...

Chuck Larsen: It goes into how configuration management isn't, in and of itself, something you do. It's wrapped into your overall maintenance processes. We use a tool called MicroMain, where all of our configuration information about our field equipment is at. Besides keeping track of the configuration information, it's keeping track of all the trouble tickets and the maintenance and operations that have been performed on those field devices, so you can go back and do that kind of reporting and find out how many times this thing has happened. If you've got good configuration management information, what that allows you to do is you can start doing things like well, am I having a lot of problems with this specific configuration? They go very much hand in hand.

back to top

Q. Paul Olson Asked: If you do COTS who does this you or them? How might you approach the COTS folks on this topic in a procurement process?

Frank Cechini:  I think Mark said it best. It's both. There's configuration management that you expect your vendor to be if you're hiring a COTS or having something kind of different. You're expecting your vendor to do a certain amount of configuration management, but ultimately you're responsible for what's built. So it's got to be integrated into your configuration management.

Q. Paul Olson Asked: Then once you hire that COTS vendor how to you make sure they are really doing an adequate or acceptable job at CM?

Frank Cechini: Again, part of the answer to that is assuring and doing an investigation early on as to just what they're internal CM processes are that they're using. I think we've answered otherwise. Does anyone else want to comment on that?

Ron Ice: I guess audits internally, auditing their process to make sure that it is-- depending on the type of procurement you're doing, acquisition.

Frank Cechini: Right. That is very important, the configuration audits.

Ron Ice:  One other point, an example of that kind of thing. Florida DOT has their approved product list, and they actually look at the processes of the manufacturer, the provider of those products. They don't just look at the products themselves; they look at the processes behind, including the configuration management. So there's a real world example of a DOT going out and doing that sort of thing.

Jesse Glaser  [Who spoke during the audio question period]: One indicator that you can use is how many surprises you have when you get an update. If they install an update and suddenly things are broken or something doesn't work and the explanation is, "Well, we forgot to notify the operator that they have to boot the system in a different way," things like that. Any kind of surprises that you say, "Gee, we should have been told about that. We should have known. That shouldn't have happened." That's a big red flag that there's not adequate CM going on.

Frank Cechini:  Good point. That's Jesse Glaser from the LA Metro office of Federal Highway Administration.

Q. Paul Olson Asked: Suggestions for dealing with CM on software in Escrow?

Chuck Larsen: Software that's in escrow. I guess the issue would be that you'd want to make sure that you know what version of the software is in escrow and are you getting the updated versions out there and you're tracking it.

Frank Cechini:  I think that's a good point. I think probably there is a tendency on the public side that you're assuring that something is in escrow, but not really thinking about the continuation of updating and the version controls that would go with the product and assuring that what's in escrow is getting the same update. Interesting point being made there.

Q. Lee Neal Asked: How practical is it to do CM after a system is complete?

Frank Cechini: In essence, after it's been developed and delivered, I guess is what you're saying there. That's the tough part and that's the expensive part of this. That's the reason why we're encouraging the early CM planning, because as we all know through the system engineering process, the later changes are made, the more expensive it's going to be to you to deal with those changes. How practical is it? Not very practical, in my mind. It involves quite possibly some re-engineering or reverse engineering. Anyone else want to comment?

Mark Morse:  This is Mark. I'll make a comment. Initially, I would say better late than never. Chuck kind of alluded to it that in 1999, they started a CM process that perhaps hadn't been done before. I guess you're right, it's easier and perhaps less expensive to do it from the beginning, but I still think it needs to be done. You don't want to be without.

Frank Cechini:  What you're highlighting there is the important point that configuration management should not be assumed as just part of a project or of a system. I think as you point out there in Oregon, it is a part of your organizational structure to assure that CM is a part of anything that you do. So I think that's important to be looking at here as well. You're right.

Chuck Larsen:  In terms of practical or not, you've got to start sometime. Take what information you have about that system and the other systems that you have and start collecting it and managing it and slowly add on as you go. As you start to use it, you'll improve.

Mark Morse:  Right. I think the CM process is an evolving process. Maybe you can back me up here, Chuck. As you go through the process, you attract new tools, you discard the things that don't work and pick up things that do serve your needs.

Q. Cary Vick Asked: Can you address how people might fund the CM process?

Chuck Larsen:  Well, I saw that question and I've been sitting here pondering it. Because it's in policy that we have to do it, it's really, in terms of the activities that are a part of the project, it's just when you do your project estimates, it's part of the project costs. Then also we have overall maintenance costs. But in terms of ever sitting down and saying hey, configuration management costs us this much, it's not something we've ever done. On the maintenance side, it's really more of a survival kit. It's never really looked at as optional. On the project side, it can add some costs, but they're just built into the project budget while you're doing the estimating. Now, in terms of the upfront costs, ten years ago when they actually implemented this, there were some costs to put that policy and those procedures in place that was very real. Those were funded out of the IS budget.

back to top