“Innovation” is not limited to the context of introducing new commercial products, services, and technologies. We can learn from the study of innovation in more general settings.
Human-engineered, human-kludged, and living biological or other natural systems not originated by humans are frequently under pressure to adapt. Those pressures originate in opportunities or competition, predators or other threats, changing environment, physical or cyberattack, or from other quarters. The ability to adapt well enough as conditions change, especially in the presence of variation and uncertainty, can be very valuable–agility can mean survival. Systems (including developmental and life cycle management systems) that adapt well enough in time, cost, and effectiveness are sometimes called “agile”. Agile methods, even in engineering, did not start with agile software methods, although those have garnered a lot of attention in recent years [1].
A reference model of agility is emerging concerning innovation of systems in general, whether human-engineered or otherwise, and whether agility is high or low.
Agile systems engineering is the subject of a 2015-16 global discovery project by the International Council on Systems Engineering (INCOSE), a 25-year-old global professional society of 10,000 members concerned with improving methods of systems-level engineering across all human domains. INCOSE is active across many areas through its Working Groups, encouraged standards, guides and handbooks, and programs of education and certification, plus local chapter and regional events and programs [2].
The Changing Face of Systems Engineering
Systems Engineering is changing rapidly, as a relatively young (perhaps 60-year-old) discipline. Three intertwined threads of that change are:
- The rise of model-based methods (Model-Based Systems Engineering, orMBSE) shifting emphasis from process and procedure to underlying information, like other engineering disciplines;
- Emergence from MBSE of Pattern-Based Systems Engineering, or PBSE, including Product Line Engineering (PLE) based on MBSE-based System Patterns [3];
- Re-casting what has been learned about Agile methods in software development, other engineering, adaptive systems, biology, and the underlying framework of the physical sciences into the world of MBSE and PBSE.
The Agile Systems Engineering Life Cycle Management (ASELCM) Pattern [4] describes an enterprise’s innovation process without requiring the subject business adopt MBSE, PBSE, or other methods, and showing where they fit into the broader history of innovation in engineered and natural systems and the physical sciences. The diagram below is a top-level view of three systems in that pattern:
System 1: The Target System (and Its Components)
The system of interest, potentially agile, which results from, or is subject to, innovation. Its characteristics or availability are targets of the life cycle innovation (change, adaptation), through iteration, experiment, feedback, and learning. Examples include aircraft, automobiles, telephones, satellites, the human immune system, software, restaurants, birds, and the health care delivery system.
System 2: The Target System (and Component) Life Cycle Domain System
The system within which the Target System (System 1) will exist during its life cycle, when “in service” or otherwise, including all actors with which the Target System will directly interact any time during its life cycle. It includes the operational environment of System 1. It also includes any system that directly manages the life cycle of an instance of System 1 or its component subsystems–systems of development, production, integration, maintenance and operations.
LC Manager of Target System: Manages any life cycle aspect of the Target System, as recognized by ISO 15288. However, it manages only “already known” aspects of System 1 and its Target Environment—it does not include responsibility of learning new things.
Learning & Knowledge Manager for Target System (and Components): Responsible for learning new things about the Target System, its Components, and its Environment. This may include extraction of patterns or other knowledge from observations, planning experiments and extracting conclusions from their results, and other forms of learning. It also includes responsibility for accumulation and persistent memory of those learnings.
System 3: The System of Innovation
The system that includes System 1 and System 2, and that is additionally responsible for managing the life cycles of instances of any (System 2) Target System LC Manager.
Let’s assume we are in the business of design and construction of commercial buildings (System 1s) in a changing market. Experience has taught us that a set of blueprints and specifications for our System 1 buildings is essential, and they can be found at the construction site of each new building. We have learned that when we want to incorporate new ideas into our buildings, changing their blueprints and specifications has a high probability of producing a new building incorporating the change—changing those blueprints is the focus of changing a future System 1.
But if we instead want to change our methods of building construction, which is System 2–how do we usually make that change? We might meet with construction teams, send memos, or conduct training, and expect to encounter resistance to change and a steep learning curve. When it comes to System 2, there is no full equivalent to the blueprints of System 1. So, why would we expect that changing System 2 can be done in as agile a fashion as changing System 1?
Is this a rationale for formal specifications for both System 1 and System 2? On the contrary, agile engineering methods [5] have suggested that we should instead value a “working” (customer accepted) System 1 building over formal specifications of System 1, and those methods have focused on human learning during iterative “sprint” cycles, when there is uncertainty and change in the definition of System 1. Long delays in creation of System 1 specifications can mask risk by delaying eventual discovery that we are planning the wrong building.
However, systems engineers have also learned that “information debt” can occur when the rate of System 1 evolution outruns the availability of learned System 1 information needed to manage System 1 over its ongoing life cycles. Balancing this inherent tension is a cornerstone of the Agile Systems Engineering Life Cycle Management Pattern.
[1] Leffingwell, Dean, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley 2011
[2] International Council on Systems Engineering (INCOSE)
[3] INCOSE/OMG Patterns Working Group 2015
[4] Schindel, W., and Dove, R., “Introduction to the Agile Systems Engineering Life Cycle MBSE Pattern”, to appear in Proc. of the INCOSE International Symposium, Edinburgh, Scotland, July, 2016.
[5] Fowler, M., and Highsmith, J., “The Agile Manifesto”. Dr. Dobb’s Journal, August, 2001.
The above article was authored by Bill Schindel, President of ICTT System Sciences. His engineering career began in mil/aero systems with IBM Federal Systems, and included faculty service at Rose-Hulman Institute of Technology and the founding of three systems enterprises. Bill co-leads the INCOSE Patterns Working Group, is a member of the lead team of the INCOSE Agile Systems Engineering Life Cycle Project, and is the president of the Crossroads of America Chapter of INCOSE.