What is functional architecture?

Updated in March 2025
I have mentioned functional architectures several times in the past. However, I have not answered the question: What is functional architecture anyway, and why can it be useful? That's what this article is about.
Functional architecture decouples function from technology
In principle, functions are always taken into account during development, e.g. via functional requirements. However, it is not unusual to end up with a specific physical system quite quickly. With a functional architecture, attention is paid to this,
- that the functions are retained as the main elements of the architecture.
- that the development of the physical system is clearly subordinate to the functional structure.
This approach has two advantages:
- The architect can concentrate fully on the functionality of the system without it being complicated by a specific technical solution.
- The architecture is much more robust with regard to technological change.
Example: Photography
A good example is that of photography, from the book Model-Based System Architecture. Photographs have been around for over a hundred years. The actual function of "taking a picture" has not changed during this time. Only the technology has changed, from pinhole cameras to film cameras with lenses, from SLR cameras to cell phone cameras. On a functional level, there is continuity despite the change in technology.
For the user, the function is important, regardless of which technology is used to implement it. This is why functional architectures create continuity.
The user who wants to take the picture is not interested in the inside of the camera, but only in the result. This knowledge in terms of functionality can also be taken into account in a new technology.
Technology-specific functions
An initial functional architecture can be defined in a largely technology-neutral way. However, this must be further refined in the course of development. And as part of this refinement, specific technologies must be addressed. Here it is important to decouple the functions from the technical decisions. For this purpose, the SYSMOD Zigzag pattern. This approach involves working in stages at different levels. At the top level, the functions would be described as technology-neutrally as possible. Technology decisions are then made one level lower. Different technologies would lead to different variants. In order to realize these variants, new, technology-specific functions must be introduced.
Functional architectures support variant management
To stick with the camera example: A technology-neutral function would be "capture image". A technology must be selected for the specification, e.g. chemical (film) or CCD sensor. In the first case, there would be the new (technology-specific) function "Change film carrier". However, this function is again "downwards" technology-neutral. It remains open, for example, whether the film material was applied to rolls or plates. This technology decision can be made in the next "Zigzag" round.
Practical application
Once the principles behind functional architecture are understood, it is not difficult to apply them. After all, functionality has always been relevant in system development. The only new aspect is the disciplined postponement of technology decisions.
A little more formal
In her book Model-Based System Architecture describe Tim Weilkiens and Jesko Lamm somewhat more formally under the name FAS an approach to functional architecture with SysML. As known from SysML modeling, use cases and activity diagrams are used. What is new is that the activities are summarized in "functional groups" and "functional blocks" are formed on this basis. Functional groups in turn contain functional blocks. Here there is the option of modeling even more detailed operations.
Currently SysML v2 is a hot topic, as it contains many improvements that also simplify functional modeling.
The FAS method "Functional Architectures for Systems" presented in the book by Weilkiens and Lamm has its own website: fas-method.org. The Systems Engineering Book of Knowledge (SEBoK) has also a separate chapter on functional architecture.
Back to the physical world
As a purely functional architecture cannot be implemented, we must now bring the whole thing into the physical world. A distinction is made between the logical architecture and the product architecture. The logical architecture describes the physical concepts, e.g. CCD sensor. The functional architecture can then be mapped to the logical architecture. Finally, the product architecture concretizes the logical architecture, i.e. the resolution of the sensor in the current example.
Mapping the functions to components requires an experienced architect. As products are rarely developed from scratch, there is usually already a lot of prior knowledge here.
Conclusion
Especially in today's fast-moving world, a functional architecture can represent a significant competitive advantage. This is because a functional architecture allows you to react quickly to new technical developments and ensure that knowledge already gained in terms of functionality is not lost. How to proceed formally here is of course a different question. A good awareness of functional architectures alone has a high added value. However, I only recommend a more formal approach such as the FAS method to experienced teams that already have a good understanding of modeling.
Image source: Sinergy'Com via SEBoK CC BY-NC-ND 3.0







A comprehensible summary and a good plea for functional architecture.
I would just like to point out the problems with the definition of the functions themselves:
The following questions must be answered for each function:
-What resources does the function require?
-What inputs/outputs does the function have?
-What time requirements apply to the function (processing time, throughput)?
-How much data must be available?
-How is the behavior of the individual function described?
-Is the behavior fully describable or only exemplary?
-What errors can the function itself detect?
Is the function error-free with regard to the inputs?
-What errors can the function itself produce?
-What are the dependencies on other functions?
Thanks for the list - it clearly shows that functional architecture is not „completely without“. Tim Weilkien's book also addresses some of these aspects.