- This event has passed.
From Systems Engineering to System Family Engineering
December 15, 2022 @ 10:00 am - 11:00 am UTC-8
Virtually all systems engineering is performed in the context of a product line – a family of similar systems with variations in features and functions. Hardly anyone builds just one edition, just one flavor, just one point solution of anything. When presented with this hypothesis, the initial reaction from systems engineers is often disagreement. However, when pressed for examples where organizations build a complex system without deriving from an existing similar system and without the intent of building other similar systems, examples are not readily forthcoming.
Because of the inherent assumption in the system engineering community that systems engineering is primarily a methodology for building a single system, systems engineering methods and tools have traditionally focused on how to build the individual point solutions within a family rather than how to engineer a system family as a whole. This mismatch comes with significant risks. A recent study by the analyst firm Tech-Clarity, involving surveys of nearly 200 company leaders engineering products and systems, the number of product and system configurations is largely viewed as the top and growing source of complexity, which results in one of their top two business challenges. Engineering complexity slows progress and leads to defects, errors, and omissions, which in turn leads to the business risks of delays, budget overruns, recalls, system failures, and opportunity losses.
When systems in a system family are engineered as individual point solutions, techniques such as clone-and-own, branch-and-merge, and reuse repositories result in ever-growing duplicate and divergent engineering effort. Trying to manage the system family commonality and variation among these individually engineered systems relies on tribal knowledge and high bandwidth, error-prone interpersonal and document-based communication among different subject matter experts. Furthermore, when each engineering discipline adopts a different ad hoc technique for managing variations among the members of the system family, the result is error prone dissonance when trying to translate and communicate across the lifecycle.
This is self-inflicted complexity, over and above the complexity inherent in the systems being engineered. It consumes engineering teams with low-value, mundane, replicative work that deprives them of time and energy that would be better spent on high-value innovative work that advances system and business objectives. As more and more of systems engineering moves to model-based systems engineering (MBSE) where documents and tribal knowledge are replaced with sophisticated webs of digital information, the complexity of managing system family variation using tribal knowledge and other non-digital engineering techniques becomes an intractable mismatch.
Engineering a product line, or system family, holistically is much more effective and efficient than engineering each of the systems individually. This requires engineering the product line as a single System of Interest (SOI), with variations formally defined and managed to support the individual system instances within the family. This shift requires INCOSE and the engineering industry at large to elevate our thinking from Systems Engineering to System Family Engineering.
Feature-based Product Line Engineering (PLE), as defined by the new ISO/IEC 26580 standard, is the modern digital engineering approach to System Family Engineering. This presentation will explore how Feature-based PLE enables organizations to elevate from Systems Engineering to System Family Engineering. It plays an essential role in the new digital engineering age, offering engineering economies in effort, cost, time, scale and quality in some of the industry’s most challenging and complex system families.
For many organizations, Feature-based PLE represents a shift in engineering approach that requires organizational change along with commitment from engineering and business leadership to make that change. The return-on-investment (ROI) to justify the organizational change is in most cases compelling, based on the elimination of low-value, mundane, replicative work, with doubling, tripling and larger improvements in engineering metrics such as effort, cost, time, scale, and quality.
In consideration of this ROI, the question to leadership is, “What if your engineers could do their normal day’s work before lunch; what would you have them do in the afternoon?” There are many answers to this question, all of them good.
Presented by Dr. Charles Krueger, CEO and founder of BigLever SoftwareRegister here