The Method Framework for Engineering System Architectures [Englisch] [Gebundene Ausgabe]

This book is a repository of architectural techniques and knowledge that is intended to be customized per project. It is geared towards system architecture, of which software architect is one small discipline, which is true in the context of this book and the systems it refers too. The systems they are referencing are airplane systems, fighter jets, and other large systems.

I do believe the book is a great start in building a repository of architectural techniques and knowledge. One thing the repository must accomplish before it is really usable is being distributed electronically. The author says that is in the works.

The book is a goldmine of information and guidance. They include a ton of content geared towards the decision making process. It is in the format of Pitfalls, Negative consequences, and Mitigations.

Amazon has made the content searchable. You can check out the table of contents, and spend some time searching on topics, for example "architecture tools", "evaluations", or "performance". Also, if you search the web for MFESA or "Method Framework for Engineering System Architectures" you will find some presentation and papers done by the author, which will give you a good look at some of the material found in the book.

The authors state that this is a work in progress and this is only the beginning. Hopefully in coming content we will see some guidance on tactics as they are related to quality attributes. I have not seen a more complete compilation of quality attributes anywhere, but they stop at the quality attributes. They do for what I would consider a good reason, it would have double or tripled the size of the book if they would have picked a domain and covered tactics. They do cover architectural mechanisms, styles, and patterns.

They also cover decision-making techniques in detail, and a tactic is a design decision that enables control over a quality attribute. They dedicate an entire appendix to decision-making techniques.

Although the book is geared towards system architecture, it also applies 100% to software architecture. I have not found any information in the book that is not relevant to software architecture.

This is a must have reference for any system or software architect. Keep in mind it is not a process, it is a repository that is used to create an instance of a process. Every project is different to a certain degree, and because of that, every project needs its own instance of a process.

This book is a bound edition of CMU/SEI's MFESA framework description document, a description of which can be found at their web site. Note that MFESA is a framework, not a methodology, practice, task, or tool. If you are unfamiliar with frameworks, you can think of this as if it were an organizational process description, compliant to the CMMI, etc.

The authors assert that systems architecting is done very poorly in most organizations, with little to no recognition of the roles, processes, resources, planning, reviews or planning documents that are needed at the engineering level. I would agree. The Method Framework (MFESA) provides a conceptual model that is "informative" not "normative" of the systems architecting process. This framework also applies to software architecting projects.

In particular, the book doesn't advertise or rehash someone else's methodology or framework (i.e., SySML, UML, TOGAF, DoDAF, MoDAF, FEAF, etc.). It does answer the Zachman Framework interrogatives "what", "why", "when", and "who" (but not "how") from an organizational perspective. That is why this book is so useful.

Why would you need such a resource? CMMI doesn't tell you how to architect systems, neither does ISO 15288, any MIL standard, or tool vendor literature.

This is not a book about "Operational View", rather it is a book about "System View", and in particular the "Project View" (DoDAF 2.0 terminology here) or the "Acquisition View" (MoDAF terminology). It helps to bootstrap your planning and execution of new product/system design, and it helps to keep you out of the ditch.

The book's chapters are laid out pretty much in process-step order:

1) Introduction
2) SA Engineering Challenges
3) SA Engineering Principles
4) MFESA: Overview
5) MFESA: The Ontology of Concepts and Terminology
6) Task 1: Plan and Resource the Architecture Effort
7) Task 2: Identify the Architectural Drivers
8) Task 3: Create the First Versions of the Most Important architectural Models
9) Task 4: identify Opportunities for the Reuse of Architectural Elements
10) Task 5: Create the Candidate Architectural Visions
11) Task 6: Analyze Reusable Components and Their Sources
12) Task 7: Select or Create the Most Suitable Architectural Vision
13) Task 8: Complete the Architecture and Its Representations
14) Task 9: Evaluate and Accept the Architecture
15) Task 10: Maintain the Architecture and Its Representations
16) MFESA Method Components: Architectural Workers
17) MFESA: The Metamethod for Creating Endeavor-Specific Methods
18) Architecture and Quality
19) Conclusions

This framework is work-product and process driven. The process steps are laid out in a conceptual timeline of events with standard Hartley-Pirbhai process block description of each task step (inputs, outputs, entry criteria, exit criteria, process description, off-nominal conditions, gotcha's, etc.).

This is a good first effort from the authors, and I will be using this text for my own systems architecting classes since it starts at the engineering level and drives down into the day-to-day activities that systems architects must perform to create viable systems.