Our world runs on increasingly complex systems. From cars to power plants, we increasingly expect immediate connectivity, machine learning on product data, and technology infusion, all of which are driving up the complexity of modern systems. These systems—found in industries ranging from aerospace to automotive, from high technology to healthcare, and beyond—rely on professionals who have a deep understanding of both the components of the system and their system-level behaviors, desirable and undesirable alike.

Consider Twitter. Follow a spate of outages during the 2010 World Cup, where peak activity crashed its infrastructure, Twitter re-architected its entire monolithic codebase. Today, it routinely processes about 5,700 tweets per second, and has handled a peak of 143,199 tweets per second (on August 3, 2013, during the airing of a popular TV show in Japan).

That’s just one example of the rising demands users put on these systems. These demands go beyond surges and scalability. For products to capture market share, we ask systems to innovate on existing offerings, incorporate novel technologies, and address multiple markets. For companies to compete on tight margins, we ask that systems be designed to optimize manufacturing cost and be delivered through multi-tiered supply chains.

My experience is that a substantial portion of a system’s performance is determined by a relatively small set of decisions—architectural decisions. For engineers, program managers, and business owners, such decisions make all the difference.

I’m excited to announce that MIT is launching a new four-course professional-certificate program to explore these architectural decisions along with industry leaders. The online-only program, Architecture and Systems Engineering: Models and Methods to Manage Complex Systems, begins Sept. 12, 2016.

Every Built System Has an Architecture

Products such as mobile phone software, cars, and semiconductor capital equipment are defined by a few key architectural decisions made early in the program lifecycle. Those early decisions drive downstream decisions. In the real-world design of complex systems, however, engineers often don’t have full knowledge of those systems’ eventual scope before making decisions that may have a big impact—from creating bottlenecks that constrain performance, to restricting potential manufacturing sites, to reducing after-market revenue share.

For example, MIT worked with NASA on the architecture of next-generation communication satellites. NASA currently operates three sets of relay satellites, each the size of a school bus, to convey government data from science and military space missions. NASA officials felt an architectural change was needed to reduce costs, which today are two to three times more than those of commercially operated satellites. MIT worked with NASA over a three-year period to identify the architectural decisions—such as the presence or absence of on-board data storage, the choice of orbit, the number of satellites per orbital plane, and technology development for inter-satellite links—and analyzed millions of combinations of decisions to identify the top candidates for new architectures.

Despite the uncertainty around scope, my experience is that spending time upfront on architectural decisions—whether you are sequencing the decisions to be made based solely on your team’s experience or sequencing them more explicitly using decision models to estimate sensitivities—can have a substantial return on investment.

In other words, good architectural decisions can create competitive advantages in difficult markets, but bad decisions can hobble large development programs down the road.

Models and Methods

In launching the new Architecture and Systems Engineering program, we’re excited to be exploring such decisions with industry leaders. We’ve brought together some of the biggest organizations involved in complex systems—including GE, Boeing, Raytheon, GM, NASA, and Caterpillar, among others—to talk about the state of the practice today.  

One of the trends we’re most interested in exploring is the movement away from paper-based design that’s often known as “model-based system engineering” (MBSE). The big idea behind MBSE is to digitize the design process.

Despite big improvements in software, from product lifecycle management software (PLM) such as Siemen’s Team Center or PTC’s Windchill, to simulation software such as large airflow simulation or mature structural codes, much of the design process is still based on paper documents. These documents carry a legacy of long rework cycles and are often the culprits in quality issues. The vision of MBSE is to combine large models to where the team works on a central model with a focus on concurrency.

“Systems engineers who are working on these complex systems really have to be the ones that understand where the margin is, understand the system performance, and then advocate for the entire system,” explains Greg Hyslop, Boeing CTO and senior vice president of Boeing Engineering Test and Technology Group.

We will discuss the promise of MBSE for making system architecture decisions, and we’ll explore the failure modes and management issues that underpin it. The computer-aided design (CAD) revolution took decades to mature—our approach to MBSE is to take a hard look at the challenges, and to foster a discussion about the implementation that’s grounded in the experience of a consortium of companies.

Making Better Architectural Decisions

Which architectural decisions did Twitter engineers make in their search for scalability after the 2010 World Cup? They decided the gains from their original, monolithic code base had been exhausted—at the time, it was one of the world’s largest Ruby on Rails installations. So they reinvented their architecture as a Java Virtual Machine installation, modularizing its functionality and placing more emphasis on concurrency. It may sound like motherhood and apple pie, but architectural changes like these take a measure of courage — we’d prefer to make them from a position of analysis and strength rather than as a gamble.

Join us in exploring these issues in more depth in MIT’s new Architecture and Systems Engineering professional-certificate program, beginning Sept. 12.

Bruce G. Cameron is faculty director for MIT’s new professional-certificate program, Architecture and Systems Engineering: Models and Methods to Manage Complex Systems. He is the director of MIT’s System Architecture Lab, a lecturer in engineering management in MIT’s existing System Design and Management master’s degree and distance programs, and a co-founder of Technology Strategy Partners, a boutique consulting firm. His research interests at MIT include technology strategy, system architecture, and the management of product platforms.