A Scenario for Using the Product Line Practice Framework

NEWS AT SEI

Authors

Paul C. Clements

Sholom G. Cohen

Lawrence G. Jones

Linda M. Northrop

Dennis B. Smith

This library item is related to the following area(s) of work:

Software Product Lines

This article was originally published in News at SEI on: September 1, 1999

Linda Northrop has been with the SEI for the past five years. Prior to assuming the management of the Product Line Systems Program, she was lead for the Software Architecture Project, manager of the Education Process Project, and Chair of the SEI Education and Training Review Board.

Sholom Cohen is a Senior Member of the Technical Staff of the Software Engineering Institute (SEI) and has been at the SEI for over ten years. Mr. Cohen is a member of the Product Line Systems Program and has authored major technical reports and conference papers on domain analysis and domain engineering methods and an annotated bibliography of domain analysis.

Paul Clements is a senior member of the technical staff at the Software Engineering Institute. A graduate of the University of North Carolina and the University of Texas, he is a project leader in the SEI's Product Line Systems Program.

Northrop. So, what we decided to do is to give you a little bit of <<something> into the framework for you to help you get an idea of how you might use the framework in your organization. We’d like to give you a dynamic, dramatic look at the framework. We’re actually going to provide you some scenarios on how to use the framework in your product line activities. In order to provide this little dynamic ..., we’re going to do some interactive discussion. I won’t go so far as to say that this is drama. There’s a real reason why we have day jobs. Our dramatic skills are not nearly as good as our technical skills, I might add.

My name is Ms. P.L. Wannabe and I’m a program manager. I have business goals; I know what my business needs to do, but I’m having difficulty with the ... technologies and processes that I employ. Now, I’ve got this SEI Product Line Practice Framework and I’m clueless as to how to use it. I consulted my favorite book on how to manage and I still didn’t come up with the answers on how I’m actually supposed to solve this product line problem. So, I decided that I would hire some consultants. These consultants are going to help me sort through this product line practice framework thing and see how I might be able to apply it. I want to start ... product lines. Let me introduce, first, Dr. Startup. He’s my Launching-a-Product-Line expert and he’s going to give me some advice. And we have Mr. <<Tele Vision>> who is going to talk with you about .... We have Dr. D. Zine who is an architecture expert. We have Dr. I.N. Dustry who is going to talk about COTS.

I want you to know that I’ve paid these people a lot of money and sometimes .... Let me describe my organization to you. I want to welcome you ... expecting some good advice.

My company is a consumer electronics company. Basically, I have some business goals. I want to improve my time to market and I want to increase productivity. We have an excellent reputation. We are world renowned for the quality of our products and we have greatly satisfied customers. I don’t want to do anything to mess with a good situation while I’m trying to improve time to market. But if I don’t improve time to market, I’m going to be out of business. My problem is that I’ve got a lot of software in my products and I never used to have a lot of software in my products. And I seem to have more and more software in my products and it seems to be more complex. These software costs are killing me. So, you know, I thought about adding more people, but the fact is if I add more of these software people they’re expensive, it eats my profits. And secondly, there aren’t enough of them out there. So, even if I -did- have the money to hire them, I can’t seem to be able to hire them. I’ve currently got about 250 people in my organization and that’s what I’m going to have to work with. I’ve been thinking about what we could do because it seems we build a lot of similar systems. We’ve tried libraries of code, but you know what...it just didn’t work. We didn’t get any reuse and we didn’t get any payoff from that. So, I read this SEI stuff about product lines and I got this framework document, but I don’t know how to sort through it. So, I’m asking you if you would help me start a product line.

Cohen. I think my colleagues would agree with me, we need to know more about the company and the kind of products you produce. So give us some more background information about the company.

Northrop. I’d be glad to do that. We build audio systems—all kinds of audio systems. Personal, home, all kinds of audio systems.

Jones. How are you structured in order to build these products?

Northrop. My organization is divided into projects and each project builds a product. So, it’s project-centric and product-centric within that.

Smith. You’re suspecting that there’s commonality among these products.

