Posted on by Acquisitionin
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:
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
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
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
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:
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
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.
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:
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.
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