Engineering the architecture for a large and complex system is a hard, lengthy, and complex undertaking. System architects must perform many tasks and use many techniques if they are to create a sufficient set of architectural models and related documents that are complete, consistent, correct, unambiguous, verifiable, usable, and useful to the architecture's many stakeholders. This blog posting, the second in a two-part series, takes a deeper dive into the Method Framework for Engineering System Architectures (MFESA), which is a situational process engineeringframework for developing system-specific methods to engineer system architectures.

In our previous blog entry, we introduced MFESA and its four components:

• the MFESA ontology defining the foundational concepts underlying system architecture engineering
• the MFESA metamodel defining the base superclasses of method components
• the MFESA repository of reusable method components
• the MFESA metamethod for creating project-specific methods using method components from the MFESA repository

We also briefly discussed the applicability of MFESA and how it simultaneously provides the benefits of standardization and flexibility. In this blog posting, we will take a closer look at the four components comprising MFESA.

The MFESA Ontology

To create a complete and well-defined method for performing system architecture engineering, it is first necessary to understand terminology (technical jargon) and concepts underlying this area. This understanding goes beyond a mere glossary of terms to encompass an information model that also describes how these concepts relate to each other. The MFESA ontology defines the domain of system architecture engineering and is the foundation on which the rest of MFESA is build.

Figure 1 below summarizes many of the most important contents of the MFESA ontology, an information model of the foundational concepts underlying system architecture engineering. Starting at the center of the diagram and moving to the left, we see that system architecture comprises a combination of

• architectural structures that can be static or dynamic as well as logical or physical
• architectural decisions that include the use of architectural styles, architectural patterns, and architectural mechanisms

Starting at the center and moving to the right, we see that system architecture can be documented in many ways including in the form of

• architectural descriptions, some of which are various types of architectural documents as well as various types of architectural models that model the different kinds of architectural structures
• executable representations, such as architectural prototypes, architectural simulations, and executable architectures

At the top of the diagram, we see that the architectural concerns of stakeholders are architectural drivers, including architecturally-significant requirements that drive the engineering of the system architecture. Architectural concerns are also, often quality focus areas (i.e., quality characteristics such availability, performance, portability, reliability, robustness, safety, security, and usability) and architectural support for these qualities can be organized in the form of architectural quality cases (a.k.a., assurance cases) that provide arguments and evidence that the architecture adequately supports the architecturally-significant requirements.

The MFESA Metamodel

The second MFESA component is a process metamodel that is restricted to system architect engineering. Figure 2 shows the MFESA view of the concepts: process, method, and process metamodel.

The system architecture engineering processes that are performed on different projects are at the lowest level of Figure 2. Each process consists of components such as

• actual work products (e.g., architectural models and architecture documents)
• actual work units (e.g., instances of architecture engineering tasks and techniques) that are used to produce the work products
• actual workers (e.g., specific architecture teams and architects) who perform the work units to produce the work products.

The middle layer consists of system architecture engineering process models that are the as-intended methods for engineering system architectures. These methods contain reusable components that describe their instances: the process components. MFESA thus recognizes that there is both a theoretical and practical difference between the methods documented in standards, procedures, and guidelines (middle layer) and the work people actually perform on their projects (bottom layer).

At the top level of this three-level structure is the MFESA system architecture engineering process metamodel, which models the process model. This metamodel consists of metamethod components, which are the abstract subclasses that are specialized to produce the method components. For example, the MFESA metamethod component task is subclassed to produce 10 specific tasks of system architecture engineering that, in turn, are instantiated as actual task executions on the project.

Figure 3 shows the four metamethod components within the MFESA process metamodel. They are the abstract classes of process components that are subclassed to create the MFESA method components.

The MFESA repository contains an extensive set of reusable method components derived via subclassing from the MFESA metamethod components. Figure 4 depicts the first nine method components (abstract classes of process components). MFESA thus recognizes three types of architecture workers who perform three types of architectural work units to produce three types of architecture work products. The complete class hierarchy of method components is considerably larger and includes the concrete method components that are instantiated to produce the actual process components seen on real projects.

Example reusable method components include subtypes of:

• architectural work products, such as architectural representations (which we saw in the MFESA ontology) that include both architectural documents (e.g., system architecture document, software architecture document, and architecture vision document, various types of architectural whitepapers and reports such as how the architecture handles concurrency or fault tolerance) and architectural models (e.g., class diagrams, sequence diagrams, statecharts, and data flow diagrams)
• architecture workers, such as the system architect, software architect, and architecture team, and various types of architecture modeling and documentation tools
• architecture work products, such as the many types of architecture tasks (e.g., identify the architectural drivers and maintain the architecture and its representations) and techniques (e.g., brainstorming and architectural patterns)

The MFESA Metamethod

As mentioned in the previous blog entry, MFESA is not a method for engineering system architectures but rather a framework for creating methods for engineering system architectures. Figure 5 shows the MFESA metamethod for creating these methods. Each box in the figure is a step in the method.

The first metamethod step determines the project's needs regarding system architecture engineering methods. The second step determines the number of such methods that are needed, which for most projects is one. The third step determines whether

• a previously constructed method can be tailored to fit the specific needs of the project, in which case a method is selected and then tailored, or
• whether a new method needs to be constructed from the reusable method components, in which case the relevant method components are selected, tailored, and integrated to form the new method

In both cases, the resulting method(s) must be documented, typically in plans, standards, procedures, guidelines, templates, and user manuals. The document method(s) must also be verified as complete, consistent, correct, and usable. Finally, the verified method(s) must be approved and published.

Wrapping Up

Systems, organizations, and contractual relationships between acquirers and developers are diverse and multi-dimensional. No single architecture engineering method is therefore sufficiently complete and tailorable enough so that it is appropriate for all situations. MFESA is not a method for engineering system architectures but rather a method framework that can be used by system architects and process engineers to produce appropriate system architecture engineering methods using situational method engineering. To accomplish this, MFESA consists of four, interrelated components:

• an ontology that defines the foundational concepts of system architecture engineering and the relationships between them
• a metamodel that defines the base classes of reusable method components from which all other method components are subclassed
• a repository of reusable method components (architectural work products to be produced, work units to be performed, and architectural workers) from which situation-specific system architecture engineering methods can be constructed
• a metamethod for selecting appropriate method components, tailoring them, and integrating them to produce the appropriate method

Even if you are content using a single organizational system architecture engineering method, you may find it worthwhile to peruse the MFESA repository to see if your method is missing any important elements. Consultants, trainers, and educators may also find MFESA a good foundation on which to build training courses and classes on system architecture engineering. Finally, researchers in system architecture engineering methods and situational method engineering may find MFESA useful as a repository of reusable method components.

Additional Resources

MFESA is primarily documented in the book, The Method Framework for Engineering System Architectures, published in 2009 by CRC Press. The book was co-authored by a six-member team from the SEI, MITRE, and the U.S. Air Force. The book was recently added to the Intel Corporation's Recommended Reading List.

To see a tutorial on MFESA presented at the 2011 IEEE International Systems Conference (ISC) in Montreal, Quebec, Canada please go to http://donald.firesmith.net/home/publications/publicationsbyyear/2011/2011-MFESA_ISC.pdf

To see a tutorial on MFESA presented at the 21st System and Software Technology Conference (SSTC) in Salt Lake City, Utah, please go to http://donald.firesmith.net/home/publications/publicationsbyyear/2009/MFESA-SSTC.pdf