Northrop: I know there’s commonality...it all looks the same. Actually, the reuse is opportunistic. It’s up to the project manager and if they want to do reuse they do it; if they don’t, I guess they don’t.

Smith. Have you heard of the software CMM?

Northrop. Who hasn’t?

Smith. Have you been assessed or have you assessed yourself?

Northrop. Well, we actually haven’t been officially assessed, but we did a self- assessment and I think we’re about Level 2.

Speaker. Let me test my understanding of what you’ve been telling us. Your company builds consumer electronics. You’ve really got a great reputation and you’ve got about 250 people who work for you in the software area. You see a lot of opportunities for possibly looking to product lines because you really need to make the change. You have three main products—home, car, and personal products. The projects, right now are all organized around individual products so there’s really very little sharing of information, I would imagine, that goes on between those products.

Northrop. Yeah, probably.

Speaker. And your reuse is pretty opportunistic when it does take place. And you have been self assessed at CMM Level 2.

Northrop. Okay...you’ve been listening. That’s all the stuff I know. Now, how do I start a new product line?

Jones. First of all, you need to understand that launching a product line effort takes activities areas that you’re going to find throughout the framework. (slide with practice areas)

Northrop. I have to use all of those practice areas?

Speaker. The depth and degree to which you have to go into each of these is going to depend on the scope of your effort.

Northrop. What, exactly, does that mean?

Speaker: Well, you ought to really try to treat launching your product line as a special type of technology change effort. You’ll see that you’re not alone in the approach to this. There’s been a lot of work that’s been done on technology change. Our colleagues in the next session...working on process improvement have done this for years. So I want to encourage you to, first of all, draw upon this existing body of knowledge. Among those is that you need to account for the human aspects of change. It’s not all going to be technological. You’ve got to treat technology change, itself, as a project. Now, normally, I hesitate to tell that to a client—particularly if they’re Level 1 because what that means, [they’re going to neglect it and they’ve done a poor job????}. But since you’ve self-assessed at Level 2, you know what that means [?????]

Lastly, I’d like to suggest that you follow some sort of iterative technology change model.

Northrop. Could you suggest such a model? I don’t have a clue.

Speaker: Well, yes, there’s been some pretty good work done by the Software Engineering Institute in Pittsburgh. They’ve come up with a model which has had a great deal of success in process improvement. It’s called the IDEAL model. With a little bit of artistic license, it’s very easily adaptable to any type of change project. So let me run you through very, very briefly, the kinds of steps that are involved. First of all recognize that it is iterative and that you will do each of these steps—perhaps to some degree—more robustly than others, depending on where you’ve started on this technology change. The initiating phase of this model requires you and your organization to recognize that you have the need to change and to establish appropriate infrastructures to deal with this and allocate resources. In diagnosing, we take a look at where we stand at a particular point in time and what we might be able to do by way of possible improvement. In our establishing phase, we plan, based on the priorities determined in our diagnosis. In the acting phase, we execute those plans. Lastly, we want to learn lessons ....[???]

Northrop. This all sounds wonderful and it certainly is a pretty picture, but how am I going to do this in my organization?

Speaker: Let me try to give you some specifics. First of all, I suggest that you try to limit this cycle of the IDEAL model, and devote it to concept exploration.

Northrop. How would that go?

Speaker: This should be an inexpensive try at this. First of all, you want to commit some limited resources to explore the applicability of the product line approach. You might designate a person to go out there and gather data and run this concept exploration. Next, a diagnosis would be somewhat simple. Of course, you have a sort of back-of-the-envelope sketch of what are the product line technologies that are available and how that might relate to your organization in particular. In our establishing phase, we’re going to take the interesting case, which is to assume that you’ve made a go decision for the next round and that you’ve decided that further exploration is warranted for the next cycle. Typically at this stage, the acting and learning phases are truncated [or are rolled into the next phase????].

Northrop. So, what do I do after this exploration stage? Clearly this doesn’t launch the product line.

