Salion, Inc.: A Software Product Line Case Study
5 Conclusions and Lessons Learned
This section synthesizes some of the major lessons we learned from Salion's experience with the software product line approach.
5.1
Joyous Software Development Process, Part 1: Unified Vision
One of the overriding themes that makes the Salion story compelling is the company's devotion to making an overall business plan, letting the plan percolate down through the organization, and having everyone adhere to it in spirit and in practice. In short, everyone at Salion is on the same page. The executives have succeeded in instilling everyone with the business objectives and producing a unified organization in which everyone is working toward the same goals. The architects understand beyond a doubt that the architecture is responsible for providing the capabilities required to carry out the business plan. In turn, they have succeeded in instilling architectural principles in the group that supports that plan.
This unified view is certainly made easier because of Salion's small size, but it would be a mistake to imagine that this was all there was to it. Salion's managers spend a great deal of effort putting people on the same page, and they do it at three levels:
In addition, the proactive inspections that the chief architect takes upon him/herself help assure high architecture and process conformance.
An example of how the business and technical sides of the house work together
seamlessly is the company's option-licensing strategy. Recall from
Section 2.3 that each system Salion ships is a suite of individual products from which its customers can pick and choose. Early on, Salion had to decide whether to ship a system to a customer as a set of the chosen products or as an entire system with only the chosen products enabled. This decision had business and technical ramifications. The marketers loved the entire-system approach, because it made it easier for them to sell license "toggles" to turn on new products. It was also appealing technically, because it was simpler: each customer was shipped the same system. Building, installation, maintenance, and upgrades were vastly simplified, and that appealed to the CFO.
The decision to ship the total system was not by itself particularly controversial, but the process for making it shows how business, financial, marketing, and technical people at Salion all speak exactly the same language and sit at the same table.
Salion's devotion to its business plan imbues developers with a sense of ownership over the company's components and makes developers conscientious about stabilizing those components for reuse. Each component is important for the success of the company's product line.
5.2
Joyous Software Development, Part 2: The Best of All Worlds
Though certain essential activities and practice areas are common to any successful software product line effort, we don't advocate any specific, prescribed methodology because many practices are relevant for each practice area. Each organization needs to choose those practices that fit its unique context--a context that encompasses culture, talent, business goals, and the product line approach.
Salion has been both selective and pragmatic about assembling the specific practices to effect its product line business and technical strategy. It has chosen with agility and care best-of-breed techniques and then pruned and combined them to its advantage. Salion's approach to software product lines is a unique and successful intertwining of techniques and principles from RUP, VRAPS, Extreme Programming, and the SEI with the added automated support provided by Gears.
Salion has evolved its most
effective blend of practices for software product lines with a true continuous
improvement mentality. Throughout, it has religiously maintained a strong
adherence to process discipline. When Salion hacked, it regretted it, and
that regret strengthened Salion's resolve to be more disciplined about
following its defined processes. Recently it conducted a Capability Maturity
Model ® (CMM®) self assessment with a resultant
"almost Level 3." Salion has resolved to make the changes necessary for it to
be a veritable Level 3.
5.3
Customization Versus Configuration
The conventional wisdom in software product line production is that the core assets should be tailorable using built-in variation mechanisms that render the components generic over a wide range of application instances. Component generators exemplify this philosophy; the use of configuration parameters is a widely adopted variant. The appeal is obvious. Product building becomes a matter of "generate and integrate," with a minimum of source code writing.
Salion knew from the beginning that its products would have to be variable over several dimensions. For example, every customer was going to want to use customized forms, so Salion set about writing generic forms software. Given this infrastructure and a statement of a customer's reporting needs, Salion could quickly generate or instantiate a forms component that would satisfy the requirements.
What sounded like a good idea turned out in practice to be a keen disappointment. After eight months of development time, Salion had a generic forms module that didn't work, was much too overblown for what was actually needed, and failed to help the company meet the real requirements of its customers. Recently, the whole thing was thrown out.
Salion experienced the same disappointment and frustration with customized reports. Trying to build a generic component in the absence of actual customer requirements resulted in wasted time and a technical failure.
These and similar lessons have given Salion a completely new outlook on achieving variation. Now its first inclination is to provide variation through customization, not configuration. This means that Salion will modify or rewrite the necessary core assets to produce a version of the system that satisfies a particular customer. As it gains more knowledge about a particular domain, it may eventually be able to design a configurable (or even generative) infrastructure for the domain. For instance, of the three major variation points of Salion's products (forms and screens, reporting and export, and bulk load), the company suspects that there's a framework lurking in the first two, which may one day be teased out in a practical fashion. But for now, customization is the watchword.
Many other companies also produce new products by simply changing what they have, but they quickly run into a wall of complexity while trying to manage the combinatoric variations present in separately evolving systems. This occurs because they clone the entire system to produce new versions. Salion never loses sight of the fact that it is producing a single product line with a small number of variations. Hence, it can keep tight control over the vast majority of the parts that are common to all family members. Undoubtedly, the Gears tool plays a large part in maintaining this control, both intellectually and technically, as it was designed explicitly to serve this purpose.
Another example of an ill-fated configurability effort came when Salion discovered that its first customer did not use the OAG standard object data model that Salion (and much of the automotive industry) had adopted. After a six-week analysis, Salion decided that the right solution was to build a configurable data item subsystem, so its products could quickly adapt to whatever object models a customer was using. Now, in retrospect, Salion is trying to eliminate this subsystem, because subsequent analysis has revealed that in fact the OAG model would have done nicely after all--it turned out to be possible to map all 145 features in this customer's data model right to the OAG framework.
5.4
Risk Management Culture
A new organization with no marketplace experience in its chosen application domain runs a risk in embracing a product line approach. Salion further exacerbated this risk by selecting previously untested combinations of approaches--namely, RUP, Extreme Programming, VRAPS, and Gears. However, at no point has Salion been blind to the risk it is assuming. Instead, it has embraced a rigorous set of risk management practices that are informed by the metrics it collects.
Salion mitigated the risk of its "green field" product line by proactively arriving at a requisite level of domain understanding and by choosing a reactive approach to product lines. With its series of "joyous" meetings at multiple levels, Salion engages in risk analysis and introspection that has led to risk mitigation strategies for undercutting what could develop into costly problems. Its total approach is a well-balanced act of innovation coupled with risk management.
Moreover, Salion has capitalized on its very nature as a small start-up unshackled by the cultural barriers and ingrained infrastructure that are so hard to dismantle in larger, more established companies. Salion recognized that it can shape its culture as it goes and has been nimbly doing so, all the while skirting risks that could prove to be land mines.