Systems Thinking

The general reader can begin with General Systems Thinking (2015), an introduction written for scientists, engineers, managers and students of any discipline, which has been in use for forty years.[11] A manager of software who wants the same way of thinking applied to that trade can start with How Software Is Built (2014).[14]

The engineer new to modelling has MBSE with SysML and Eclipse Papyrus (2024), which builds a model of a coffee machine step by step in a free tool,[17] and The SysML v2 Book (2026), which describes the new version of the modelling language from its first concepts.[1] For the mathematics of feedback there is Control Systems Made Easy (2026), a practical guide for students and builders of robots and embedded devices.[23]

The practitioner can go to SYSMOD - The Systems Modeling Toolbox, 3rd edition (2020), a toolbox of methods for those who build system models or introduce modelling in an organisation,[2] and to The Craft of MBSE (2023), a catalogue of patterns and practices.[15] Advanced readers will find Variant Modeling with SysML (2016), on modelling the variants of a product, which assumes the language,[3] and Value Planning (2017), which its author calls a tough read meant for serious study.[5]

General systems theory was proposed in the middle of the twentieth century by biologists and others who saw the same patterns, of feedback, growth and regulation, in organisms, machines and societies; cybernetics, the study of control and communication, appeared at the same time. Systems engineering grew up separately in the telephone, defence and space industries, as a way of managing projects too large for any one discipline. From the 1990s its documents began to give way to models, and a standard modelling language for the purpose was published in the 2000s.

The books record the later chapters. General Systems Thinking was first published in 1975 and its two sequels complete a series planned then.[11] The SysML v2 Book recounts that the first version of the systems modelling language was built on a language designed some thirty years ago for object-oriented software, at a time when digital twins and artificial intelligence played no part in engineering; work on a successor began in 2014 and took more than ten years, the new standard being adopted in September 2025.[1] Variant Modeling with SysML places its subject in a change of industrial era, from mass production to what it calls mass customisation, in which a company must offer a very large set of variants of each product.[3] And AI Assisted MBSE with SysML (2024) belongs to the newest phase, in which engineers prompt AI tools to help build their models.[18]

General Systems Thinking teaches through named laws and principles, questions for further research and examples drawn from some two dozen fields, on the view that the same ways of thinking serve the physician, the engineer and the manager.[11] Its sequels divide a single question, why things stay the same. Passive Regulation (2014) studies stability that comes from the structure of a system, building an account of persistence from populations of parts with their births and deaths,[12] and Active Regulation (2014) studies regulation that corrects errors, with feedback loops, anticipation and the model a regulator holds of its environment, and ends with chapters on the ways people misunderstand regulation.[13]

The same author's System Design Heuristics (2018) is a deliberately unorganised collection of rules of thumb for designers. Its sample is a single checklist of the guesses on which a designer bets: that hardware will get faster and stay compatible, that costs of capital, labour and materials will or will not change, that usage will grow at some rate and follow some pattern, that the builders will understand the design and the maintainers will change it without corrupting it, that users will be trained, will make errors and may try to beat the system. The designer is asked to include a guess about the designer too, whether the users and the business are understood, and to use the list twice: to guess better, and to record the assumptions so that customers know what the success of the design depends on.[4] How Software Is Built opens a companion series on software with the patterns by which managers try to control development and the dynamics that make projects hard to steer.[14]

Model-based systems engineering replaces the documents of a project with one model of the system that every discipline shares. SYSMOD - The Systems Modeling Toolbox, 3rd edition presents a methodology for it and is careful about the words. A process says what is to be done and a method says how; a methodology is a consistent set of processes, methods and tools, to which the author adds products and roles, so as to include the people. Its toolbox has three kinds of thing: products, the significant artefacts of development such as the requirements or a description of the architecture; methods, the best practices for creating a product; and roles, each responsible for certain products and methods. The relations are stated exactly: every method has one role that answers for it, takes products as inputs and yields at least one as output, and every product has one responsible role. Processes in this scheme are guidelines and not rules, since mastery of the craft matters more than obedience to a sequence, and a real project uses a selection of the methods in its own order with many loops. The book pairs the methodology with the standard modelling language without requiring it, and gives its second chapter to the responsibility of engineers for what their systems do to the planet: those who use a system bear the first responsibility for its effects, the author writes, but those who built it have the expertise to influence the outcome. An annex maps the methodology to the international standard for life-cycle processes.[2]

The other books on method take different lines. The Craft of MBSE starts from the observation that the move from documents to models is a change of culture and structure as well as of tools, and that modelling is too often applied as one more administrative task; it offers patterns, practices and principles in the spirit of craftsmanship.[15] Pain-Free MBSE (2026) is organised as a catalogue of habits that its authors think make modelling harder than it need be, each with an alternative.[16] MBSE with SysML and Eclipse Papyrus teaches by one continuous example, from requirements and stakeholders to behaviour,[17] and AI Assisted MBSE with SysML carries a single design, a scientific instrument, from a model of its domain to tested software, listing the AI prompts used at each step.[18]

Variant Modeling with SysML deals with one hard case, the product that exists in many variants. A variant usually touches only a few parts of a system, the book says, but each point of variation adds a dimension to the model: an engine that may be diesel, electric or hybrid, combined with a chassis in three forms, already gives nine cars. Nor is there an objective measure of how far a variant may differ before it is a different system; a car and an aircraft are both transport, and it is useless to model them as variants of one thing, because what they share is too abstract. The reasons for modelling variants are a product line, a customised product and the comparison of alternative designs, and the rule is that the benefit must exceed the cost of managing a more complex model. The method defines a core, variation points, variations and configurations within the standard language, so that no separate tool is needed. Its author self-published it in order to revise it as projects taught more, and says so.[3]