Speaker: No. But we could try another round with the IDEAL in which we do our concept refinement and the additional implementation. In this case, we start to beef up the steps that go in each phase. In the initiating phase would be more of an awareness building and advocacy [that’s broader than just the few people who are involved in it???] You would have to commit more resources and you might want to establish more structure in order to be able to tackle this. Your diagnosis would be more elaborate too, in which we review our existing organizational environment, our assets and culture and the things that you might want to take stock of. In your establishing phase, we’re going to start off with putting our toes in the water, in which we develop visions, goals, strategies, and objectives for [helping you achieve organizational xxxx with this product line????]. We want to take a look at some of the commonalities, scope the product line, and develop the preliminary operating concept, in which we describe how this is going to play out. This can be a significantly useful activity for risk mitigation. We will also then worry about preliminary architecture definitions, preliminary mining of your existing assets, which you say are out there, and work on developing a business case that’s going to establish why you would do this. Our acting phase is then to execute that plan. And then in learning you will select lessons learned from what we’ve done in that first cycle, refine our approach, and take another look at whether we proceed.

Northrop. Okay, well, how actually do I make some sense of this learning phase? How do I go ahead with it after that?

Speaker. Again, let’s take a more interesting case that says that we’re going to proceed with this, that this turned out and has some viability in your organziational context. I won’t belabor yet another cycle of the IDEAL, but you can consider that to be superimposed over this. You might beef up some structures and possibly do some rediagnosis, based on the first cycle of learning. But we want to refine our approach to create what I call a product line adoption or implementation plan.

Northrop. I don’t have a clue. What might be in a product line adoption or implementation plan?

Speaker. We’re going to have refinement of our initial architecture definition and we’ve learned some lessons about that, based on the first cycle. We want to have some further mining of our legacy assets, and now we’ve learned something about the organizational concept. We can refine our concept of operations and get more details on how we’ll actually tackle this. The details of how to migrate then from the current organizational state to the future state is what’s really going to be what’s described in this concept of operations.

Northrop. I just don’t like the whole word "migration." It sounds like a tremendous amount of upheaval. Can’t I use this product line thing without upheaval in my organization?

Speaker. I’m afraid not. Execution of this plan is going to really rely upon you and your leadership skills. Let me give you some practical advice on how you might tackle some of these things that might otherwise be overwhelming. You’re going to have to show leadership in establishing the goals, communicating, and being an advocate and cheerleader for these things. You’re going to have to allocate more resources. You’re going to have to set up proper organizational structures. You’re going to have to pay a great deal of attention to those initiating phase activities, particularly if they’ve been somewhat short- circuited while you tried to feel your way around the first couple of cycles.

Leader. Are you suggesting that I have to personally become actively involved?

Speaker. Yes, you most certainly do.

Northrop. I’m overwhelmed.

Speaker. Let me see if I can take some of the pressure off by giving you this whale sandwich a few bites at a time. You’ve already said that you’re a pretty good planner because you’re Level 2 CMM. So, if we actively manage this change as a project and not just let it happen, you’ll be a lot happier with it. Part of that is based on your excellent reputation in the hardware industry, you might be able to manage your risks pretty well. A way to keep the scope down, and to learn your lessons in a small way before making big mistakes, is to use pilot projects actively as part of your risk mitigation strategy. Initially, don’t go too hard and fast on some of your processes and organizational structures. Some organizations find a great deal of success using what you might call lightweight processes to tackle this initially. Keep things flexible and less formal to learn what works in your organization before you put a great deal of turmoil on yourself and your organization.

Northrop. That makes me feel a little better. I’m actually thinking, while you’re talking, that I know how we can come up with a goal, the vision and the strategy because we’re a TQ environment and I have people that I can gather around and help me do that sort of thing. But I’m really perplexed. One of the things you said was to plan things that I didn’t understand at all is commonality analysis and scoping. Early on, you said that the whole impact of the effort is really going to be dictated by the scope of the product line. I have a problem. What’s the scoop with this scope thing?

Jones. As much as I’d like to take some more of your money, I think I’ll have to defer to my world-class colleague on scoping, Dr. Vision.

