Telling the Story
There are many ways to start a behavioral-model presentation. Somewhat unconventional is showing the working simulation first, even before the EFFBDs themselves. This follows the concept of the Golden Circle.
The WHY: The behavioral logic makes the simulation work, it shows the interactions between your Vehicle Management Computer (VMC) and other components in the whole aircraft (what the audience really cares about).
The HOW: You explain the behavioral logic with the Enhanced Functional Flow Block Diagrams (EFFBDs) (what confirms your tool and methodology).
The WHAT: The audience can now read the EFFBDs and re-trace the logic themselves without your help.
This strategy only works when you have a working simulation at the system-level, which is not always the case when you conduct the initial review meeting. A subsystem or component-level simulation could be useful but does not send as strong a WHY message. No available simulation at all is okay; you will just have to work with a more abstract WHY.
You are now ready to show your beautifully assembled EFFBD on the screen. It is beneficial to explain the EFFBD structure briefly: nodes, lines, and constructs. That is the minimum required knowledge to follow the diagram flow. You would be surprised how quickly the less-frequent or casual users forget the notations. And, the non-users would appreciate the help to not get lost right out of the gate. On the other hand, avoid explaining the whole metamodel content at the start of the meeting. That would only overwhelm most of your audience.
What I usually like to do next is show the audience a 30,000-foot view of the behavioral structure. That means two things.
One, if the behavior requires a lot of decomposition, I would start at the highest relevant level and show the decomposition structure down to my leaf-level functions. In a holistic approach to systems engineering and model-based systems engineering (MBSE), it is essential to understand both the interactions between the parts and how the parts work as a whole. Your audience needs to understand the context in which your VMC works with other components and also works to fulfill the aircraft’s overall functions. The decomposition structure walk-through prevents the reductionist thinking, which will often lead you and your audience down the path of a fuzzy WHY. If we are only looking at how the VMC works at the VMC level, why do we care about it at all at the aircraft level?
Two, if my behavior is shown in a single flat diagram with a lot of nodes, I would zoom out on the diagram until the whole thing is fitted on the screen. The text might be too small to be legible but zooming-out allows you to explain the structure of the flow. This is often the case when you build an operational activity model (DoDAF schema) and want to show all activity nodes on the same diagram for human’s information consumption. The narration could be:
“There are four parallel branches, one for our fighter aircraft, one for the enemy aircraft, one for the allied aircraft, and one for the enemy surface-to-air launcher. The big loop structure here is to denote a continuous scan by the SAM radar…”
The bird’s-eye view of the structure allows you to prepare your audience for the onslaught of information to come. It gives them a map and some sense of direction.
One of the challenges of explaining a functional flow is having the discipline to stick to the point when the flow splits. An example is a Select (OR) construct with multiple branches, each with an assigned probability. Do you try to explain all of the branch options now or focus on a single path? What about a Concurrency (AND) construct? And my most favorite flow to explain: A Multiple-Exit inside a Loop construct? The problem here is that, your speaking is linear and so is the audience’s listening. But a functional flow is rarely strictly linear. The engineering information you are conveying to the audience can get complex and overwhelming rapidly. The communication strategy here, as it turns out, is fairly simple: What is the point are you trying to make? (a mini WHY within the bigger WHY, if you will).
If a stimulus-response behavior is what you are after, follow that specific flow from start (stimulus) to end (response), don’t branch off at any split. Have the discipline to avoid any deviation from that path, no matter how important other branches of the construct are to the overall behavior. You can always come back to them in a second, third, etc. pass-through. This scenario is common when you explain an operational activity model where the focus is the interactions between a system and an external actor.
If a combination of possible conditions is what you are after, stay at the split to explain the meaning of all shown paths. You can use layman’s terms to describe the outcome at the end of each path without tracing out the flow at this time. This allows the audience to understand the Selection (or Concurrency or Multiple-Exit) logic without the burden of understanding further modeling logic down on each path. This scenario is common when you explain a functional behavior where multiple modes are available after a function has executed.
As you go along, the audience might get saturated with new concepts and information. They may need to look at a function, its allocation, and its inputs and outputs outside of the metamodel structure. When this happens, the Property Sheet is your friend. It shows the function’s description, attributes, relationships and relationship targets, all in one neat window. A diagram can get very busy with crowded nodes and crossing lines. An input to a function, for example, may even be out of sight in a particular view. Opening up the property sheet gives everybody a much-needed break from the graphics, and the opportunity to focus on just enough information to understand a function by itself.
Remember that you can resize and move things around while presenting the information in GENESYS. The EFFBD is not a static picture. Resize nodes to clarify their names if they are cut off by the border. Move items close to their related function if you need an extended discussion about such entities. You can even move functions and stretch out a branch deliberately to emphasize the timing and order of execution. At my previous job a long time ago, I once asked a systems engineer why he placed functions performed by different subsystems in a sequence construct (instead of in a concurrency construct with triggers between functions). He answered, “because the Customer wants to see them in a specific order.” I told him that he could build the behavior correctly with the needed concurrency structure, and just stretch the diagram out to denote timing and sequence of execution. The integrity of the metamodel structure must not be violated in favor of human’s information consumption. But, with a little bit of graphics manipulation, you can always make a sound metamodel structure look good for story-telling as well.
Other Presentation Tips and Tricks
A wise man once said, “there are no stupid questions.” He was neither genuine nor wrong. My interpretation of the saying is some questions are undeniably stupid, but if you seek after a successful discussion, treat all questions as valid. In a productive discussion about behavior, you will be bombarded with questions. Some are genuine, though quite naïve. This is normal, even from the most knowledgeable team members. I have seen the smartest design engineer broken by a triple-loop-multiple-exit construct. On the other hand, some questions are nothing but a straight challenge to your credibility as an engineer. This is quite all right, too. Meaningful behavioral diagrams, when done correctly and holistically, tend to offend the reductionist thinking. To win hearts and minds is not to rebuke the “stupid questions” but to treat them as an opportunity. It is your opportunity to build a rapport with your audience. If they feel that you are patient and open to answering their questions, they will be more patient and open to your different and new perspective.
When asked how you know something is true, you must be able to answer it with your own knowledge, and put your own credibility on the line. Never rely on someone else as your “expert witness”. At my last job before joining Vitech, I heard this in meetings all the time:
[A speaker explains a concept]
[Someone asks how the speaker would prove it is true]
Answer: “I talked to Alex (a subject matter expert (SME) who might be familiar with the concept) yesterday. He agreed with my assessment.”
I cringed every time this type of explanation was used. If Alex is found to be a false SME one day, is your work totally worthless then?
If you have to invoke an expert opinion as your primary defense for your credibility, your Golden Circle is out of balance. Your WHAT is inconsistent (all of your work should be consistently defensible); your HOW is undisciplined (your engineering is so weak that you have to rely on someone else’s reputation), your WHY is unclear (if a strong aircraft design is your ultimate goal, why focus on a cheap review approval?). When the Golden Circle is out of balance, what you say and do seems ingenuine to your audience and customers. You look like you do not know what you are talking about. You have failed to create lasting trust and loyalty.
Be Inspired and Go on Inspiring
I hope this discussion gives you a fresh perspective on the effective communication with your team. I had some limited success in introducing CORE and GENESYS behavioral diagrams to a broad audience in my past Defense/Aerospace experiences. But, my strategy was largely a combination of tips and tricks and random gut feelings. My discovery of Simon Sinek’s Golden Circle helped put the fuzzy “best practices” into clear concepts, and clear concepts into successful applications. When we try to “sell” people something, a product, an idea, a business, they do not really buy our WHAT. At least, not consistently and with a cult-like following. They buy our WHY. Not because they love our WHY, but because our WHY aligns with their WHY, and inspires their WHY.
Our work in behavior or in any other aspects of model-based systems engineering will only be recognized and adopted by a large and diverse community if our cause and purpose is clearly communicated. Most team members will not care how beautifully our diagrams are crafted unless our ultimate cause and purpose aligns with theirs. If we have succeeded in communicating our WHY, work hard to keep the Golden Circle in balance: the clarity of WHY do MBSE, the discipline of HOW to do MBSE, and the consistency of MBSE products. Be aware of “the split”, where our WHY and WHAT start to diverge as we become more successful over time. “The biggest challenge is Success.” It is less likely to happen within one meeting with our team members. But, as our tool and methodology become more accepted and utilized, we might be tempted to start shifting the focus of MBSE to “better looking graphics” and “cool integration features”, rather than our original purpose. Never let our WHY go fuzzy.
Whether you are still working toward discovering your purpose in systems engineering, or are already enjoying the success in the field, I hope you will go on to inspire others. Systems engineering is the connective tissue that binds all engineering teams together. Your success in communication to get the job done will, in turn, inspire others to communicate better. A cohesive and trusting team with a clear sense of WHY is a beautiful thing.
