| |
Some years ago a very bright and enterprising young manager noticed that several of his people were doing essentially the same work. It occurred to him that instead of having 5 different engineers independently designing the same feature, perhaps it would be smart to develop the feature once and then just use it in 5 different products. Should be cheaper to develop since you're only doing it once, and all the products in the product line will automatically work the same since they are using the exact same design. The manager was promoted for his ingenuity.
Vice President of Engineering |
Things were going along well until one day the team discovered a feature that they wanted to work a little differently on some of the products. The answer was obvious: this is really two different features. So the now seasoned and successful manager agreed to split his team in two; he sent one sub-team off to develop one variant of the feature, and another sub-team off to develop the second variant. Our happy and successful manager moved to a corner office and was given the title Vice President of Engineering.
In the course of time, however, the customers started getting a little finicky. Some customers wanted the feature to work this way and some liked it better that way. Some customers wanted an extra "on / off" switch; others wanted a real time clock that automatically ordered breakfast at sunrise. Each time a customer wanted something a little different, our friend in the corner office applied his tested and proven approach - he split off another sub-team to go off, develop, and maintain a new variant of the feature.
One day a bring and enterprising young manager came into our friend's corner office and announced "I've just discovered that we have 10 different engineers who are independently doing roughly the same thing - we're maintaining 10 variants of the same feature!." The engineering sage realized he'd been snookered. His underling was right and something had to change. Clearly the customers expectations were out of hand; it was quite unreasonable for them to expect to control every detail of the product. After all, the products are dependable and of high quality; the engineering group is continually under pressure to keep costs under control, so we've just got to stop building so many variants in response to every customer's whims.
Vice President of Marketing |
At the next meeting of the Vice Presidents, our always cool Vice President of Engineering announced his plans to save money for the company; we'll choose the best variant of each feature and standardize on that variant across the product line. It so happened, however, that at this meeting there was the occupant of another corner office; she was tall, feisty, had red hair, and wore the title "Vice President of Marketing". In response to this proposal she cooly mentioned that meeting the customers at their point of desire was working well for the company, and besides the competitors were offering whatever the customer wanted. A discussion ensued in which the red haired wonder tickled the senior executives' ears with stories of the Experience Economy - something about giving the customer an excellent, memorable experience as the best, perhaps only, way to gain customer loyalty and forestall commoditization. She was convincing, but the group still liked the notion of saving money, and the company did, after all, have 10 different sub-teams maintaining variants of essentially the same feature. So our somewhat disheartened friend went back to his corner office with the assignment to improve the ability to meet the customer at their point of desire AND to save money in the process.
The next week our hero gathered his wits and called in the young manager who had brought the dire situation to his attention and ask whether he had any suggestions. The young manager said, why yes, he had thought a bit about it. Back when he was getting his Master's Degree at Berkeley he had heard of a few people working on a set of software engineering practices and patterns called Software Product Lines. As any diligent young manager would, he had already looked up some information on Software Product Lines and had had concluded that this was exactly what the company needed.
The enterprising young manager had discovered a straightforward road-map for building a scalable, highly productive Software Product Line:
- Form a "Core Assets" team; task them with re-engineering the product line from the ground up, creating a framework for reusable components which can be employed as needed in products.
- Task the Engineering IT group to create a Oracle web application to manage the software components being developed by the Core Assets team. They should probably use XML - it pretty much works for everything.
- The Core Assets team also needs to develop the reusable components themselves, in addition to the framework.
- Instruct the existing Product Teams that in the future their products will be built by assembling the to-be-created software components using the to-be-created web application -- and that they should scrap their current plans in favor of this new one.
- The teams responsible for writing user's guides and application notes for the customers, and for government certifications could pretty much work the way they do today. Sure, there'll be some redundancy and some tedious cross-checking, but hey it's just documentation and nobody expects that stuff be 100% accurate anyway.
The Engineering VP was impressed with the young man's initiative and he agreed that the "Software Product Line" notion was moving in the right direction, but he wondered if there might be a way to get there with baby steps rather than jumping off a cliff. He asked the perfunctory questions about team experience, risks, and cost. The industrious young manager answered that most of the team members had heard of component frameworks before - one had even seen a presentation on component frameworks at a conference. No, they have never developed a component framework from scratch, but they were pretty smart and were certainly dedicated. The team had plenty of experience building the existing product line using non-component methods, and besides there were a few commercial component frameworks (Microsoft COM, Java Beans, and Enterprise Java Beans) which the team could look at to get some ideas. Further, the Engineering IT group had built plenty of applications over the years and they knew Oracle like the back of their hand, and a few of them had even used XML for a project last year. Regarding getting the Product Teams on board, the young manager thought that might be a good job for the Engineering VP himself, rather than for a working-level manager. Regarding cost, the young manager thought they might be able to have something running in a year or two, but cautioned that sometimes there are cost and schedule overruns when venturing into new territory. But the payoff seemed so obvious that one ought not be put off by a little bit of uncertainty.
The Engineering VP, whose "reality bites" experience was starting to show, asked whether the to-be-created product line would improve their ability to meet the customer at their point of desire. The young manager wasn't completely sure, but since the web application hadn't been built yet they could add that to the list of requirements.
Wondering what good old Red, his nemesis from Marketing, would think of this new plan, our hero glanced out the window at the birds on the neighboring building and mused on how nice Hawaii was this time of year.
Just as the industrious young manager was walking out the door, the Engineering VP thought of one last question: "Is there anyone out there who's done this kind of thing before? ..."
|
|