Cohen. Let me help you learn a little bit about the scoping and some things you might want to consider. You mentioned that you have a TQ environment so you know what it means to do vision and goals. With product lines, you have to go back and do the same thing: What’s your vision for the product line. What are the goals that you’ve set for yourself. So, if you’ve set the vision, you probably want to consider the things you want the product line to accomplish. You mentioned up front that you need to reduce costs and control your [xxx??] These are pretty good goals that a company would want to achieve by taking on this product line work.

You also need to know what steps you want to follow to make those things happen. Again, with launching a product line, you need a strategy, a concept of operations. What steps you’re going to take up front in order to make this play out and work successfully from day one. At that point you know where you’re headed, you know what your vision is long-term, and you know what things to get started. At this point it’s now appropriate to start defining the product line, or possibly product lines.

Northrop. OK, I get this. Is this scoping?

Cohen. Well, scoping is actually about determining boundaries. What’s inside the product line and what’s outside. [elaboration on this, can’t hear ???] You need to know who your end users are. What service is the product going to provide to users? Looking at some of the products, some have built-in radios, some have playback and also record.

Northrop. So essentially, I have to look at the variations.

Cohen. What you really want to look at in terms of the scope is where it’s going to be from the architecture side. You’re going to make a product line architecture for some products and not others. So what are some of the issues that come up here? For example, something that a person could carry is not going to be as integrated as something that is used in the home. Those are things that are going to affect the architecture of the system. You have things that are going to be able to pick up a broadcast at home or in the car. Or you may be talking about a Web type of interface to pick up live broadcasts over the Web. Or maybe download Web source material and play that back. You may be able to take that with you.

One of the problems is who is going to distribute these products. Is it going to be the OEMs—GM, Ford or Daimler-Benz. Then you want to look at future plans, we’ve been looking under the microscope at these products, but you also need to take a longer vision, and see where in the future these products might go. The Web might be one thing that affects that.

Northrop. You brought up an excellent point. How wide is this scope?

Cohen. When you do product line scoping, you really want to try and look at scoping the products we’ve already mentioned and then try to pin down exactly what the product line or lines are going to be. So one thing you might do is say, well we’ll have one product line of entertainment products and then develop an architecture that covers all the products in that product line. That accomplishes one goal. So you may be able to use one kind of user interface across all of these. The tuners and play devices may be able to be reused. On the other hand, there’s probably a longer upfront development effort. You’re going to have to do scoping or architecture work and look at a broad range of products before you’ll be able to implement your first one. So that may be one of the considerations you want to make there. On the other hand, you may want to look at a separate product line for each market, so that would mean all product lines for home entertainment systems, car, personal, and have different product lines for each. There may be easier adoption, or earlier upfront kinds of implementation, [is this possible fragmentation, you may lose some of the economies of scope we mentioned ???]]. There could be other segmentations. You could say a tuner product line or amplifier product line, and so on. You may want to consider outsourcing some of {xxxx??]

Northrop. All of those things are internal. Should I look outside my company?

Cohen. Yes, I suggest you consider some of the things that are going on out if the field so you don’t lose sight of what other people are doing. Market studies are appropriate to see what the competition is doing. Your competitors may be doing some things you want to look at. You may want to look at opportunities for shared development, collaborators, opportunities to combine Web-based products with things you’re doing right now. COTS are another piece of information you may want to look at how to incorporate off-the-shelf capabilities into your products. And then there are other interactions. How do you do upgrades? Media types, how to play back digital, compact disks. Those are the kind of considerations you want to make.

Northrop. Hmm. So after I do all this scoping stuff, what’s the result?

Cohen. We hope that you’ve identified what product line you want to invest in, or product lines. You should have an understanding of the kinds of services that you’ll provide to the users. What kind of product integration you’re going to be able to accomplish, and you really want to bound your variability, you want to be able to say these are the products we’re going to do and these are the variations that we might be able to accommodate. You might want to say, in the future we know that products will be integrated with the Web and you may not be able to do that today, so you may want to leave that as an opportunity for the future, and you want to set a plan for product line development, common features, variations, architecture drivers, and so on. The SEI has product guidelines for developing a product line concept of operations.

