This article discusses accountability in distributed Model-Based Design projects: What it is, and why it’s important.
The nature of simulation, or any software development, requires precision in the implementation of the component interfaces. Small errors, such as data typing, prevent smooth integration of components.
When the groups contributing components are not held accountable for the low-level details, your group has a headache when assembling the components into a simulation. Each error in the detail puts the engineer in your own group into a difficult position. They have two choices, neither of which is good: Mind-meld with the models, or push back.
Mind-Meld with the Models
Mind-melding with the delivered component to debug the differences between the design and the implementation is tricky. Understanding another group’s simulation model is always difficult because there are always assumptions and considerations that cannot be readily gleaned from the code. Even if your engineers can understand the flow of the model, these hidden considerations mean any changes are fraught with peril.
Also, an unwritten rule among developers is that you never modify somebody else’s code. This is just professional courtesy. Usually, the other groups will cooperate when your engineers modify their code, but it is poor form. If you’re unlucky, you’ll have to deal with an engineer in another group who is very possessive.
If you go this route, your engineers might have an on-going, time-consuming problem. Each time the component is updated, they must dig into it to correct the errors.
Push Back
Instead of your engineers modifying the contributions from groups who do not meet your specifications, you or your team could work with the contributing team to get the issue resolved. For most situations, this can be resolved in one or two phone calls. The first call is to understand why the design wasn’t followed (it’s usually a misunderstanding), and the second call is to negotiate a solution.
In my experience, every project has a few glitches in the contributed models that are not so easy to resolve. Usually, this is due to uncooperative contributors. Sometimes they are simply too busy or don’t have the budget to make the changes. Unfortunately, it can become political. Either way, it can be a source of frustration.
One advantage of pushing back is to resolve the problem once, instead of having to re-work their contributions each time the component is updated.
Accountability and Feedback
Sometimes, a subsystem modeler will find an error in the agreed-upon design. This is often a missing data item, but sometimes it is driven by the developer discovering a factor that had not been considered, resulting in significant changes.
I have encountered subsystem modelers who discover an error in the design, and simply change the interfaces to meet their internally updated design. This is not the appropriate solution. Design updates discovered by subsystem modelers should be handled by re-negotiating the design, instead of unilaterally updating an interface.
Appropriate accountability ensures that when an error is discovered in the design, the affected parties re-negotiate. This ensures that all stakeholders are aware of the changes early, and it provides a mechanism for other stakeholders to accommodate the updates. In addition, you will have early feedback on issues as they arise.
The Importance of Accountability
Instead of trying to correct errors after the component is delivered, everybody is happier, including the model developers, if the errors never escape to your group. A mechanism to hold the other groups accountable can save a lot of headaches all around.
If you have a mechanism to ensure the contributing groups follow the agreed-on design, then you can be sure that your team will not have to deal with improperly implemented interfaces. This will save time for you, your team, and for the groups contributing components. Also, it will save frustration for you.
This is where the SystemBlend™ application suite shines. First, your group, with input from all stakeholders, designs the simulation in SystemDesigner. Then you deliver the design, and a copy of ComponentGuide, to the groups building the components, for a big payoff. ComponentGuide becomes your proxy in the other group, holding them accountable to the design so you don’t have to. The contributing groups understand the interface precisely, and they can be sure that they are implementing the interfaces exactly. Your team can receive the components knowing that they will drop into your design.
In addition, when a subsystem modeler discovers a need to change the design, ComponentGuide makes it clear that the design must be updated, and can’t be changed locally. This ensures that changes needed by subsystem developers result in re-negotiation.
ComponentGuide holds component developers accountable to your design, allowing the third tool in the SystemBlend™ application suite, Integration Master, to provide drag-and-drop integration, which is another big payoff for having accountability in the contributing groups.