Book Foreword by Prof. Crawley
Architecting and engineering large, complex socio-technical systems, as well as gaining deep understanding of existing natural and man-made systems, have eluded people for many years. Our thinking about systems and their role in improving humans’ quality of life has evolved over the last two decades.
We now understand better that successful systems do not materialize in a haphazard way. Rather, they must be carefully architected just like edifices, accounting for the needs, wants and requirements of their intended beneficiaries, and alternative architectures – ways in which these desired functions are embodied in form. These early decisions are critical to the system-to-be, as they determine the concept to be followed and consequently the whole direction the system development takes and the nature of the final outcome: how well the system performs in terms of delivering value, i.e., benefit at cost, while maintaining the other requirements of safety, robustness, ease of use, environmental friendliness, and many others.
As I was gaining these insights some 15 years ago, I realized that no matter how convincing your ideas are, and how compelling are the arguments, there is only so much one can do with preaching and hand-waving. It became obvious to me that making progress in the area of architecting and engineering complex systems is contingent upon a solid foundation of language and methodology. It so happened, that at that time, around year 2000, Dov stepped into my office, the office of the Head of the Aero-Astro Department at MIT, with a draft of his first book, titled Object-Process Methodology – A Holistic Systems Paradigm (Springer, 2002). Reading this draft in a plane I immediately understood that what I was holding in my hands was exactly what I was looking for.
Object-Process Methodology (OPM) is a systems modeling paradigm that represents the two things inherent in a system: its objects and processes. OPM is fundamentally simple; it builds on a minimal set of concepts: stateful objects – things that exist, and processes – things that happen and transform objects by creating or consuming them or by changing their states. This duality is recognized throughout the community who studies systems, and sometimes goes by labels such as form/function, structure/function, and functional requirements/design parameters. Objects are what a system or product is. Processes are what a system does. Yet, it is remarkable that so few modeling frameworks explicitly recognize this duality. As a result, designers and engineers try to jump from the goals of a system (the requirements or the “program”) immediately to the objects. Serious theory in such disparate disciplines as software design, mechanical design and civil architectural design all recognize the value of thinking about processes in parallel with objects. Not only does OPM represent both objects and processes, but it explicitly shows the connections between them.
OPM has another fundamental advantage – it represents the system simultaneously in formal graphics and natural language. The two are completely interchangeable, conveying the exact same information. The advantage in this approach lies in appreciating the human limitation to the understanding of complexity. As systems become more complex, the primary barrier to success is the ability of the human designers and analysts to understand the complexity of the interrelationships. By representing the system in both textual and graphical form, the power of “both sides of the brain” – the visual interpreter and the language interpreter – is engaged. These are two of the strongest processing capabilities that are hard-wired into the human brain. Since each model fact is expressed both graphically and textually, in a subset of natural English, it is readily accessible to non-technical stakeholders, enabling them to take part in the early, critical stages of the system architecting and development, in which the most important decisions are made.
OPM allows a clear representation of the many important features of a system: its topological connections; its decomposition into elements and sub-elements; the interfaces among elements; and the emergence of function from elements. The builder of viewer of the model can view abstractions, or zoom into detail. One can see how specification migrates to implementation. These various views are invaluable when pondering the complexity of a real modern product system.
OPM semantics was originally geared towards systems engineering, as it can model information, hardware, people, and regulation. However, in recent years OPM started to serve also researchers in molecular biology, yielding tangible published new findings related to the mRNA lifecycle. This is a clear indication of the universality of the object and process ontology: As it turns out, one can use this minimal set of concepts to model systems in virtually any domain. Perhaps one exception is quantum physics, where our macro notions of particle (object?) and wave (process?), as well as matter (object?) and energy (process?) get fuzzy as we try to ‘inspect’ subatomic particles such as electrons. For any system from the molecular level up, all the way to the most complex natural, socio-technical and societal systems, the object-process paradigm works extremely well. OPM models concurrently explicate the function (utility), structure (form) and behavior (dynamics) of systems in a single, coherent model that uses one kind of diagram at any desired number of levels of detail by drilling down into the details of processes hand-in-hand with the objects they transform. The set of these self-similar object-process diagrams are represented not just visually, but also textually, catering to humans’ dual channel processing, a key cognitive assumption of how we process information to convert it into actionable knowledge.
Having realized the value of OPM to systems architecting and engineering, I adopted it in my thinking and teaching, and it has become an important cornerstone of courses I have been teaching in systems architecture at MIT and elsewhere. In particular, OPM has become a key element in the teaching of core courses in the Systems Design and Management graduate program at MIT. I have used OPM in the SDM System Architecture course. It has proved an invaluable tool to professional learners in developing models of complex technical systems, such as automobiles, spacecraft and software systems. It allows an explicit representation of the form/function duality, and provides an environment in which various architectural options can be examined. The addition of OPM to my subject has added the degree of rigor of analysis necessary to move the study of technical system architecture towards that of an engineering discipline.
OPM is also used as a representational framework in the new book which I co-authored, System Architecture: Strategy and Product Development for Complex Systems (Pearson, 2015), which develops an approach to architecture and demonstrates it with examples ranging from pumps, circuits, and sorting algorithms, to complex systems in networking and hybrid cars. Indeed, the task of architecting and engineering a new system has become more complicated by the increasing number of components involved, the number of disparate disciplines needed to undertake the task, and the growing size of the organizations involved. Despite the common experience that members of many organizations share, they often lack a common product development vocabulary or modeling framework. Such a framework should be based on system science, be able to represent all the important interactions in a system, and be broadly applicable to electrical, informational, mechanical, optical, thermal, and human components.
OPM provides such a framework. Indeed, in 2008, the task force of the International Council on Systems Engineering (INCOSE) has recognized OPM as one of the six leading model-based systems engineering methodologies. Looking at the historical development of engineering disciplines, it is an appropriate time for such a rigorous framework to emerge. Disciplines often move through a progressive maturation. Early in the history of an intellectual discipline, we find observation of nature or practice, which quickly evolves through a period in which things are classified. A breakthrough often occurs when classified observations are abstracted and quantified. These phases characterize much of the work done to date in system engineering and product development. Mature disciplines, such as mechanics, are well into the era of symbolic manipulation and prediction. Maturing disciplines such as human genomics are in the phase of symbolic representation.
OPM is a parallel development in symbolic representation of systems. Over the past two decades, the understanding of the need for systematic modeling capability has broadened. As OPM was developed in response to this growing recognition, so have other approaches. The most notable of these are UML, which includes 13 kinds of diagrams, geared for software engineering, and its derivative, SysML, which includes nine kinds of diagrams, designed more generally for systems engineering. Both SysML and OPM are listed as leading standards in the Guide to the Systems Engineering Body of Knowledge (SEBoK), an online ongoing project jointly sponsored by the Systems Engineering Research Center (SERC), the International Council on Systems Engineering (INCOSE), and the Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS).
SysML and OPM represent two different approaches to system modeling. In SysML up to nine diagrams are used, which are independently derived, and may not be completely consistent. In OPM one main diagram emerges. The need to integrate several kinds of diagrams may be more complicated. I make the distinction between complexity – the inherent fact that a system contains many parts interacting in multiple, often inexplicable ways, and complicatedness – the way a system model is presented through a certain modeling language and is perceived by a user. While there is not much we can do to reduce systems’ inherent complexities, we can and should strive to reduce the complicatedness of the representation to the bare necessities without sacrificing accuracy and details. OPM with its minimal ontology of stateful objects and processes favorably responds to this challenge.
While the emphasis of the book is on OPM, because of the relatively wider spread use of SysML, Dov has included SysML with adequate presentation of its syntax and semantics, as well as synergies with OPM, comparison with OPM in terms of such factors as length of the standard specification, and ways OPM can replace many SysML diagram kinds with a single diagram kind. The coverage of both languages in the same book is unique, as Model-Based System Engineering (MBSE) books to date have mostly used SysML. This dual coverage of OPM and SysML is highly valuable, since the reader gets deeper perspective on MBSE that penetrates beneath the idiosyncrasies of a particular conceptual modeling language.
I recommend using this textbook for an intermediate or advanced course in model-based system engineering, product development, engineering design, and software engineering. It would be ideal for courses that attempt to show how various disciplines come together to form a multi-disciplinary product. With OPM now formally recognized as an ISO specification, it can form the backbone of a corporate or enterprise modeling framework for technical products and large-scale socio-technical systems. Such a representation would be especially valuable in conceptual and preliminary design, when much of the value, cost and risk of a product are established, but when few other modeling frameworks are available for decision support.