Problems Solved by SystemBlend™, Part 1: Manager Frustration

This is the first in a series of articles discussing the real-world problems addressed by SystemBlend™. For this first article, I’ll describe how SystemBlend helps the project lead by eliminating the back-and-forth between her and the groups contributing subsystem models.

Imagine Augusta is leading a simulation project that includes subsystem models contributed by other companies. Without the proper tools, there will be considerable back-and-forth between the other companies and her group to get the simulation integrated properly. Experience has shown that on every project, some of this will become political, and Augusta will have to step in to referee the situation. (In a future article, I’ll discuss the impact this back-and-forth has on her group.)

Low-Level Details

A source of frustration for Augusta is coordinating the engineers to ensure they get the interfaces between the models working properly. The component interfaces include many low-level details, and every one of those details must be working properly for the simulation to run as intended.

The majority of these details will work as initially implemented. Unfortunately, because there are so many ways that the interfaces can go wrong, even a small minority of the details can result in a large number of issues. Each of these issues must be ironed out between the different companies, meaning there can be a lot of work.

Because Augusta is the project lead and this effort involves outside companies, Augusta must remain involved enough at this level of detail to ensure the overall project is running smoothly. As I mentioned before, this can become political because outside companies are involved. When it does, Augusta must be closely involved to ensure the overall project remains on track, and this is a major source of frustration for her.

In SystemBlend, the second application in the suite, ComponentGuide, addresses these issues very cleanly. It is installed and run by the companies that are contributing subsystem models, and it ensures that the interfaces are being implemented properly, so Augusta’s group doesn’t have to. Because it is guiding the other companies at their own site, the back-and-forth to get the details implemented properly is eliminated.

Design-Level Issues

Sometimes, the engineers will identify a problem at the design level. This can be for many different reasons, but it is usually because they identify some behavior or subsystem that was not considered during the design effort. This can come from the contributing companies or from Augusta’s group.

Either way, it results in back-and-forth between the affected groups. I’ve worked on several projects in which these issues were resolved during integration, which is not an optimal approach. As with any engineering problem, you want to implement the resolution upstream at the source of the problem, instead of letting it flow downstream where it is much more difficult to manage.

The structure of the SystemBlend suite makes it intuitively clear to everybody that resolving a design-level issue must be done at the design level, using the first application in the suite, SystemDesigner. This ensures that problems are resolved once at the source, instead of repeatedly during integration.