All system modeling approaches the author came into contact in the last 20+ years, including INCOSE, SysMod, RFLP and even the IBM Rational Harmony approach are designed with the mindset that one architect designs a single model. Aspects like collaboration, variant handling or life cycle management are not covered at all by these approaches. IBM Rational Harmony Deskbook Release 4.1 mentions the term variant four times. But how the variants are created is not described at all. Furthermore the presented variants do not even realize the same interface. Do two independent relations shown in a single diagram represent two variants? The author feels: “No!”.
As a result, more and more projects significantly delayed or even failed completely, because of the sheer complexity to master. This happened not only to a single OEM or a single 1st tier supplier, it is a common phenomenon. This made the author think on how to master this amount of complexity. The result is this new approach to model complex systems. This post summarizes some of its ideas but follow the previous link for the full approach description.
The key to model complex systems is collaboration, at some level of complexity a single architect is simply unable to design the system up to the given due date. Side effects of the approach are an easy to use variant handling mechanism and implicit life cycle management enabling a high degree of re-use. Beside this, the approach allows mixing both top-down and bottom-up design as well as waterfall and agile processes.
As a fun fact: The approach describes nothing new. All methods/principles exist and are successfully adapted for decades. But not by the system modeling engineers. Even the almost complete combination of the methods used by the approach is commonly established to implement software for decades. So besides the unit tests also most of the integration tests are already successfully passed.
One core principle used is Design by Contract also referred to as Liskov Substitution Principle. This principle is a sound foundation of variant handling. Being a mathematical calculus the principle enables formal proving. The way variants are handled by the approach furthermore enables variants to be developed in parallel by independent teams. Nevertheless, the approach is simple and hence easy to understand and adopt.
Separation of Concerns is a further principle utilized. Separation of Concerns has several aspects including Aspect-oriented programming. Aspect-orientation can also be applied to modeling. The approach describes how to augment a base model by another model adding a specific aspect. Such aspects could be safety (e.g. FMEA or FTA), security or conformance to regulations / laws. Another aspect of Separation of Concerns is the separation of responsibilities. What does that mean? Besides performing normal operation, safety-critical components perform periodical self-tests, report to a diagnosis component and reply to a watchdog. These four responsibilities can and shall be interfaced by separate interfaces. The third and last aspect of Separation of Concerns is the separation of abstraction levels. This is the only principle not being used for implementing software. But nevertheless, it is not new. The NAF (NATO Architecture Framework) along with other Architecture Frameworks separate levels of abstraction for decades. The approach adopts the three levels of abstraction defined by NAF v2 and re-used in NAF v3 but names them operational architecture, logical architecture and physical architecture as defined by INCOSE’s SEBok. These terms are also used in the ARCADIA method. Hence the author regards these terms as more common.
The third and last principle used is referred to as the Open-Closed Principle. Besides using this principle to structure the system of models the principle gets extended. Open and closed instances of a model are allowed to co-exist. A released instance of a model is frozen, is closed. To evolve the model an open working copy co-exists. It is even supported that several working copies co-exist. This enables trial-and-error or to name it more embellished: to operate in investigation mode. Nevertheless, either one of the working copies gets released or one gets released as base and others get released as variants.
As written before: This text is just the teaser. Go read about this approach to model complex systems and let me know your thoughts!
In brief, I am an systems architect since more the two decades. What else, I like to travel between worlds. Consequently I worked in different domains (i.e. automotive, railways, defense, insurance, banking). My projects range from pure software development projects,systems engineering or embedded system engineering to pure consulting projects. I call myself a systems architect, because in all projects I designed systems.I view software applications and engineering/modeling guidelines as systems too. All follow the same rules.
The principles you mention are useful and important, but getting intellectual collaboration as a team is necessary to achieve the effect when more than one architect is involved. Bill Curtis’ “A field study of the software design process for large systems”, CACM, Nov 1988 is the best analysis of these factors I’ve seen. Although the technologies of 30 years ago are long gone, the human factors haven’t changed.
https://dl.acm.org/citation.cfm?id=50089
Hi Robert,
many thanks for the link to that paper. I was not yet aware of that study.
Yes, human — or to be more specific phychological and cognitive — factors have not changed that much, if at all the last 30 years.
The paper focusses on technical issues. Nevertheless like in
I mention human factors to back design decisions.
/Carsten
great thinking !
I personally like the “Open-Closed Principle” adnd the beautiful word of “encapsulation” applied to all levels of abstraction.
collaboration can be a dangerous word, a bit like “we need to talk” … In my experience we MUST provide the map on which to talk ABOUT i.e. what to collaborate about!
As Robert V Binder and you pointed out, the most crucial factor is to get intellectual collaboration working. I really be grateful for the term “intellectual collaboration” introduced by Robert V Binder.
To get intellectual collaboration work, you have to consider social and even psychological aspects.
I am actually thinking on writing a follow-on paper focusing on the social and even psychological aspects.
/Carsten