Northrop. This is beginning to take shape in my mind, but something you said back when you were talking about market studies is bothering me. You said something about COTS. Now I’m confused. Why and how would I want to use COTS in my product line?

Smith. You’ve already seen that product lines offer tremendous examples of economies of scale. Organizations such as HP and Motorola have achieved these tremendous economies of scale.

In addition to that, I can go down to Comp USA and buy a COTS product that costs me $89.95. If your organization were to build this, it would probably take you about 2 years and cost about $3 million. So, there’s a good news / bad news scenario but you’ve got tremendous capability of leveraging on top of what you’re already leveraging with product lines.

Northrop. While it makes sense. The money part really appeals to me, but isn’t it kind of risky?

Smith. Absolutely. That’s the bad-news part. If you look inside the box of a COTS product, you have no idea what’s inside of it. You can see what the vendor says on the outside and there may or may not be a manual in there, which may or may not expose what’s in there—it may or may not expose what the interfaces really do. So, it’s a black box and you’re certainly taking a tremendous risk. In addition to that, you have no control over the evolution of what goes inside there. Also, in general, when you’re dealing with COTS products in a product line, you need to develop your requirements very flexibly and your architecture needs to be flexible so that you can handle a wide variety of interfaces.

Northrop. That’s way too general. How exactly do I do this?

Smith. Well, if you want to use COTS successfully, first of all, you need to really understand your own architecture, especially the points of variability and flexibility. You need to account for your whole organizational ways of acquiring software. So, for example, you may be able to go down and buy a product from COMP USA or it may take you six months to be able to do that, depending on your organization. You need to also have a set of documented approaches for scanning the marketplace. There may be dozens of competing products that may or may not be better. You need to have a very good way to evaluate these products and not just take the blurb that’s on the back of the box, or what a vendor happens to be telling you. Once you acquire a product, you need to perform very extensive integration testing.

Northrop. Are there more things I need to consider?

Smith. There sure are. If you want to really use COTS successfully in a product line, once you’ve qualified the potential components, you’re going to need to do a fair amount of adaptation. Despite what your favorite vendor may say, these are not plug and play. You may need to adapt them to your components through wrappers, software, middleware, or other glue code. In addition to that, once you’ve done that, you need to assemble these components. You need to account for interaction between them and your architecture...between them and other components and also, interactions between middleware. In addition to that, you’ve got the COTS people who are going to make periodic updates. You may want to move to a later release or you may not. That’s going to depend on where your product is going. It’s also going to depend on your assessment of this vendor. They may not be in business in five years. Or their evolution strategy may be in direct conflict to your product line approach.

Northrop. I’m confused. This seems like a lot of information about COTS, but how does this all relate to my product line?

Smith. Specifically, when you’re developing a product line, a bunch of potential COTS products could wind up being core assets. For example, there could be databases, graphical user interfaces, and middleware. I was recently working on a project and I found a graphics component available on the Web that cost $50. I was integrating a set of modeling components into the architecture. There are about 200 of these components. Most of them previously had their own graphics packages. So, by investing $50, with some adaptations, I was able to have a common set of graphics that went across all of these components. Other issues, when dealing with core assets include things like stability and maturity of this particular product or this particular vendor. You want to know how long this product has been around, what its reliability is. You want to make sure that its reliability is at least as good as Microsoft’s. You also want to understand how it interoperates with the other components that are in your architecture and what its interfaces and protocols are compared to your own standards and protocols.

Northrop. So, what you’re telling me is that I can use some of these COTS things as core assets, but I need to pick out my own architecture and how it all fits together. Is that true?

Smith. Yes it is.

Northrop. But now I want to build products from these things. How does this COTS work when I’m building products?

