Digital engineering is not about building models.
It is about building shared understanding.
I develop model-based architectures, methods, tools, and learning environments that reveal critical relationships, preserve engineering intent, and help teams make digital engineering a practical part of how they understand systems and make decisions.
ENGINEERING PHILOSOPHY
My philosophy has always been that engineering is fundamentally a team sport.
Titles, organizational boundaries, and formal responsibilities are important, but complex systems rarely succeed because individuals remain strictly within the limits of their job descriptions.
Every program has challenges. But my philosophy is simple; If you have the capability to help, you have the responsibility to help.
Sometimes that contribution occurs at the organizational level—aligning stakeholders, driving important initiatives, and improving the effectiveness of the larger system.
At other times, it means meeting privately with a software engineer, helping develop an algorithm that is more effective and efficient, and then watching that individual shine during the next review.
The objective is not ownership of a particular task.
The objective is the success of the system.
ORGANIZATIONAL ADOPTION
Effective digital engineering adoption begins before the software is opened.
Digital engineering training is often approached as software instruction: where to click, how to create an element, and which menu contains a particular function. Those mechanics matter, but they are not where effective adoption begins.
People are more willing to learn when they understand why the work matters, how it connects to the larger engineering mission, and what becomes possible when information is organized differently. Establishing that context creates interest, reduces resistance, and gives the mechanics that follow a reason to matter.
My approach begins with purpose and conceptual understanding, then builds progressively toward methods and tools. The objective is not simply to complete training. It is to develop engineers who understand what they are creating, why they are creating it, and how the resulting information supports better technical and program decisions.
I also structure training in focused chapters, typically four to fifteen minutes in length. This makes the material easier to enter, easier to revisit, and easier to use at the point of need. Rather than searching through a long recording, learners can return directly to the specific concept, method, or task they need to review.
TRAINING EXAMPLE
The following four-minute chapter demonstrates this approach by establishing the purpose and value of model-based systems engineering before introducing its methods and tools.
SELECTED PUBLICATION
Integrating the Constructive Systems Engineering Cost Model with the Systems Modeling Language
This work explored the integration of model-based systems engineering and systems cost estimation through the development of a custom SysML profile and supporting implementation within Cameo.
The underlying objective was to move cost reasoning closer to the evolving system model, improve consistency between engineering and programmatic information, and reduce dependence on disconnected artifacts and manual translation between disciplines.
More broadly, the work reflects an enduring interest in preserving engineering knowledge, improving information visibility, and enabling better decisions through connected digital representations of complex systems.