Archive
The SS2000 Epiphany
I’m currently designing/writing the software component of a new air surveillance radar data processor that interfaces the radar to an existing, legacy combat control system. In order to test the software, I have to interact with the combat system’s GUI to issue radar commands and ensure that detected targets are received and displayed properly on the combat system display.
As the figure above shows, the acronym “SS2000” appears prominently on the GUI display. When I saw it for the first time, a sense of deja-vu came over me, but I couldn’t figure out why. After a few days of testing, I experienced an AHA! epiphany. Out of the blue, I suddenly remembered where I saw “SS2000” before. Ding!
Ya see, back in the early 2000’s, I read a Software Engineering Institute (SEI) case study on the concept of “software product lines“. It featured a Swedish company called “Celsius Tech“. The report meticulously described how Celsius Tech painfully transformed itself in the 90’s from an expensive developer of one-off naval combat systems into an efficient, low cost, high quality, producer of systems. Instead of starting from scratch on each new system development, Celsius Tech “instantiated” each new system from an in-place, reusable set of product line assets (code and requirements/design/test documentation) that they diligently built upfront.
I was so enamored with Celsius Tech’s technical and financial success with the concept of software product lines that I concocted an executive summary of the report and aggressively pitched it internally to everyone and anybody who would listen. But alas, I utterly failed to jumpstart an internal effort to transform my employer at the time, Sensis Corp., into a software product line enterprise.
The name of Celsius Tech’s software product line infrastructure was…… SS2000 = Ship System 2000! But wait, the story gets eerily better. Celsius Tech was subsequently purchased by Swedish defense company Saab AB (yes, they used to make cars but they sold off that business a long time ago) – the same company that bought my employer, Sensis Corp., in 2011. As a result of the buyout, I currently work for Saab Sensor Systems. Quite the coincidence, no?
Boulders And Pebbles
When embarking on a Software Product Line (SPL) development, one of the first, far-reaching cost decisions to be tackled is the level of “granularity” of the component set. Obviously, you don’t want to develop one big, fat-ass, 5 million line monstrosity that has to have 1000s of lines changed/added/hacked for each customer “instantiation“. Gee, that’s probably how you operate now and why you’re tinkering with the idea of an SPL approach for the future.
On the other hand, you don’t want to build 1000s of 10K-line pieces that are a nightmare for composition, configuration, versioning and integration. For a given domain, there’s a “subjective” sweet spot somewhere between a behemoth 5M-line boulder and a basket of 10K-line pebbles. However, if you’re gonna err on one side or the other, err on the side of “bigger“:
…beware of overly fine-grained components, because too many components are hard to manage, especially when versioning rears its ugly head, hence “DLL hell.” – Martin Fowler (UML Distilled)
The primacy of system functions and system function groups allows a new member of the product line to be treated as the composition of a few dozen high-quality, high-confidence components that interact with each other in controlled, predictable ways as opposed to thousands of small units that must be regression tested with each new change. Assembly of large components without the need to retest at the lowest level of granularity for each new system is a critical key to making reuse work. – Brownsword/Clements (A Case Study In Successful Product Line Development)
A Risky Affair
The figure below shows the long term savings potential of a successful Software Product Line (SPL) over a one-off system development strategy. Since 2/3 to 3/4 of the total lifecycle cost of a long-lived software system is incurred during sustainment (and no, I don’t have any references handy), with an SPL infrastructure in place, patience and discipline (if you have them) literally pay off. Even though short term costs and initial delivery times suffer, cost and time savings start to accrue “sometime” downstream. Of course, if your business only produces small, short-lived products, then implementing an SPL approach is not a very smart strategy.
If you think developing a one-off, software-intensive product is a risky affair, then developing an SPL can seem outright suicidal. If your past history indicates that you suck at one-off development (you do track and reflect upon past schedule/cost/quality metrics as your CMMI-compliant process sez you do, right?), then rejecting all SPL proposals is the only sane thing to do…. because this may happen:
The time is gone, the money is gone, and you’ve got nothing to show for it. D’oh! I hate when that happens.
Related Articles
The Odds May Not Be Ever In Your Favor (Bulldozer.com)
Out Of One, Many (Bulldozer.com)
The Odds May Not Be Ever In Your Favor
The sketch below models a BD00 concocted reference cost curve for a single, one-off, software-intensive product. Note that since the vast majority of the accumulated cost (up to 3/4 of it according to some experts) of a long-lived product is incurred during the sustainment epoch of a product’s lifetime, the graph is not drawn to scale.
If you’re in the business of providing quasi-similar, long-lived, software-intensive products in a niche domain, one strategy for keeping sustainment costs low is to institutionalize a Software Product Line Approach (SPLA) to product development.
A software Product Line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. – Software Engineering Institute
As the diagram below shows, the idea behind the SPLA is to minimize the Total Lifetime Cost by incurring higher short-term costs in order to incur lower long-term costs. Once the Product Line infrastructure is developed and placed into operation, instantiating individual members of the family is much less costly and time consuming than developing a one-off implementation for each new application and/or customer.
Some companies think themselves into a false sense of efficiency by fancying that they’re employing an SPLA when they’re actually repeatedly reinventing the wheel via one-off, copy-and-paste engineering.
You can’t copy and paste your way to success – Unknown
If your engineers aren’t trained in SPLA engineering and you’re not using the the terminology of SPLA (domain scoping, core assets, common functionality, variability points, etc) in your daily conversations, then the odds may not be ever in your favor for reaping the benefits of an SPLA.
Related articles
- Out Of One, Many (bulldozer00.com)
- Product Line Blueprint (bulldozer00.com)
What’s Next?
I was browsing through some old powerpoint pitches and I cam across this potentially share-worthy graphic:
I’m sorry for the poor resolution. I was too lazy to spruce it up.
Product Line Blueprint
Here it is, the blueprint (patent pending) you’ve been waiting for:
Need a little less abstraction? Well, how about this refinement:
Piece of cake, no? It’s easy to “figure out“:
- the number of layers needed in the platform,
- the functionality and connectivity within and between each of the layers in the stack
- the granularity of the peer entities that go into each layer and which separates the layers
- the peer-to-peer communication protocols and dependencies within each layer
- the interfaces provided by, and required by, each layer in the stack
- what your horizontally, integrate-able App component set should be for specific product instantiations
- how much time, how much money, and how many people it will take to stand up the stack
- how many different revenue-generating product variants will initially be needed for economic viability
- how to secure all the approvals needed
- how to manage the inevitable decrease in conceptual integrity and increase in entropy of the product factory stack over time – the maintenance problem
Perhaps easiest of all is the last bullet; the continuous, real-time management of the core asset base IF the product factory stack is actually built and placed into operation. After all, it’s not like trying to herd cats, right?
Please feel free to use this open source (LOL!) product line template to instantiate, build, and exploit your own industry and domain specific product line(s). Enough intellectualizing and “strategizing” about doing it in useless committees, task forces, special councils, tiger teams, and blue ribbon panels. There’s money to be made, joy to be distributed, and toes to be stepped on; so just freakin’ do it.
Is this post still too abstract to be of any use? Let’s release some more helium from our balloon and descend from the sky just a wee bit more so that we can get a glimpse of what is below us. Try out “revision 0” of this blueprint instantiation for a hypothetical producer of radar systems:
Did you notice the increase in tyranny of detail and complexity as we transcended the 3 levels of abstraction in this post? Well, it gets worse if we continue on cuz we don’t yet have enough information, knowledge, or understanding to start cutting code, building, testing, and standing up the stack – not nearly enough. Thus, let’s just stop right here so we can retain a modicum of sanity. D’oh! Too late!
Findings And Recommendations
The National Academy of Sciences is a private, nonprofit, self-perpetuating society of distinguished scholars engaged in scientific and engineering research, dedicated to the furtherance of science and technology and to their use for the general welfare. Upon the authority of the charter granted to it by the Congress in 1863, the Academy has a mandate that requires it to advise the federal government on scientific and technical matters.
Via the publicly funded National Academies mailing list, I found out that the book “Critical Code: Software Producibility for Defense“ was available for free pdf download. Despite being committee written, the book is chock full of good “findings” and “recommendations” that are not only applicable to the DoD, but to laggard commercial companies as well.
Not surprisingly, because of the exponentially growing size of software-centric systems and the need for interoperability, “architecture” plays a prominent role in the book. Here are some of my favorite committee findings and recommendations:
Finding 3-1: Industry leaders attend to software architecture as a first-order decision, and many follow a product-line strategy based on commitment to the most essential common software architectural elements and ecosystem structures.
Finding 3-2: The technology for definition and management of software architecture is sufficiently mature, with widespread adoption in industry. These approaches are ready for adoption by the DoD, assuming that a framework of incentives can be created in acquisition and development efforts.
Recommendation 3-2: This committee reiterates the past Defense Science Board recommendations that the DoD follow an architecture driven acquisition strategy, and, where appropriate, use the software architecture as the basis for a product-line approach and for larger-scale systems potentially involving multiple lead contractors.
The DoD funded Software Engineering Institute, located at Carnegie Mellon University, has produced a lot of good work on software product lines. Jan Bosch’s “Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach” and Chapters 14 and 15 in Bass, Clements, and Kazman’s “Software Architecture in Practice” are excellent sources of information. The stunning case study of Celsius Tech really drove the point home for me.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 