Smith. There is a whole set of issues. One of these products could very well fit in as a component that would be part of your products. There’s a whole set of questions that you need to examine. Certainly one issue is that of functionality. What does this actually do? Not only what does the vendor say it does but what does it actually do compared to the other things. There’s the issue of looking at quality attributes. If your system needs availability and performance—those may or may not conflict with each other. You need to be able to pick your own quality attributes and see how well these conform to that. There’s a whole set of business issues dealing with COTS. There’s certainly a strong cost avoidance right up front, but you need to look at the whole set of lifecycle issues. This package may fit 80% of the needs that you actually need. Are those other 20% of needs important or not important? So, you may be giving up something with COTS also. When you look at a COTS product, you need to also consider the flexibility of updating it. Many vendors will tell you that it’s plug and play, but that’s really not necessarily the case. You need to know whether it’s going to require something to adapt or whether it’s more truly plug and play.

Northrop. That’s a big risk. Are there other risks?

Smith. There sure are. COTS components will have unknown interactions with other COTS products and with your software. So, you certainly need to worry about how well behaved that piece of software is. The updates of different COTS components are not synchronized—they’re going to be coming at very different times. They’re going to be doing very different things. You need to consider that. When you replace a COTS product, you’re not going to replace one for one these components because they’re built for very different purposes and they do very different things, so you’re not going to have exact matches when you do your updates. As we all know, configuration management is critical for product line approaches and certainly when using COTS within product lines. As I said before, COTS products need to be adapted to fit into your architecture.

Northrop. Architecture, architecture, architecture. Everybody’s talking about architecture. I don’t have a clue. What’s an architecture? Why’s it so important? I thought you were talking about COTS and now you’re talking about architecture. What’s up with that?

Smith. Well...let me introduce Dr. D. Sign. He’s one of the world’s leading experts in the field of architecture.

Northrop. Okay, Dr. D. Sign. Tell me about architecture. What is it? Why is it important?

Clements. Software architecture is, in my view, one of the most important—if not the most important—core assets that you’re going to build when prosecuting a product line. We like to say that software architecture is the structure or structures of the system. These structures comprise software components, the external divisible properties of those components and the relationships among them. When we came up with scope in product lines—remember that "scope" encompasses the commonality that all the products will share and the variability that the different products will feature. Architecture goes hand- in-hand with that scope. It is going to be the carrier of the commonality. We hope that all the products in the product line will share the same architecture, modulability, extendibility, and variation mechanisms which we’ve built into the architecture so that you can build a product by taking the variability mechanisms off the standard architecture and achieving instant architectures for the individual products.

Architecture is a carrier of the quality attributes in a system by and large. By "quality attributes," I mean things like performance, security and modifiability. So, every product in the system must meet the basic quality requirements, but the scope may identify different products that have different quality requirements. You might have a high-security product, a low- security product, a high-performance product, a low-performance product, all within the same family. You need an architecture that’s flexible enough to perform all of those things. It is the basis for flexible assignment of personnel among your project—you have 250 people right now working on individual things, probably their expertise is limited in large part to the product that they’re working on right now. Wouldn’t it be nice if I could swap those people back and forth flexibly? A common architecture will let you do that because when people learn and are fluent with the common architecture, then they’re automatically fluent with the different products that use it. So architecture is, again, the embodiment of the product line’s commonality. The right architecture is going to help you achieve success in this product line - - it will pull your wagon and it will float your boat. The wrong architecture is, for sure, a recipe for disaster.

Northrop. The thought of being able to leverage my people in a better way is really appealing. As I told you, I just can’t hire any more people, so I’ve got to make use of these 250 people in a much more productive way. It occurs to me that I’ve got to have some really special people to do this architecture thing. What kind of people and how many people do I pick to build this architecture?

