Research
System Architecture Methods
System architecture as a field of study grew out of practioner work attempting to capture expert wisdom from past designs and to structure a broader understanding of potential designs. By definition, system architecture models look broadly across possible technologies, subsystems, and use contexts. Although each model employs problem-specific parametrics, we have advanced the state-of-the-art by developing unique and generalizable approach to structuring complex systems architecting problems that can be applied across disciplines.
Our methodological work on system architecture problems spans several key questions, including:
- What decisions will define the system architecture?
- What couplings exist between decision options?
- How should the system be decomposed and modularized?
The over-arching intent is to capture the possible technical decisions in a solution-neutral expression, as opposed to reasoning from existing solutions - the difference between How to design a corkscrew to remove the cork? and How to extract wine from a bottle?. The graphic below illustrates one of the analytical tools used to represent architecture, the Object-Process Methodology (OPM), a semantically exact system for defining functions.
Using OPM as a semantically exact language has enabled us to build out representations of system architectures as a set of coupled decisions. For example, in [Koo et al., 2009] we built an executable model capable of enumerating all architectures and then evaluating the tradespace from a list of decisions. For example, the five decisions that defined the Apollo mission mode architecture are shown in the figure below. This focus on decisions enables system architects to directly trade the choices of reference, rather than the underlying designs they represent, thus encouraging broader concept evaluation. At the same time, this decision language enables system architects to order decisions according to their leverage on the system performance, thus directly recognizing that system architectures are rarely chosen in one fell swoop - they are iteratively defined by a series of choices.
Representing system architecture as decisions is one of many classes of system architecture problems. Our current work includes an effort to build a taxonomy of theses system architecture problems, which span the tasks that architects are responsible for overseeing. Another class within this taxonomy is partitioning and covering problems, where the architect is looking to divide a fixed number of functions across a set of product - such as distributing earth-observation instruments across a range of satellites [Selva, 2012]. By developing this taxonomy, we are working to bring existing mathematical solvers into the toolset of the architect, identifying situations where computational power can help architects manage large tradespaces more effectively.