Intro to Software Product Lines

This is the first in a series of postings on the topic of Software Product Lines

Consider that software engineers are potentially the worst people to decide what software to engineer.  Their view is typically myopic, founded in satisfying the immediate demand, usually project-based, executed in silos with limited insight into what Teams B and C might be doing.

The ability to look across the teams, across all the Ask on the table, and to decide if there are efficiencies to be gained in more creative and rationalized delivery, is an ability that Business would do well to evolve.  Many of the competencies comprising this ability are both technical and non-technical in nature.  We will explore these over upcoming posts.

A simple non-tech example to illustrate some fundamentals

A slow-food joint makes burgers.  Order a single, a double, or a triple, and the folks in the back will fulfill the order.  Think of these as small kitchen projects.  They start from scratch for each order – remove the ingredients from various refrigerator units, get the spices down from the shelves, add quantities by eye, mix by hand, shape to arbitrary design, throw the burger on the grill, bun ’em up, apply condiments, side-plate the fries, clean-up and put away all.  A long line of preparers queues up to do the very same as the kitchen is small, and the culture is such that you wait your turn for the limited space and resource, do not work concurrently or in tandem in the kitchen across orders – even for those coming from a single table! –  and you don’t breathe a word to anybody about the contents of your order.  Customers, at first delighted knowing that their food is fresh and made to order, soon become disenchanted with the long waits, the staggered arrival of food, the lack of uniformity in the product, and the declining mood of the eatery’s workers.

Sounds pretty ridiculous, doesn’t it?  And I bet it’s relatively easy to name at least 2 or 3 pain-points in the governing policy, process and the culture’s behavior, that if addressed, would make the establishment more efficient, customer-friendly, and profitable.

A simple tech example to extend the point

• Business Unit 1 wants to create new product offering for the Customer (or client, or student, or insured, or employee, or patient, or sovereignty, or channel, or some other entity more appropriate for your work and industry),
• Business Unit 2 wants to enhance an existing product offering for the Customer.
• Business Unit 3 needs to implement regulatory mandates affecting the Customer.

You kick off 3 separate projects.  You size and estimate, staff, plan and schedule each project, and run each in relative isolation of the other.

It is not long before you begin to resemble the slow-food eatery.

The three project teams begin to work on Customer, meaning source software and data assets, as well as the physical assets where those are instantiated, to fulfill their respective delivery obligations.  Team 2 overwrites the work of Team 1.  Team 3’s business logic is contrary to the functionality that Team 1 desires.  Team’s begin to rig local instances of databases to avoid the queue that’s building there around the architecture and DBA function.  Test data management teams begin to back up, processing 3 separate requests.  Integrated testing environments are booked, delaying Projects 1 and 2, since the Regulatory nature of Project 3 trumps, allowing them sole residence there until further notice.  Project 3 though is somewhat dependent on Project 2’s enhancement.

Business Unit 1 begins to adjust their revenue projections based on delayed entry into the market.  Even the CEO is a bit concerned as she foresees impact to brand.  Regulatory is starting to talk about major fines due to lack of compliance.  In a few months customers will begin to wonder if the grass is greener on your competitor’s side of the valley.

And the music goes round and round – and it comes out . . .

Here – the Uber Effort

In the spirit of this writing, I will reuse an earlier paragraph:

Sounds pretty ridiculous, doesn’t it?  And I bet it’s relatively easy to name at least 2 or 3 pain-points in the governing policy, process and the culture’s behavior, that if addressed, would make the establishment more efficient, customer-friendly, and profitable.

Here’s my list of observed pain points gleaned from the example above.  For starters, the Business would do well to have:

1. A holistic view of the demand from the business units.
2. An architecturally integrated view of the work that needs to be performed across the 3 projects, especially since they all 3 are touching on a common set of Core Assets (more on this in future posts).  Consider that what was once 3 distinct and dis-integrated Analysis & Design phases, one for each of the projects, will collapse to One, with each effort inheriting a grander design for the benefit of all.
3. An integrated Production Plan and schedule for delivery that creates efficiencies in all 3 efforts (appreciate that the line between the 3 projects will blur into something else of greater benefit).  This will create efficiencies in downstream practices for Test Data Management, Environments Provisioning, the allocation of third-party and vendor resources, and much more.
4. A clear attributing of dependencies and priorities to serve as decision-making guidelines.

We will continue to explore these topics in an upcoming series of posts.  Next week, more on the Business Case for software product line practices, and Core Assets.

This art is paid for and used under Non-Exclusive license agreement with Condé Nast.
Cartoonist: Bruce Eric Kaplan, The New Yorker Collection
Issue Publication Date 01/11/1999
The Cartoon Bank TCB-40677, Image ID: 8298

© Michael C. Simonelli, onthegocio.com, 2013