The SysML v2 Book describes the language itself and is independent of any method or tool. A modelling language, it explains, defines syntax and meaning and says nothing of how it should be used, as a natural language has spelling and grammar and does not tell anyone how to write an essay. The first version was built on the general modelling language of software engineers; the second is built on a new kernel language with formal semantics, developed alongside it and a standard in its own right, which removes the chief weakness of the first, the imprecision of its meaning. The new version has a textual notation equivalent to its diagrams, and a standard programming interface through which a model can be read and changed whatever tool made it. The authors call this a change of foundation and not an update, and they are clear that the language is one component of an engineering approach that also needs processes, methods, tools and people. The kernel may in time carry other languages, and a modeller need not learn it before learning the language built on it. The chapter on the discipline begins from an awkward question. A software engineer can point to source code and a mechanical engineer to drawings and parts; what, the authors ask, can a systems engineer show?[1] A course by the same authors, SysML v2 Certification Model User (2026), is a bank of questions in the style of the certification examination for users of the language.[19]

A system begins with what is wanted of it. Exploring Requirements One (2014) treats that as a human problem of ambiguity and negotiation: its chapters cover ambiguous statements, questions that can be asked before anything is known of the context, the choice of the right users, the running of meetings and the handling of conflict.[20] The Practical Guide to Agile Requirements Enginering (2025) organises the same work for agile product development around a fixed set of artefacts, from business goals and scope to quality requirements and constraints, with one product worked through as an example.[21] A Little Book about Requirements and User Stories (2017) is a short book of heuristics for the smallest unit of requirement in agile software.[22]

Value Planning goes furthest towards measurement. It is a training text in a planning language for stating what stakeholders value as numbers and delivering it in small measured steps, and its introduction states the hope that readers will come to see planning not as the conventional exercise but as the dynamic and measurable delivery of value to those with a stake. The book is frank that it is no light overview, and each section ends with a practical tip and a suggested policy. Conventional practice, its author admits, turns as slowly as a great ship, and is changed one person, one project and one company at a time.[5]

Feedback, the idea the general theory borrowed from engineering, has its own textbooks. Control Systems Made Easy runs from the feedback loop and the transfer function through the tuning of the common three-term controller to state space and digital control.[23] Kalman Filters Made Easy (2026) explains the filter that combines noisy measurements with the predictions of a model, on the ground that sensors alone jitter and models alone drift,[24] and Model Predictive Control Made Easy (2026) introduces the kind of control that predicts ahead over a horizon and respects constraints.[25]

Two tutorials apply statistics and machine learning to industrial plants. Machine Learning in Python for Dynamic Process Systems (2024) is about building models of dynamic processes from plant data,[26] and Machine Learning in Python for Process and Equipment Condition Monitoring, and Predictive Maintenance (2024) about detecting and diagnosing faults and predicting the need for maintenance. The second insists that the classical statistical methods are not obsolete and are still widely used to monitor processes; it therefore covers the whole range, from simple control charts to deep-learning estimates of the remaining life of equipment, and addresses process engineers entering data science as well as data scientists entering the plant, assuming undergraduate mathematics and no experience of machine learning.[6]

Software that runs is a system with operators. Team Guide to Software Operability (2021) defines its subject as how well software works in production and argues that operations should be treated as skilled work that adds value. Its authors, one from operations and one from development, observe that teams tend to think their systems unique when the operational needs that make or break them are nearly the same everywhere, and they recommend that a team write its run book together, using a common template to find the gaps in what it knows, and return to it regularly. Some of their themes belong to the movement that joined development to operations, they say, and others to critical thinking, engineering practice and the understanding of human factors.[7] Architecting Agentic Systems (2026) describes a newer structural problem. A traditional system has a control flow fixed in advance; an agentic one places a probabilistic reasoning component inside that deterministic shell, so that some decisions are made by a part whose behaviour is not fully described at design time, right most of the time, plausible nearly always and occasionally wrong in ways that are hard to foresee. The book compares the change to earlier ones, such as the move from programs on one machine to distributed systems, which brought partial failure and messages out of order: each produced a new class of failure and a body of patterns to meet it, and the discipline took a generation to catch up. Autonomy, the book says, is an operational state to be bounded by infrastructure, and the system must be engineered so that the shell catches the model's errors.[8]

Failure and its prevention are the subject of several books. Errors (2017) asks what errors cost, where they come from and how to live with them,[27] Handbook of Technical Reviews, Fourth Edition (2014) is a handbook of the formal review,[28] and What Drives Quality (2018) lists the factors that drive quality along the whole chain from request to delivery.[29] Claude Code for Legacy Modernization (2026) applies analysis to an existing system: recover its rules and flows first, then show that the replacement behaves the same.[30]

The organisation is the largest system of all. Quintessence (2022) holds that an organisation's effectiveness is a function of the beliefs its people share, and that those beliefs interlock, so that pressing on one makes the others tighten.[9] Stop Facilitating, Start Leading (2026) shows the same thing in a delivery pipeline, where a feature that takes six days of work waits fourteen weeks for approvals that no single team controls.[10]