A Functional Architecture is an architectural model that identifies system functions and their interactions. It defines how the functions will operate together to perform the system mission(s) and is a framework for organizing information, processes, or different solution modules into an enterprise system. A functional architecture depicts a system that emphasizes its functions and how they interact with each other.

Definition: A functional architecture is a set of functions and their sub-functions that defines the transformations of input flows into output flows performed by the system to achieve its mission. (SEBoK)

Purpose of Functional Architecture

The purpose of the functional architecture is to support functional and performance test development. It also supports system development, along with the physical architecture, of verification tasks that are defined to verify the functional, performance, and constraint requirements.

Functional Architecture in Development

The functional architecture serves as the fundamental basis for the systems engineering process. The engineering team initiates the process by first establishing the requirements and objectives of the stakeholder. Subsequently, they proceed to ascertain the specific functions that are necessary to meet those requirements and objectives. Subsequently, as additional connections and elements are incorporated into the design, these functions are fragmented into smaller functions.

Types of Architectures

Normally, more than one architecture can satisfy the requirements. Usually, each architecture and its associated allocated requirements usually have different cost, schedule, performance, and risk implications. The two most common architectures a system will have are:

• Functional Architecture
• Physical Architecture.

Requirements Decomposition

During the Functional Analysis and Allocation step, the functional requirements identified in the Requirements Analysis step are decomposed and their associated performance requirements into sub-functions to the point that they can be unambiguously related to the system elements or products that make up the design that flows out of a later step. The result is often called functional architecture. [1]

SMC Systems Engineering Handbook, Figure 15

Compliance

In the Design Loop, synthesized designs are compared with the originating architectures and allocated requirements to assure compliance or to initiate re-evaluation. Sometimes it is necessary to drive toward optimal solutions by presenting various functional views, including those that depict functional relationships with existing assets, to enable more thorough assessments of plausible solutions. [1]

Benefits of Using a Functional Architecture

There are a few benefits to taking a functional approach to any system. The first reason is that it helps you see how different parts of your business work together. By writing down how each input and output of your system works, you can better understand how different things may affect your business.

Functional architecture also saves your work in the long run, which is a big plus. By looking at the relationship between modules and end-to-end processes, you can ensure that a lot of the foundational work you do for a system will be useful for a long time. You can change the pieces, but from a functional point of view, how things connect tends to stay the same.

Consistency is the last good thing about using functional architecture. This benefit comes into play when you want to add new technology to a system that already has infrastructure. Companies often know exactly what is missing from their system because they have found a pain point, process gap, or inconsistency in some of their business.

AcqTips:

• The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
• DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

• [1] DoDAF Architecture Framework Version 2.02
• DoD Architecture Framework Working Group Version 1.0, Volume 1: Definition and Guideline, 9 Feb 04 (Old Version)
• DoD Architecture Framework Version 1.0, Volume 2: Product Description, 9 Feb 04 (Old Version)
• Website: DoDAF Architecture Framework – DoD Deputy Chief Information Officer
• Website: DoDAF Version 2.02 Journal
• Website: DoDAF Meta Model (DM2)
• Website: DoD Information Enterprise Architecture
• Website: OMB Enterprise Architecture Assessment Framework (EAAF)

Updated: 3/11/2024

Rank: G1.2