Mark Simons once found himself sitting in a circle at his then 8-year-old daughter’s yoga class. Participants went around and introduced themselves, explaining what they did for a living. Realizing that no one in the room would be likely to know about systems engineering, Simons thought quickly about how to explain it. “I told them that in my job, I work to bring engineers from a diverse background and experience to come together and work toward a common goal. After that, they all thought I had the best job in the world.”
Simons was recently hired on as the latest principal systems engineer to become part of the Professional Services team at Vitech. In this role, he will deliver training in systems engineering to clients as well as provide mentoring and coaching.
With his range of work experience within both the government (NASA) and the public sector (The MITRE Corporation), and his teaching experience at Johns Hopkins, Simons draws on the many dimensions of systems engineering to bring value to his SE practice.
The makings of a systems engineer
Ironically, as a kid, Simons says math and science were his weakest subjects in school. And yet, math held an attraction for him. “What appealed to me about math was its logical purity. It’s like systems engineering—the critical thinking and methodology. Math teaches you to appreciate abstract thinking.” As for scientists, he says, “They have a method where they make, test, and validate hypotheses to formalize their critical thinking processes. Systems engineering provides a similar method to organize critical thinking processes for engineers.”
Simons started out in the early ’90s at NASA as a software engineer doing software testing and later, software development. After discovering an interest in systems analysis and operations, he joined NASA’s space-based Tracking and Data Relay Satellite System. Then, seeking a greater understanding of this field, he obtained a master’s in operations research from George Washington University.
In his early career, requirements was a major focus. Requirements, he saw, were often hard for people to write, so sometimes they simply didn’t write them until after a project had been completed. Needless to say, that’s less than optimal. Simons realized that using modeling and simulation would be a good way to elicit and validate requirements. “Without an understanding of requirements, you’re guessing at the components,” he notes. But by using modeling and simulation to create your requirements at the outset, you can increase your opportunities for insight, and this will benefit the efficacy of your design.
From there, Simons moved again within NASA to a project developing ground data processing systems for earth-observing satellites that processed raw data into products for scientific interests. On one occasion, Simons devised a process for this enterprise—known as the Earth Sciences Data Information System Project—to deliver raw earth science data to an outside agency, allowing weather scientists to provide timely analysis to the general public.
It was while doing modeling and simulation at NASA on the Earth Sciences Data Information System project that Simons truly cut his teeth on systems engineering and fell in love with the discipline. “I saw that systems engineering could help organizations efficiently build and develop systems.”
In the early 2000s, Simons went to work for The MITRE Corporation, a federally funded research and development corporation based in McLean, Virginia that handles a mix of federally funded research and development projects for U.S. government agencies. At MITRE, just as he had at NASA, Simons held a number of positions, working in everything from Wide Area Networking to Service-Oriented Architecture to IT systems and even laser technology.
While at MITRE, Simons again returned to school, this time to get a master’s in systems engineering from Johns Hopkins. “All the systems engineering pieces came together at that time,” he notes. At Johns Hopkins, he had a professor who gave students a group project to complete every month. The instructor suggested that the students use CORE as a tool. While he didn’t provide training on the model-based systems engineering tool, Simons taught himself.
“When I first used CORE, I thought, why didn’t I have this product when I was at NASA?! It would have saved me a lot of pain and suffering.” At that time in the 1990s, Simons points out, most organizations used document-centric systems engineering processes. With CORE, though, the processes were more automated.
In the early days, Simons recalls, there was no actual training in systems engineering—it was just on-the-job. So to get actual training at a university level in a practice that he had in effect already been doing for some years was rewarding. To confirm, after the fact, that what he had learned about how and why certain things had been necessary and how it all fit together—this was illuminating. “It was enlightening for me to understand that systems engineering offered methodical rigor and repeatable processes.”
After receiving his degree from Johns Hopkins, Simons was asked to co-instruct a course in product management for their systems engineering program. As good teachers do, he learned a lot himself. “That’s when I was able to understand the mystery of the work breakdown structure. You realize what an important touchpoint that is for systems engineering.” And, he notes, “I love teaching—all ages. I love to provide the ‘light bulb moment’ to people.”
Meanwhile, at MITRE Simons continued to work on complex systems. One project was a study for the FAA about consolidating facilities for air traffic service and how that affected voice communications. “We incorporated stakeholders in the process,” Simons explains. “If you do it right, the users are on your side, and if you do it at the beginning, you’ll have their input to guide better engineering.” This is key. “Even though, as engineers we often think we know what’s best for the users, we need to have the stakeholders’ input and understand their needs, or they won’t find the system or product acceptable.”
And, it brings up a truism about systems engineering—that it helps you understand human nature. “Through the practice of systems engineering, you learn about human behavior and how conflict can either help or hinder systems development,” Simons notes. “Systems engineering provides processes and artifacts that can remove the personalities from a discussion so you can focus on the problems at hand.”
A deep knowledge of Vitech products
Simons truly learned Vitech’s model-based systems engineering tools CORE and GENESYS while he was at MITRE. He found them to be advantageous in a number of ways. “When we submitted our proposal, the reviewers commented on how clear it was and how easily understood, and how readily everything was communicated to all the stakeholders so they could easily understand the vision.”
Simons enumerates several additional benefits of the Vitech tools. “I appreciated the speed at which I could get work done, and how the tool allowed me to leverage my capabilities to magnify my impact. “ With CORE, I could get everything done that I needed and just work as a single engineer, producing artifacts that other teams of engineers were doing.”
Simons continues, “Other tools or tool suites require a significant amount of staffing and specialized experience. I’ve found Vitech tools can help an organization avoid large systems engineering staffs, reduce wasteful processes, and motivate lean principles.”
Additionally, Simons observes that without CORE, it’s difficult for an organization to understand key details. “You get caught up in recording data and miss out on the opportunity for insight.” For example, “With CORE, if a risk popped up while I was working a functional analysis, I could quickly stop and identify and associate a potential risk area, and then come back to what I was working on.” Finally, Simons notes, “One has the ability to work at ‘think-speed.’ The tool doesn’t get in your way.”
Reflecting on his work at various places and in his different capacities, Simons comments, “I have enjoyed being able to shed light on ideas that help stakeholders understand the system and bring about convergence on a solution.” Sounds a lot like what the systems engineer said to his daughter’s yoga class—that it’s about bringing people together to achieve a common goal.