Clements. You want to work inside of your organization if you can. We find that one of the essential qualities for product line success is long, deep, domain experience, and you probably have that in your organization. Bringing people in from the outside is probably not the thing to do. Ideally, you certainly have senior designers in your organization that have domain experience. You should choose from among them. Ideally, you’d like to identify a single, perhaps gifted individual or assess a small set of cohesive, coherent, small, integrated design team to turn out the architecture for the product line. Architecture by committee—and I guess there are some examples of that—but by and large, be real suspicious of that as a modus operandi. Conceptual integrity is one of the most important qualities in the products in the system. And you’d like that to flow from the mind of a single architect, or a small group of architects, who subscribe to that. So, you should look for people in your organization who are gifted in this area. They need special skills. First of all, they have to be technically savvy. You want them to be able to understand the latest technology. This will let you survive and move into new markets as the technology changes. They have to have really good communication skills—both input and output. Input: They have to listen to competing requirements and desires on the part of all the product manufacturers. They have to understand what is needed by the architecture. They have to gather all the inputs necessary to make that architectural decision. On the output side, they have to be able to clearly communicate the vision to people and to make them understand why the architecture is going to solve the problem at hand. Also, different organizations have different work models concerning the architect. Some of them are fairly in control. They say, "Here is my architecture and you will use it." Other organizations have different models where the architect says, "Here’s what I think is a really good design to solve your problem. I’d like you to use it. I’d really like to work with your product." Some major organizations have [xxxx???] as their work model too so those architects in particular have to be very good communicators to convey why their solutions are probably the right ones. Thirdly, the architects all have to have people skills. Architecture is the vehicle—it’s the medium through which tradeoffs and conflicts are negotiated. One person is going to want really high security, but another won’t want to pay for that because that person doesn’t need it and wants more performance. Those conflicting needs have to be negotiated and so the architect is often at the center of the whirlwind of controversies like that. They have to remain calm and communicative.

Northrop. As you’re speaking, I’m picturing an individual in my organization and if I could entice her to be the architect, I would need to be able to give more information about a product line architecture. So, given that she has the right set of skills, what extra would she have to know about a product line architecture to be able to do the job?

Clements. Well, product line architectures are not so unlike ordinary system architectures in that there are requirements that they must meet. They must allow their systems to meet their behavioral and quality requirements. For a product line architecture, it’s almost a multi-dimensional approach because there’s a plurality of products for which that must be true. So, each architecture must allow the systems to meet their behavioral requirements. They must allow you to play music, tell what time it is, get songs off the Web—whatever the functionality that’s required. The architecture must let the systems meet their quality requirements: performance, security, modifiability in particular. The architecture must meet the developing organization’s ambitions. The model that we all learned in software engineering class, where somebody writes down the requirements for a system and then tosses that over the transom and it lands with a thud on the architect’s desk, and that’s where the architecture comes from. That model’s wrong; it’s a lie. The developing organization has lots of subtle influences into an architecture that will decide whether it’s successful or not. You might have a group of underutilized people that you’d really like to put to work. The architect may need to take that into account. You may have a tool environment that you’ve already built. It would be a bad architecture that wasn’t compatible with that tool environment. In particular, your ambition is to have a product line so the architecture needs to be able to encompass the commonality and account for the variability across all the products to satisfy that organizational ambition. Finally and critically, and I think obviously, the architecture must be buildable. The most elegant architecture isn’t much use if it takes 300 people and six years to turn out a product line.

Northrop. This may sound like a really naive question, but do architects inherently know how to do this?

Clements. Well, they do it now. But, I think you’re asking: "Do they have to do this anew each time?" The answer to that is almost certainly not because one of the reasons that architects get the big bucks, or they should, one of the things that they’re known for and one of their pieces of craftsmanship is the experience that they have over the years, designing similar systems and people bring that to bear. So, the architect of a product line is probably not going to be created from scratch—that would be highly risky. When architecture typically comes from, certainly out of the architect’s prior experience. We see architects that have had great experiences with certain design approaches—those things can be used again, a lot. We see architects that have had bad experiences with design approaches—you’re not going to see those for awhile, even if it might be the right answer for the next system. The architect’s prior experience, this is certainly a factor. The architect should be familiar with other similar systems in the domain—well, that’s okay—that’s why we picked this person, because she had long, deep experience in the domain. That was a prerequisite and she will bring that experience, that observation to bear on solving this problem.

Patterns and styles—the community is now actually coming to the rescue with architectural patterns, architectural styles. Attribute-based architectural styles is something the SEI is working on. These give architects the beginnings of a kitbag that they can bring to bear to solve a particular problem at hand. The architecture is also going to be heavily influenced by whether or not we want to bring in [???external components or whether we want to write to components ???]

In addition, there’s one other factor that the architecture needs to have. We often talk about architecture in a descriptive fashion. One, the architecture for your system describes the architecture, but architectures need to be prescriptive as well.

