Systems Thinking – Abstraction is Your Friend

Some time ago I showed the famous series of Picasso’s bull drawings to our 7-year old granddaughter, Junie. Her verdict? “Picasso got worse with time!” And that’s okay because we interpret things differently depending on what we are looking for. But it’s only okay if we also understand what we are looking for in the first place.

The first four drawings increase the physical details—clearly this is what Junie was looking for—more detail allowed her to better comprehend what it is. Starting with the fifth drawing however, the physical details are replaced with an increasingly abstracted view of what the bull does: can move (the legs), can whack the flies (the tail), can defend itself (the horns), is a source of food (the size) and is able to reproduce (the you know what). This now allows the viewer to freely explore what the actual bull may look like—there are many different types of bulls after all. This is what threw little Junie off—she is yet to appreciate the importance of the function over the form.

And what does this have to do with the Systems Thinking and abstraction? Well, everything as it turns out. Systems Thinking is a holistic approach to analyzing and understanding how the system’s constituent behaviors and elements interrelate, how they change over time, and how they fit in the context of a larger system. While by itself it is not a new concept, it is quickly moving to the forefront of today’s Digital Transformation initiatives in response to the exploding complexities of the today’s and tomorrow’s intelligent and connected systems.

Systems Thinking however does not work that well when applied on the level of physical details of the various implementation disciplines (mechanical, electronics, electrical, software). It only works well when the design is expressed as an intent. And that is the domain of systems engineers and the related Model Based Systems Engineering (MBSE) tools—capturing system design intent symbolically, exploring various implications (ex: system-of-systems interactions), formalizing key architectural decisions, mitigating unintended properties and behaviors and serving as a single source of the truth for all lifecycle stages of the system (from the concept to the retirement of the asset). Do you notice the commonality with the final Picasso’s depiction of a bull? Higher levels of abstractions make very complex problems of functionality much more manageable.

So, what’s the catch? The first catch is that today’s MBSE tools, methodologies, and data structures evolved in a silo that is disconnected from the design details managed by PLM solutions. Now, we all know how much systems engineers like to talk about PLM—but please bear with me. Connecting various interdisciplinary data structures makes sense only if the structures and the connections can be revision controlled and configuration managed in the context of the overall system design. That’s why PLM is key to the success of MBSE abstraction of what the system is supposed to do.

But that’s not the only catch. The other is that today’s legacy PLM solutions were architected to manage design data through the lens of a mechanical structure. This is great for the mechanical domain, but completely inadequate for abstracting electronic intent, in the form of a schematic. Same holds true for abstracting software intent, in the form of functional source code grouping, function specific branching, or feature/option variants. Interdisciplinary design collaboration based on physical BOM expression of these domains simply does not work when managing functionality. Implementation of Systems Thinking, as part of Digital Transformation, is not effective unless all design domains can be abstracted to their functional models. This is how they can be easily connected with the MBSE abstraction of the system under a unified configuration management. Legacy PLM systems simply can’t get there.

In other words, if the goal of your Digital Transformation is driven by the need to manage interdisciplinary physical structures, then the legacy PLM system is likely to be sufficient. If, however, you have reached the transformational point where your product has transitioned from a BOM-driven definition to a model-based system definition, then the success of your Digital Transformation strategy is based on a modern architecture of a PLM Platform capable of expressing functional definitions of every domain—and that’s why Systems Thinking and design abstractions are your friends.

This whole area of Systems Thinking, design abstractions, and interdisciplinary collaboration is extremely important to the market, but it is also a complex issue with many moving parts. Feel free to add your point of view in the comments below and look for future blogs on the subject.

And going back to the drawings of the bull and Systems Thinking—what was the unintended emergent behavior out of this complex interaction of the artist’s intent, influence of his art, thinking of the little Junie and the state of her grandparents’ bank account? Well, it’s that college saving account towards a double major in art and engineering…

Anonymous