Northrop. What exactly do you mean by prescriptive?

Clements. The product line is only going to work if the people building the product use the architecture that’s been laid out for them. In that sense, the architecture is prescriptive—it’s before the fact. It’s not just what was done and how the products were built. But it’s the marching orders for the product organization. So the people working on the product line have to be comfortable with architecture-based or architecture-driven development. They have to understand how to dtake the specifications and write code that conforms to it, because that’s how commonality comes to be exploited.

Northrop. So, my documentation must be really important.

Clements. Documentation is critical, especially in a product line architecture. Architecture in any system is a vehicle for communication. It lets the stakeholders communicate with each other. That only happens in a disciplined manner if the architecture is well documented. But, in a product line, it’s crucial because in a single system, you could imagine that the architect could take his/her vision to the product builders and sit there and coach them, talk to them, and make sure that he/she answered all their questions. A lot of architects spend their time doing that. In a product line, there are going to be 8, 10, 12, 15 projects all using the architecture and it’s just not viable for the architect to be like a butterfly pollinating all the flowers. And so in this case, the documentation is especially crucial. It’s going to have to be clear, unambiguous, and it’s going to let the product builders know enough to be able to do their jobs.

An architecture is also the vehicle for analysis. I am going to have to make sure my system meets its quality attributes, but in a product line I’m going to have to make sure all my systems meet all their quality attributes, so architecture becomes very important as the basis for analysis of a product line.

Northrop. I do have a lot to think about, but I certainly have a much better understanding than I had before.

 

About the Panelists

Linda Northrop has more than 25 years experience in the software development field as practitioner, manager, consultant, and educator. Her primary interests and contributions in the last decade have been in product line engineering, software architecture, object technology, and software engineering education. She has been with the SEI for the past five years. Prior to assuming the management of the Product Line Systems Program, she was lead for the Software Architecture Project, manager of the Education Process Project, and Chair of the SEI Education and Training Review Board. Linda is co-developer of the SEI Improvement Planning Workshop, and has taught software engineering at Carnegie Mellon University.

Before joining the SEI, she was associated with both the United States Air Force Academy and the State University of New York as professor of computer science, and with both the Eastman Kodak Company and IBM as software engineer. As a private consultant, Linda also worked for an assortment of companies on software development projects, assessed and recommended software process. She has developed and delivered a wide variety of software engineering and object-oriented training programs and seminars.

Sholom Cohen is a Senior Member of the Technical Staff of the Software Engineering Institute (SEI) and has been at the SEI for over ten years. Mr. Cohen is a member of the Product Line Systems Program and has authored major technical reports and conference papers on domain analysis and domain engineering methods and an annotated bibliography of domain analysis. He is a contributor to the Product Line Framework and is also the author of reports on Product Line Concept of Operations for the Air Force Electronic Systems Center, the National Reconnaisance Office, and DoD test and training ranges. Besides domain engineering, Mr. Cohen’s current research activities include object technology, software product line practices, and product line introduction.

Prior to joining the staff of the SEI, Mr. Cohen was a member of the software engineering technology branch of the McDonnell Douglas Astronautics Company. In that position, he was a key developer of the Common Ada Missile Packages components and tools.

Mr. Cohen received his BS from the Massachusetts Institute of Technology, an MA in Library and Information Science from the University of Michigan, and an MS in computer science from Columbia University (New York).

Paul Clements is a senior member of the technical staff at the Software Engineering Institute. A graduate of the University of North Carolina and the University of Texas, he is a project leader in the SEI's Product Line Systems Program. His work includes collaborating with organizations that are launching product line efforts. He is a co-creator of the Software Architecture Analysis Method (SAAM), which allows organizations to evaluate architectures for fitness of purpose. He and others are working on an extension to SAAM, which will allow analysis of quality attribute trade-offs at the architectural level. He is co-author of Software Architecture in Practice (Addison-Wesley-Longman, 1998) and more than three dozen papers and articles about software engineering.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us

info@sei.cmu.edu

412-268-5800

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.