Systems Science

January 2008

Vol 11 Issue 1

SPECIAL FEATURE

Systems Science:

Deepening Our Understanding of the Theory and Practice of Systems Engineering 1 Overview of Complexity Essays – White

2 Integrating and Unifying Old and New SE Elements – Hybertson and Sheard

4 Systems Engineering and Complexity – Honour

5 Boundaries – Schoening

7 Asks the Chief Engineer: “So what do I go do?! – Norman and White 8 Ethnic Culture and Systems Engineering Process – Ferris

3 Complex and Complex Systems Engineering – Hayenga

6 Emergence in Systems Engineering – Ryan

9 Is INCOSE a Complex System? – Sheard

SCSE-INCOSE-12/07.qxd:SEA-INCOSE-1/07.qxd

12/16/07

11:31 AM

Page 1

Modern society depends on large-scale software-intensive systems of astonishing complexity. For almost all interesting systems, the majority of the value is delivered through software and the majority of the engineering challenges are addressed through software. Because the consequences of failure in such systems are so high, it is vital that the software be assured or trustworthy; i.e., it has the characteristics that users depend on, including correctness, security, safety, and availability. Applying best practices based on sound underlying principles is essential in building complex software-intensive systems. Such practices address ways to specify, design, implement, test, and evaluate these systems in ways that enhance their trustworthiness. The courses in the Certificate in Systems-Centric Software Engineering address software engineering in a way that integrates critical aspects of systems engineering and incorporates best practices to make those systems trustworthy. Courses offered in convenient one week modules or in traditional semester formats. Courses delivered online, on-campus in Hoboken, on-site at the Applied Systems Thinking Institute (ASysT) in Arlington, VA, and at corporate/government agency locations worldwide.

FOR ADDITIONAL INFORMATION: Dr. Arthur Pyster, Distinguished Research Professor, School of Systems and Enterprises

Email: [email protected] or Beth Austin DeFares, Associate Director of Outreach and Communications, School of Systems and Enterprises

Email: [email protected]

Please visit our website at:

2

Volume 11 No. 1

INCOSE INSIGHT

Castle Point on Hudson, Hoboken, NJ

www.stevens.edu/sse

President’s Corner

President’s Corner Paul Robitaille, [email protected]

INSIGHT

Publication of the International Council on Systems Engineering Chief Editor [email protected] Assistant Editor [email protected] Theme Editor [email protected] Advertising Editor [email protected] Layout and Design [email protected] Member Services [email protected] On the Web Article Submission

Bob Kenley (260) 460-0054 Andrew Cashner Brian White Alope Bennett (800) 366-1164 Chuck Eng (206) 364-8696 INCOSE Central Office (800) 366-1164 http://www.incose.org [email protected]

Publication Schedule. INSIGHT is published four times per year. Issue and article/advertisement submission deadlines are as follows:   April 2008 issue – 15 February; July 2008 issue – 15 May; September 2008 issue – 10 July; January 2009 issue –15 November; For further information on submissions and issue themes, visit the INCOSE Web site as listed above. Advertising in INSIGHT. Please see http://www.incose.org/Products Pubs/periodicals/insight.aspx – or email [email protected]. Subscriptions to INSIGHT are available to INCOSE members as part of their membership. Complimentary copies are available on a limited basis. Back issues are available on the INCOSE Web site. To inquire about membership or to order a copy, contact Member Services. ©2008 Copyright Notice. Unless otherwise noted, the entire con­ tents are copyrighted by INCOSE and may not be reproduced in whole or in part without written permission by INCOSE. Permission is given for use of up to three paragraphs as long as full credit is provided. The opinions expressed in INSIGHT are those of the authors and advertisers and do not necessarily reflect the positions of the editorial staff or the International Council on Systems Engineering. Who are we? INCOSE is a 7000+ member organization of systems engineers and others interested in systems engineering. Its purpose is to foster the definition, understanding, and practice of world class systems engineering in industry, government, and academia. INCOSE is com­prised of chapters located in cities worldwide and is sponsored by a corporate advi­ sory board and led by elected officers, directors, and membership board. 2008 INCOSE Board of Directors President: Pat Hale, M.I.T. President-Elect: Samantha Brown, BAE Systems Secretary: Bob Kenley, Kenley Consulting Treasurer: Ricardo Valerdi, M.I.T. Director for Leadership and Organizational Development: Bill Ewald, Macro International Director for Communications: Christian Tulodieski, Northrup Grumman Director for International Growth: Tat Soon Yeo, Temasek Defence Systems Institute Director for Commercial Outreach: Henk van der Linden, SRON Corporate Advisory Board Chair: Art Pyster, Stevens Institute of Technology Member Board Chair: Gunter Daley, Siemens – UGS PLM Software Member Board Co-Chair: Jonette Stecklein, NASA Technical Director: Dick Kitterman, Northrup Grumman Managing Executive: Shirley Bishop, Shirley Bishop Inc.

Past Presidents Paul Robitaille, 2006/07 Heinz Stoewer, 2004/05 John Snoderly, 2002/03 John Clouet, 2001 Donna H. Rhodes, 2000

Ken Ptack, 1999 William W. Schoening, 1998 Eric C. Honour, 1997 V. A. (Ginny) Lentz, 1996

James Brill, 1995 George Friedman, 1994 Brian Mar, 1993 Jerome Lake, 1992

Dear colleagues, It has been four years since you elected me as your president. The first two years were a learning opportunity as I served as president-elect to Heinz Stoewer. One immediate lesson I learned was that I would never equal his style in speaking to large audiences. Another lesson, one of many actually, was the need for our leadership team to focus on strategic thinking. I think both of these lessons have benefited our organization. It spared you any attempt on my part to equal my predecessor as a public speaker and it helped me to focus on something I could be productive with! INCOSE thanks you, Heinz! Thanks to the hard work of the leadership team and many fellow INCOSE members, we have continued to mature as an organization in the past two years. We are thinking, planning, and acting in ways that are enhancing our reputation and enabling us to establish ourselves on a global scale. Briefly, I would like to note just a few of the significant accomplishment we have made together over the past few years: Outward-Looking: • Admitted to ABET as an accrediting society for systems engineering academic programs • Developed a community Systems Engineering Vision and are working to establish a coalition of systemsengineering-related organizations and societies to assure we achieve the vision • Established three new INCOSE chapters – China, Japan, and Singapore • Established active outreach campaigns in Brazil, China, India, and Russia • Extended and strengthened our agreement with the Association Française d’Ingéniere Systéme (AFIS)

• Improved our relationship with the Systems Engineering Society of Australia (SESA) • Signed a memorandum of understanding with the International Test and Evaluation Association (ITEA) • Established a formal liaison with the Capability Maturity Model® Integration (CMMI) Project • Established an Systems Engineering Educators Leadership Forum • Established the first-ever International Military Systems Engineering Educators Forum • Continue to be an active member of systems-engineering-relevant industry standards forums • Continue to provide timely technical review and comment to industry and government systems-engineeringrelated policies and guidance • 2008 International Symposium scheduled in Utrecht • 2009 International Symposium scheduled in Singapore Products and Services: • Launched a contemporary, enhanced Web site and collaboration environment • Launched iPub, with online search and retrieval for all historical symposium, European Systems Engineering Conference (EuSEC), and Conference on Systems Engineering Research (CSER) papers, plus others (available to all members) • INSIGHT is back on a quarterly cycle with a paid editor • Published a systems engineering reference curriculum for U.S. master’s programs and will soon publish one at the doctoral level • The Certified Systems Engineering Professional (CSEP) certification exam has been updated to track with version 3 of the Systems Engineering Handbook • Jointly developed systems engineering leading indicators measures > continues on page 4

INCOSE INSIGHT

January 2008

3

President’s Corner

President’s Corner

continued from page 3

• Korean-language translation of version 2 of the Systems Engineering Handbook • Intelligent Enterprise Knowledge Claims • Significant contributions to the release of the SySML standard • Pioneer work underway on modelbased systems engineering • Developed the Regal requirements tool Inward-Looking: • Have grown to over six thousand members • The Corporate Advisory Board has grown to over fifty members • Corporate Advisory Board subgroups are improving the board’s effectiveness and engagement • Director for Commercial Outreach made a voting Board of Directors member to reflect importance of role • Appointed a Marketing Director

• Appointed a Director for International Outreach • Established new working groups for safety, security, cost engineering, lean systems engineering, resilient systems, systems engineering process improvement and measurement (CMMI) • Have especially active working groups for requirements, intelligent transportation, human–systems integration, and the Model-Based Systems Engineering Challenge As you can see from the above, which is only a selection of our many activities, it has been a very productive two years indeed! INCOSE is well poised to provide the leadership required to advance the practice of systems engineering in partnership with other systems-engineeringminded organizations worldwide. The Systems Engineering Vision, developed

and enhanced as a community project, established a unifying objective from which many interesting partnerships can emerge. Working together through these partnerships we can assure that the future of systems engineering as a relevant and exciting profession is indeed bright. It has been both a challenge and an honor to serve as your president these past two years. I thank you all for your support, encouragement, and hard work! I would like to extend my best wishes to each of you, your families, and loved ones as we enter the new year. We have reason to celebrate!

Paul Robitaille INCOSE President

Corporate Advisory Board — Member Companies Alliant Techsystems BAE SYSTEMS Boeing Commercial Airplane Co. Boeing Integrated Defense Systems Boeing Integrated Defense Systems – East Booz Allen Hamilton Inc. C.S. Draper Laboratory, Inc. Carnegie Mellon University Software Engineering Institute Center for Systems Engineering at Air Force Institute of Technology Defense Acquisition University Delphi Corporation EADS Astrium EADS Military Air Systems Federal Aviation Administration (U.S.) General Dynamics Honeywell International ITT Space Systems Division Japan Manned Space Systems Corporation JAXA (Japan Aerospace Exploration Agency)

4

Volume 11 No. 1

INCOSE INSIGHT

Jet Propulsion Laboratory Johns Hopkins University L-3 Communications Integrated Systems Lockheed Martin Corporation Mitsubishi Electric Corporation National Aeronautics and Space Administration National Geospatial - Intelligence Agency National Reconnaissance Office National Security Agency Naval Surface Warfare Center  – Dahlgren Division Northrop Grumman Corporation Northrop Grumman Information Technology Northrop Grumman Information Technology – TASC Office of the Under Secretary of Defense (AT&L), Systems and Software Engineering Project Performance International QinetiQ Raytheon Corporation Raytheon SAS

Rockwell Collins, Inc. Rolls Royce Corporation Saab AB SAIC Sandia National Laboratories Siemens – UGS PLM Software SPAWAR Systems Center Charleston Stevens Institute of  Technology Swedish Defence Materiel Administration Systems and Software Consortium Inc. Systems Engineering Innovation Centre Telelogic AB Thales The Aerospace Corporation The MITRE Corporation UK MoD Integration Authority United Technologies Corporation Missouri University of Science and Technology University of Southern California US Army ARDEC Vitech Corporation

Special Feature

INSIGHT Special Feature

Systems Science: Deepening Our Understanding of the Theory and Practice of Systems Engineering Brian White, [email protected]

I

n Part 1 of his article, “A Challenge for Systems Engineers: To Evolve Toward Systems Science” (in INSIGHT 10:3), John N. Warfield challenges “systems engineers to move toward a systems science platform for systems engineering.” In Part 2 in this issue, he discusses “behavioral research and … pathologies that frustrate attempts to resolve complexity.” I recommend that you read both of these essays, as well as Stephen Cook’s essay on “The Science of Systems Engineering and the Engineering of Complex Systems,” to gain a broader understanding of what systems science is all about. This special issue is limited to just one important aspect of systems science — complexity. A couple of years ago INCOSE’s Systems Science Enabler Group (SSEG) decided to concentrate on complexity, complex systems, and complex systems engineering as a potentially fruitful area of exploration in systems science. Providing a single definitive treatise on how complex systems engineering enhances the practice of systems engineering in a way that satisfies the majority of the INCOSE membership would be an impossible task, particularly considering the voluntary nature of our efforts. Instead, we produced a series of individual essays that would interest and inform systems engineers about the principles of complexity theory. I hope that exposure to these mindsets, which are different from those usually associated with “traditional” or “conventional” systems engineering, might help practitioners in our most difficult systems engineering environments. A few enabler group members have already published four essays in past issues of INSIGHT, available at our public Web site (http://www.incose.org/practice/ techactivities/wg/sseg/). The group brainstormed and discussed more than fifty ideas for essays, and after considerable cajoling by me,

members generated eighteen draft essays. Other group members reviewed the draft essays, and the authors revised them accordingly. My cochair Sarah Sheard and I suggested that the authors of some of the longer essays submit their papers to Systems Engineering, INCOSE’s refereed journal, and we settled on eight shorter essays for this special issue. We encouraged the authors of the remaining essays to consider submitting them for future INSIGHT issues. The authors have written their essays with the goal of presenting their own views to inform and challenge the thinking of the INCOSE community. It is appropriate to note that, although the selected essays were shared with the Systems Science Enabler Group, they should not be considered products of the enabler group per se, but rather statements of positions from these individual members, somewhat tempered by comments of other members. So, these essays are statements of positions that can be argued, debated, or discussed in trying to advance our collective systems engineering thinking. The following diagram serves as a 1 Overview of Complexity Essays – White

teaser and provides a rough logical order of the essays. Duane Hybertson and Sarah Sheard explain some of the basic differences between “old” and “new” types of systems engineering in Essay 2. In Essay 3, Craig Hayenga attacks the controversial topic of “complicated versus complex.” Eric Honour echoes this topic of systems engineering and complexity in Essay 4. Essays 5 and 6, by Bill Schoening and Alex Ryan, respectively, discuss boundaries and emergence — both very popular topics in the literature about the engineering of complex systems, systems of systems, and enterprises. Doug Norman and I offer some thoughts on what this all might mean to one new way of practicing systems acquisition, where users rather than developers compose the systems. Tim Ferris, in Essay 8, delves into cultural issues of systems engineering in a world where different countries practice systems engineering in different ways. Finally, in Essay 9, Sarah Sheard describes INCOSE itself as a complex system and discusses the implications. We hope you enjoy this special issue of INSIGHT and look forward to your feedback.

2 Integrating and Unifying Old and New SE Elements – Hybertson and Sheard

4 Systems Engineering and Complexity – Honour

5 Boundaries – Schoening

7 Asks the Chief Engineer: “So what do I go do?!” – Norman and White 8 Ethnic Culture and Systems Engineering Process – Ferris

3 Complex and Complex Systems Engineering – Hayenga

6 Emergence in Systems Engineering – Ryan

9 Is INCOSE a Complex System? – Sheard

INCOSE INSIGHT

January 2008

5

A Challenge for Systems Engineers: To Evolve Toward Systems Science (Part 2 of 2) | John N. Warfield, [email protected]

I

n Part 1 of this essay, I challenged systems engineers to move toward a systems science platform for systems engineering and introduced seven component challenges to focus attention upon the possibility of doing so. Several pioneering systems engineers have adopted and tested such a platform of systems science and found it to be versatile and effective. In Part 2, I discuss findings in behavioral research and present the two methods from systems science that work

around the well-established behavioral pathologies that frustrate attempts to resolve complexity. Ignored Behavioral Findings In the second half of the twentieth century and in the early part of the twenty-first century, behavioral scientists in some of the best-known institutions of higher education in the world have made discoveries that have major implications for all forms of activity involving synthesis, including strategy development,

policy design, and systems engineering. As near as can be determined from reports in the media, these findings have been largely ignored. As is often the case when individual researchers report results, the connections between the results go unperceived, even among the researchers themselves. I will summarize the results from behavioral pathology studies that are connected and have a bearing on the seven challenges, leaving a more thorough examination to those who are interested in taking up

Table 1. Relevant Behavioral Pathology Studies

6

Author(s) and Year

Brief Title

Nature of Finding

Miller (1956); Simon (1974) verified Miller’s results

Span of Immediate Recall (“Magical Number Seven”)

I: Shows that a human being can only bring into short-term memory about seven items at a time.

Lasswell (1960, 1971)

Situation Room, Observatorium

SG: Shows the importance of infrastructure in policy development and system design, and in learning on the part of those who follow up policy or system design activity by access to large visual displays.

Lasswell (1960, 1971)

The Pre-legislature

SG: Presents the need to develop policy concepts in depth before the political process begins, rather than relying on ad hoc design in political settings.

Tuckman (1965)

The Unstructured Four-Stage Group Process

SG: Presents the typical pattern of group work when no scientific structure is available, showing how much time is wasted, in effect, in social overhead, which may never converge to results.

Downs (1966, 1994)

Predictability of Bureaucratic Behavior

O: Explains why bureaucrats behave the way they do. (Thus, unless a process is imposed, only those situations that are responsive to bureaucratic behavior will yield.)

Allison (1971)

Groupthink

SG: Shows how otherwise bright individuals will “go along to get along” and how they did so in high-level planning for the Bay of Pigs incident.

Vickers (1980)

Language Degradation

I, SG, O: Shows that terms like system are being degraded by narrowing their meaning to fit what suits particular groups, thereby limiting the utility of the words and polluting the language.

Argyris (1982)

Inertial Hypocrisy

O: Shows what happens when every problem is treated the same way, when there are issues that cannot be discussed, and when organizational behavior is wrongly described.

Janis (1982)

Groupthink

SG: Provides a thorough description of groupthink in action, showing how very bad decisions emerge from groups, even though the individuals involved would not support the decisions.

Warfield (1989)

“Magical Number Three”

I: Shows that when variables are all interrelated: three variables and their relations use up the magical number seven, so that the human mind without the aid of logic is much more limited than previously believed.

U.S. Department of Defense program managers with H. C. Alberts (1994)

Structural Incompetence

I in O: Explains the appearance of incompetence on the part of governmental employees whose behavior is forced upon them by governmental structures.

Warfield (1995)

Spreadthink

SG: Provides clear evidence that for systems involving complexity, every informed individual has a different perception of what the more important problems are in the situation under investigation—with drastic implications for leadership.

Kruger and Dunning (1999)

Inaccurate Self-Assessment

I: Shows that the incompetent rate themselves too high, and the competent rate themselves too low.

Volume 11 No. 1

INCOSE INSIGHT

Special Feature

the challenges. The table lists a group of results from behavioral pathology studies arranged from top to bottom in chronological order along with an identification of the author who characterized the pathology. A brief title (not necessarily the one assigned by the discoverer) is assigned to each result. The highlighted letters I, SG, and O in the third column in the table refer respectively to the individual, the small group, and the larger organization. Generally speaking, whatever applies to the individual automatically flows through to the small group and then to the organization, if the individual is acting in a small group which is part of an organization. Consequently, in studying the pathologies, it is probably most appropriate to study first those affecting the individual, and then those affecting the small group, trying to keep in mind how the individuals’ pathologies will affect behavior in the small group and, if that can be absorbed, imagining how the entire panoply of pathologies flow through into the organization. It is a fundamental tenet of systems science that these pathologies can be avoided by applying processes based in systems science, provided that those processes themselves are designed in the light of the behavioral pathologies. This condition is a key contribution of the systems science described in my 2006 book and its predecessors, and that is why I feel comfortable putting forth this challenge. Individual Pathologies. The cluster of pathologies marked I in Table 1 reflect, in the worst instance, the prospect that individuals will overestimate their own personal competence, or that they will believe that they themselves can correctly bring into memory all of the relevant variables in a situation and assess properly the existence of the multiple relationships among them, leaving only the numerical or dynamic details to be worked out (perhaps by subordinates). Even if none of these descriptions applies, the individual may be forced to make decisions under the impact of organizational constraints that override individual competence; these constraints act as virtual pathologies. Whatever the individual may conceive, even if high in quality, is subject to formulation in the

dysfunctional language carried forward from a time when the concept of systems was just beginning to be perceived as significant, and language grew spontaneously to fit the bubbling needs of the moment. This cluster of difficulties now carries forward into the consideration of group pathologies, which are particularly important in the complexities of these times. Group Pathologies. Of the three types of pathologies — individual, group, and organizational — the type most amenable to direct observation and data-taking, and consequently the most reliable and replicable, are the group pathologies. Spreadthink. The pathology that is probably the least known is called “spreadthink.” It can be readily and reliably confirmed, because it is a replicable process that occurs across cultures, organizations, and situations. Spreadthink is a consequence of the fact that in a complex situation, every individual with insight into the situation has a different opinion on what constitutes the most important problems to be resolved. It is normal to expect at least forty problems, and one should not be surprised to find at least one hundred fifty problems involved in these situations. Henry Alberts and his program managers found over six hundred problems to be resolved in the defense acquisition system. The manager who intends to move ahead by working on the subset of problems that his or her intuition says are the most important will automatically generate opposition from others who are intimately involved in helping to resolve the situation. This is the message rendered by the spreadthink discovery. The message rendered by systems science is that there is a direct way to overcome this. Groupthink. Groupthink has been heavily documented to occur at the highest levels of the American government, and there is little doubt that it occurs often. This pathology is not as easily demonstrated as spreadthink. Spreadthink is documented automatically as part of the normal process of resolving complexity provided by the application of systems science. To document groupthink, on the other hand, requires that data be taken that would not necessarily be gathered in the ordinary process of attempting to reach a decision on some

difficult issue. It would likely require special permissions particular to each situation. Nonetheless, groupthink is very well defined, and its various dimensions are easy to observe. One approach to observing groupthink is by conducting interviews after the fact, as was done for Graham Allison’s highly detailed study of the decision-making process leading up to the 1961 invasion of the Bay of Pigs. Organization Pathologies. Organization pathologies typically are very difficult to examine scientifically. The literature, nonetheless, can be examined by large numbers of people since so many people spend so much time in organizations. Because so many people are able to assess the literature, it seems very likely that those authors whose works rise to the top and who have spent substantial time in organizations are reliable in content. Chris Argyris has consulted with many organizations and has generalized on certain attributes of most of them. Anthony Downs has elaborated in great detail on the predictability of the behavior of bureaucrats, explaining why they behave the way they do. Authors like Argyris and Downs furnish reliable data that individuals who interact as clients with such organizations can test frequently in a variety of ways. When it comes down to attempts to resolve complexity, in which individuals in organizations are involved at different levels within the organization, all of the pathologies come into play at the same time, with the individual pathologies seeping into the group behavior, and the group behavior seeping into the organizational behavior at the various levels. Moreover, there is feedback around these levels that is unpredictable in its effects, but that cannot be assumed to be helpful in light of the fact that the feedback is subject to the same pathologies. Systems Science And Behavioral Pathologies As systems thinking has evolved over the past several decades, researchers have proposed far too many theories and methods to enumerate here. One wellknown systems personality has referred to this situation as “panacea overload.” The situation has also been described as a collection of “paradigm villages” > continues on next page INCOSE INSIGHT

January 2008

7

Special Feature

The Science of Systems Engineering and the Engineering of Complex Systems Stephen Cook, [email protected]

few years ago, what is now the Defence and Systems Institute of the University of South Australia accepted a task from the Australian Defence Science and Technology Organisation to prepare a paper outlining the science of command and control. The assignment proved insightful and we extended our work beyond the original assignment to that recorded in Cropley et al. (2005). By the time we completed that paper we began to understand that any definition of science in such a context would involve a broad range of concepts, methods, philosophies, and ideas. It is from that background that I open this paper. To draw from Cropley et al. “The word ‘science’ itself is derived from the Latin scientia meaning ‘knowledge’ (Collins, 2001). Dictionary definitions typically focus on two aspects of the meaning of the term. The first relates to the nature of the knowledge itself, for example: (a) ‘Systematic knowledge of the physical or material world’ (RHD, 1967), or, (b) ‘Knowledge – especially that gained through experience’ (AHD, 2006). These definitions also highlight the physical or experiential nature of knowledge in the context of science. The second aspect of the meaning of the term relates, in particular, to the process by which such knowledge is obtained, for example: (a) ‘The observa-

Challenge

continued from page 7

surrounded by mountain ranges with no interconnecting roads. Virtually all of these theories and methods ignore the behavioral pathologies. These pathologies can be safely ignored when the situations being analyzed or when the design being considered is simple enough that the pathologies do not come into play. For situations in which the pathologies cannot be safely ignored, systems science provides the Nominal Group Technique (NGT) and an interactive, computer-assisted technique called 8

Volume 11 No. 1

INCOSE INSIGHT

tion, identification, description, experimental investigation, and theoretical explanation of phenomena’ (AHD, 2006) or, (b) ‘Knowledge or a system of knowledge covering general truths or the operation of general laws especially as obtained and tested through scientific method’ (AHSD, 2002).” For a more comprehensive understanding of the nature of science one need only turn to the writings of the history and philosophy of science. There are over two hundred books in that category in our university library, which reinforces the fact that science is hard to define! Introductory texts such as Rosenberg (2005) describe the aims of science in such terms as the production of knowledge about the world, the epistemology of science (how science enables us to know things and the limits of that knowledge, and the principal schools of thought such as logical positivism, empiricism, and those included in post-modernism. It does not take long before the reader is confronted with the realisation that the esteemed position that scientific knowledge holds within our society can be hard to justify from a philosophical basis. This was an unintended consequence of Kuhn’s seminal work (1970) that described the historical practice of science: Kuhn used the term paradigm to describe the theoretical framework that includes the world view,

accepted theories, assumptions, methods, instruments, and problems that constitute the way reality is viewed by the scientific community that shares them. Kuhn described how a branch of science progresses from one paradigm to another when enough influential scientists believe that the newer paradigm offers better explanatory power than the former. Kuhn’s description of the political and social processes that take place during a paradigm shift led authors such as Chambers (1990, Chapter 2) to assert that there is no one scientific method and that scientific inquiry is indeed a social process that changes over time and across fields of endeavour. In the context of this paper, this thought helps us to accept that we should consider the term science in a broad sense and that we need to appreciate that in a field as broad as systems engineering, there will be a number of scientific paradigms that inform our practice. I find it useful to again follow the tack of Cropley et al., who went from the dictionary definitions of science to the definitions of disciplines that include science in the title. For example, they point our that management science focuses on “improving our understanding of the practice of management,” whereas political science can be “regarded as the branch of social science that studies politics,” and lastly they cite that computer science is “the systematic study

Interpretive Structural Modeling (ISM). These two methods are the only methods of systems science, and they are both designed to be group methods. Applied together, they work around the behavioral pathologies. This has been demonstrated repeatedly in a wide variety of situations and is documented extensively in the literature. The question may arise, however, as to what role the other theories and methods that have proven themselves in applications play in relation to the systems science. The answer is that these play the same role as

before. When appropriate, the requirement for them will emanate from the application of systems science, which provides organization and insight. In this way, the other theories and methods will be no longer be accidents of imagination, but rather the product of thoughtful group activity that applies system science methods to scour the situation space in search of sufficient consistency, insight, coherence, and consensus to make it possible to define requirements and sequences for a work program that will resolve complexity.

Special Feature

of computing systems and computation.” Cropley et al. found it reasonable to conclude that any rigorous empirical activity which seeks to acquire and apply a body of knowledge about a particular topic or field can be regarded as a science. On the basis of the preceding arguments and a foray into the philosophy of science, Cropley et al. contend that it is reasonable to propose a general definition of science as a combination of • an organised body of knowledge about a particular area of interest or endeavour, • the methods used for acquiring that body of knowledge, and, • the processes and methods of applying the body of knowledge. In retrospect, I now realise that this is consistent with the definition of a paradigm, given that the world view and the accepted theories can be found in the body of knowledge, and that the accepted instrumentation is inherent in the methods. A number of us at the Defence and Systems Institute have been building on this foundation for several years. One of our interests is to get a good understanding of what systems engineering is and the areas it covers in contrast to other disciplines. Cook and Ferris (2007) outlines our arguments as to why systems engineering should receive more prominence among management scientists as the approach of choice for any complex systems problem that can be expected to involve a substantial technical component. That paper commenced by citing Sage (2006), who states that the current concern of systems engineering includes the technical systems developed, (the “end product systems”); their interaction with the human and environmental stakeholders; the systems that support the users’ use of the systems, (the “enabling systems”); and the organisations doing the development work, (the “process systems”). The realisation that system engineering involves at least four systems, three of which are predominantly social systems, gives pause for thought about the fundamental sciences that systems engineering needs to embrace. In our quest to define systems engineering in terms of a discipline, we have found considerable utility in the concept

that a discipline must possess four attributes (Kline 1995:3): • a specific area of study (A), • a literature that embodies a framework of ideas that underpin the discipline (F), • an agreed methodology (M), and • a working community of paid scholars and/or practitioners. Cropley et al. carried this concept further by recognising that there must be two methodologies: one that applies when the discipline is marshalled to tackle a problem in the area of concern, and a second to build the framework of ideas. Cook and Ferris set forth to describe each of these for systems engineering and in so doing make a strong case that systems engineering should be considered a metadiscipline that draws on the philosophies and frameworks of ideas from many disciplines and uses correspondingly many methodologies from science, engineering, mathematics, engineering management, and social disciplines in order to achieve its ends. This position is reinforced in the “Fellows’ Edition” of Insight (8: 2) in which appeared many largely synergistic but different opinions from the INCOSE Fellows on what constitutes the fundamentals of systems engineering. I believe that this divergence of views stems from multiple personal formations and frameworks of ideas and each of these can be mapped onto corresponding methodologies that can tackle particular areas of

concern that arise as sub-problems in systems engineering. This view is completely consistent with contemporary systems thinking, found in management science circles, that recognises that the days of the grand narrative and the grand unifying theory are behind us, and that the world needs to look to pluralism to tackle the broad range of issues that confront both management and society in general (Jackson 2000). Before pursuing the pluralist view further, it is worth thinking about what an overall framework of ideas for systems engineering might comprise. In this venture, the logical place to start is in the articulation of the top-level areas of concern. For the purposes of this paper, the definition from the INCOSE Technical Vision (2005) is usefully comprehensive: “Systems engineering is a professional endeavor that leads to the engineering of a system of humans, organizations and technologies through knowledge management efforts associated with bringing the perspectives of all stakeholders to the associated issues to bear, such as to enable the appropriate: definition of the system to be engineered such as to achieve needed capabilities and fulfill requirements; development of the system through appropriate architecture, design, and integration efforts; and ultimate deployment of the system in an operational environment and associated maintenance and > continues on next page

Technology Practical cultural activities: Includes hardware, software, and their social and technical context.

Science Systematic study of the physical world and its life forms; aimed at knowledge and understanding

Engineering Science Science adapted for use in engineering practice

Engineering Science, art, and judgement, applied to design construction and use of material and machines (includes engineering management)

Figure 1. Relationships between technology, science, engineering, and engineering science (from Johnston et al. 1999) INCOSE INSIGHT

January 2008

9

Special Feature

Science of Systems Engineering

continued

reengineering of it throughout a useful lifetime of trustworthy service to these stakeholders.” This statement tells us that the area of concern of systems engineering is fundamentally the engineering of enduring sociotechnical systems. We have found it useful to draw on the philosophy of engineering as a starting point for identifying aspects of the overall framework. In many discussions, engineering is considered to be synonymous with science. Checkland (1981), however, clearly elucidates the difference between the aims and methods of professional scientists and engineers. According to Checkland, science attaches the highest value to the advancement of knowledge, whereas engineering prizes most highly the efficient accomplishment of some defined purpose. Hence, the principal question that scientists ask is “Have we learned anything?” whereas the engineers and technologists ask “Does it work?” Johnstone et al. (1999) devote a chapter of their book to the philosophy of engineering. They concur with Checkland’s position and see engineering as occupying the space shown in figure 1, i.e., as being fully embraced by technology and intersecting with science. Thus, not surprisingly, they conceive that a philosophy of engineering will combine aspects of the philosophy of science with the philosophy of technology. Crawford (2005) states that engineers need to adopt a mosaic of philosophical types. He shows how engineering draws on a range of philosophical positions; for

10

Volume 11 No. 1

INCOSE INSIGHT

example, empiricism, which professes the importance of practice and knowledge gained through experimental observation, and rationalism, which states that theory based on a priori knowledge is the most important aspect of knowledge. Crawford states that engineers are informed by both. He states that it is clear that rationalism has become the more powerful force in engineering education, although he states that it is equally obvious that there is a great need for empiricism in the practice of engineering. Indeed, my experience as a design engineer has taught me that while engineering science forms the basis for new designs, there are always numerous important aspects of the design that have to be informed by knowledge of what works in practice; knowledge that cannot be expressed in equations. Johnstone et al. conclude that each of a variety of philosophical positions has provided a useful basis for certain engineering activities but that none is sufficient as the guiding framework for all of engineering. Johnstone et al. admit that their work is but a beginning, saying that a philosophy of engineering would need to cover the ability of engineers to synthesise working designs with limited formal knowledge of the principles they are employing and with incomplete knowledge of the technical aspects of implementation. It would also need to cover the philosophy of values and cover ethics, and aesthetics, in order to deal with the broad range of issues that enable the product being designed to be suitable for its intended purpose in life. In Johnston’s figure, I consider

systems engineering to be a technology. In saying that, I mean that systems engineering includes knowledge from mainstream science and mathematics, i.e., the engineering sciences that so dominate university education. It also includes all aspects of engineering from across the engineering disciplines, and, most importantly, it includes the practical knowledge of what works, when considering systems engineering problems. In addition to science and engineering, another substantial shaper of the framework of ideas for systems engineering is the epistemology of systems thinking. Checkland (1981) regards systems thinking as a response to the failure of natural science to tackle complexity, many real-world problems, and social phenomena. System thinking is the antithesis of Descartes’ reductionism, the mainstay of the scientific community: the technique of breaking down problems into their components and solving the component problems in order to build understanding of larger issues. In Jackson’s words (2000: 2), systems thinking “… respects the interconnectedness of the parts and concentrates on the relationships between them and how these often give raise to surprising outcomes — the emergent properties. Systems thinking uses models rather than laboratory experiments to try and learn about the behavior of the world and even then does not take for granted or impose any arbitrary boundary between the ‘whole’ that is the subject of attention, in the model, and the environment in which it is

Special Feature

located. Instead it reflects on upon and questions where the boundary has been drawn and how this impacts on the kind of improvements that can be made.” Similarly to the world of science and engineering, there are many systems thinking approaches: Jackson (2000) describes over twenty designed to tackle management issues. Furthermore, Jackson is a strong advocate of pluralism in the form of using more than one methodology to gain insight into complex problems. How, then, may engineering and systems thinking be combined to tackle complex problems? Barton (2007) in his recent PhD thesis, makes a notable contribution by advocating the importance of systems thinking within the scientific method. He argues that the scientific method is not solely analytic (as is often stated) but is in fact an ongoing spiral dialectic between analysis and synthesis. He sees the process starting with the observation of surprising facts that are synthesised using abductive reasoning (the selection of the hypothesis that best fits the evidence) within a systemic context into a new hypothesis that is subsequently tested through action and analysis using deductive and inductive reasoning from which further hypotheses are synthesised. When tackling complex systems engineering problems, I would like to suggest that an analogous process takes place, in that systems thinking helps the practitioner conceive of the problem situation in its context and use this representation to help synthesise potential solutions. Each of these potential solutions is then analysed against a set of criteria to derive the preferred solution for further consideration. In this way the design of a system can progress in a systemic, iterative way from the user needs statement to the completed detailed design. In smaller-scale engineering projects, the spiral dialectic concept maps well onto the traditional engineering development process that proceeds through a sequence of prototypes until the product system demonstrates its worth, in both an engineering sense and within the social system in which it is intended to operate.

Thus I argue the framework of ideas for systems engineering, as a whole, comprises the compendium of frameworks from the disciplines it harnesses, coming from science, engineering, and management perspectives. I see these disciplines being more integrated than is often thought to be the case, and I suspect that what is emergent in systems engineering is its application methods 1 and its specific heuristic technical knowledge, rather than its science. What, then, constitutes complex systems science? The same lines of argument apply here as with systems engineering, I shall conclude by referring to Alex Ryan’s erudite presentation on the subject (2006). He argues that complex systems science comprises the following three endeavors: • The search for structural (organisational) properties independent of composition • The study of systems in context, relative to an observer • The study of mechanisms of dynamic pattern formation over multiple scales Thus we can conclude that complex systems science encompasses systems thinking together with the disciplinary science that one draws on in systems engineering. In addition to these, Ryan explicitly names pattern formation, as exemplified by self-organisation, collective behaviour, and networks; multiscale analysis (which incorporates hierarchy theory, emergence, and universality); and dynamics that covers attractors, feedback, adaptation and evolution. This paper is very much a work in progress, but it contains features that I suspect will endure. The first is that a framework of ideas for systems engineering will include a number of empiricallybased sciences, whether natural or social sciences, and their attendant paradigms. Within each paradigm are both accepted methods for advancing these sciences, plus methods that direct their application to real-world, sociotechnical problems. It is the overall methodology of systems 1. These methods are recorded in standards (e.g., ISO/IEC 15288, 2002) and in guidelines, for example, the INCOSE Systems Engineering Handbook (2006), and are embodied in workplacebased knowledge.

engineering, informed by systems thinking, that provides the wisdom to know which methods to use, at which times, for which problems. As these sciences enrich our understanding of the world, I expect systems engineering to progress in order to cope, more predictably, with complexity. References AHD. 2006. The American heritage dictionary of the English language, s.v. “Science.” 4th ed. Accessed online via http://www.dictionary.com (15 October 2007). AHSD. 2002. American Heritage Science Dictionary, s.v. “Science.” Accessed online via http://www.dictionary.com (15 October 2007). Avison, D. E., and D. Fitzgerald. 2003. Information systems development: Methodologies, techniques and tools. 3d ed. London: McGraw Hill. Barton, J.A. 2007. Systems thinking: Philosophy, methodology and application to knowledge management. PhD dissertation, Monash University. Chambers, A. 1990. Science and its fabrication. Minneapolis: University of Minnesota Press. Chapter 2. Collins. 2001. Collins concise dictionary, s. v. “Science.” 5th ed. Glasgow: HarperCollins. Cook, S.C., and T. L. J. Ferris. 2007. Re-evaluating systems engineering as a framework for tackling systems issues. Systems Research and Behavioral Science 24: 169-181. Crawford, A. 2005. Philosophy of engineering. http://www.cwr.uwa.edu.au/cwr/outreach/envirowa/essays/general/philosophy.html#The%20 Philosophy%20of%20Science (accessed 20 June

2005). Cropley, D. H., N. Sproles, and S. C. Cook. 2005. The science of command and control (C2). Journal of Battlefield Technology 8 (1): 15–23. Haskins, C., ed. 2006. Systems engineering handbook: A guide for system life cycle processes and activities. Version 3. Seattle: INCOSE. INCOSE. 2005. INCOSE technical vision. Version 1.1. Seattle: INCOSE. Jackson, M. C. 2000. Systems approaches to management. New York: Kluwer Academic/Plenum Publishers. Johnson S., P. Gostelow, and E. Jones. 1999. Engineering and society: an Australian perspective. 2nd ed.. South Melbourne: Longman. Kuhn, T. 1970. The structure of scientific revolutions. 2nd ed. Chicago: University of Chicago Press. RHD. 1967. Random House dictionary of the English language, s.v. “Science.” Unabridged ed. Rosenberg, A. 2005. Philosophy of science: A contemporary introduction. 2nd ed. New York: Routledge. Ryan, A. 2006. What is complex systems science? Proceedings of the Pan-TTCP Symposium on Complex Adaptive Systems for Defence. Glenelg, Adelaide, Australia: Defence Science and Technology Organisation.

INCOSE INSIGHT

January 2008

11

Faculty Positions Opening The Air Force Institute of Technology (AFIT), Graduate School of Engineering and Management (located on Wright Patterson AFB in Dayton Ohio) is an NCASC accredited institute of higher learning offering a variety of master’s and doctorate level degrees in traditional and innovative disciplines of engineering and management. All engineering degrees are ABET accredited at the graduate level. The Department of Systems and Engineering Management (AFIT/ENV) is seeking to fill two tenure-track assistant/associate professor positions in the following disciplines (US citizenship is required): 1. Systems Engineering with a focus on rapid product development and infrastructure systems (to include general systems theory, process and management, systems analysis, and engineering economics). A PhD in Systems Engineering, Industrial Engineering, or closely related field is required. The successful applicant will have broad education/experience in the application of systems engineering principles across a wide range of organizational, infrastructure, and engineered systems in order to bring a broad integrating approach to all department activities. 2. Systems Integration and Cost Analysis with a focus on the application of econometrics. A related PhD is required with a general understanding of systems engineering processes and management, integration of architecture, and systems analysis. Responsibilities will include teaching mathematical economics, graduate level econometrics, as well as classes in the regional, public, and industrial organization areas. Competitive individuals will also have extensive experience collaborating with academic disciplines across both engineering schools and business schools. This experience is demonstrated either by published research or consultation on projects dealing with systems integration. Highly desirable is someone with analytical experience in general decision analysis approaches, development and the use of metrics, utility theory, system dynamics, optimization, and risk (making decisions under uncertainty). The department offers degrees in rapid technology development, engineering management, information resources management, cost and financial analysis, environmental science and engineering to include occupational health, and systems engineering. Focused research streams include infrastructure development and management, crisis management (battle field and natural disasters), systems integration in chemical, biological, radiological, and nuclear response, organizational change, cyber warfare and information assurance, business process re-engineering, quantitative human health risk analysis, integration of human-machine systems, and rapid technology transition. Successful candidates will be expected to develop outstanding externally funded research programs that build on these core intellectual strengths. Current faculty also find it useful to collaborate with other researchers through various centers on campus including the Center for Systems Engineering, the Center for Rapid Production Development, the Center for Cyberspace Research, and the Center for MASINT Studies and Research, as well as with researchers within the many directorates of the Air Force Research Laboratory which is co-located on Wright Patterson Air Force Base. Applications will be accepted until the position is filled. All applications received before 31 January 2008 will receive full consideration. Applicants should send a resume, a statement of research and teaching interests, and three letters of recommendation to Dr Michael Shelley Chairman, Faculty Search Committee Department of Systems and Engineering Management AFIT/ENV, B-640, Suite 101 WPAFB OH 45433 [email protected] • FAX: (937) 656-4699 AFIT is a Federal institution that is an equal opportunity employer.

12

Volume 11 No. 1

INCOSE INSIGHT

Special Feature

Integrating and Unifying Old and New Systems Engineering Elements 1

Duane Hybertson, [email protected], and Sarah Sheard, [email protected]

T

he field of systems engineering is currently experiencing a significant expansion of scope beyond its comfort zone. The expansion is predominantly in the general area of “complex systems,” by which we mean systems that behave more like organisms and less like machines. Systems engineering is therefore at a juncture in its history where it needs to strengthen and extend its methods to support this new realm of application. We also argue that the old and extended methods must be integrated in a new unified systems engineering. The problem is thus one of both extension and unification. This paper defines the problem and suggests an approach to solving it.

Old and New Systems Engineering “Old systems engineering” follows a mechanistic model; “extended systems engineering” follows an organic model. “New systems engineering” is a combination or hybrid of the old and the extended that must be unified. “Old Systems Engineering”: Mechanistic Over the past half-century, systems engineering has developed as a multidisciplinary field in certain areas of application, most notably aerospace and defense. It has also been applied in fields from transportation to medical and information systems. Systems engineering was developed to promote a holistic approach to systems, in contrast to focusing on each separate part and addressing integration, if needed, as an afterthought. The systems engineering that has been in play during this period, commonly called “classical,” “ordered,” or “traditional systems engineering,” has achieved considerable success. Traditional systems engineering has a reasonably well-understood stance toward the systems it engineers. The traditional view 1. Many of the ideas in this paper come from a forthcoming book by Duane Hybertson, Model Oriented Systems Engineering: A Unifying Framework for Traditional and Complex Systems, to be published by Taylor & Francis Group.

of system characteristics is that they are large-scale and multidisciplinary, that they have well-defined interfaces and are relatively stable and predictable, and that they are designed by an external agent — a systems engineer. System components exclude people. In the traditional approach, people usually play one of three roles, all of which reside outside the system, and the approach treats them as distinct from the system: systems engineer, project manager, and user or operator. Therefore, in the traditional view, people are not system components; at least, they are not engineered in the way system components are engineered. These characteristics reflect a “systemas-machine” metaphor — a mechanistic view of systems. “Extended Systems Engineering”: Organic and Multi-scale Systems engineering is beginning to address other types of systems, such as organizations, “systems of systems,” enterprises, and other socio-technical systems, as well as biological systems and nanosystems. Such non-mechanistic systems represent a category often called complex systems. The complex systems stance toward these systems is that they experience continual change, are autonomous and self-organizing. They are highly interconnected, and the behavior of the whole system emerges from or depends in a significant way on the interactions between components. They include humans or other agents as system components. They are adaptive: they learn, grow, and evolve in response to their environment. These characteristics reflect a “systemas-organism” metaphor—an organic view of systems. This understanding of a system contrasts to some degree with that of traditional systems engineering described above. For more information on the complex systems view, see, for example, Axelrod and Cohen (1999), Boccara (2004), Holland (1992), and Sussman (2002). Boccara describes a basic set of complex system models.

Another feature of the organic or complex systems extension to systems engineering is a different perspective on some constructs that are viewed negatively in traditional systems engineering. In complex systems, constructs such as the following are viewed as positive or at least potentially positive: • Change. Change is something to be avoided in traditional systems engineering, or at least carefully controlled. In the complex systems approach, change is viewed as a natural process. It can be positive, negative, or neutral, but in general, change reflects learning, growth, improvement, adaptation, and the development of necessary capabilities. • Risk. Traditional systems engineering attempts to minimize or avoid risk. The complex systems approach should examine the opportunity side of risks as a potential positive—as the potential for significant gains. In addition, the practice of integrity management includes a more systemic approach to risk • Uncertainty and lack of control. The traditional approach tries to maintain maximum control and to minimize uncertainty. The complex systems approach includes the practice of yielding control to systems that exhibit autonomy and self organization, which reduces the amount of instructions or specifications necessary • Contradiction and paradox. Traditional systems engineering seeks to achieve consistency and avoid contradiction, paradox, tension, and contrast. The complex systems approach embraces contradiction, tensions, and contrasts as representing balance and diversity, in the spirit of yin and yang. Complex systems thinking holds in balance both order and disorder (they coexist as part of the same system); both the one and the many (a system is one whole, and is also many parts); both the discrete and the continuous. This is exhibited at multiple scales — for > continues on next page INCOSE INSIGHT

January 2008

13

Special Feature

Old and New SE Elements continued

example, light is both a wave and a particle). The complex systems approach reconciles these contrasts by using views. The Needed New Systems Engineering: Composite of Old and Extended It is necessary but not sufficient to define complex systems engineering in contrast to traditional systems engineering. Conceptualizing the systems of the past as machines and the systems of the future as organisms brings important concepts to the table, but it leaves out an important reality: most systems that systems engineers will develop in the future will be a combination of machines and people—not strictly one or the other. This also means that systems engineers will be creating systems that are neither wholly artificial (like the traditional machine) nor wholly natural (like human beings), but are a hybrid of both. Therefore, replacing the traditional methods with ones designed for more complex systems, or even adding the complex methods to the traditional ones, is not adequate. Both traditional and extended methods must be integrated into a unified and seamless systems engineering of complex systems. In response to the above arguments, we have defined a taxonomy of system characteristics that captures our view of the relations between traditional and complex systems. This taxonomy (shown in figure 1) shows four groups of characteristics. Some characteristics are common to all systems (group 4). Many of these come from the field of systems science. For other characteristics, traditional sys-

3. Special case 4. Common to all

1b Complex systems

1a Traditional systems

1b Complex

2a Traditional 3 Traditional 4

Complex

Traditional and Complex Science Foundation

Figure 1. Taxonomy and foundation of unified systems engineering

14

Volume 11 No. 1

INCOSE INSIGHT

Other supporting sciences

2. Different in degree

Foundation: Systems Science and Other Sciences Figure 1 shows the foundation of systems science and other supporting sciences. Systems science (“SS” in the figure) is a substantial element of the foundation and its support for unification. The other supporting sciences include, first and foremost, complex systems science, as well as physics, chemistry,

SS

1. Different in kind

tems are a special case of the more general complex case (group 3). An example of this is a model of a traditional system that assumes deterministic behavior, as opposed to a model of a complex system that assumes probabilistic behavior. Deterministic behavior is a special case of probabilistic behavior with certain outcomes assigned a probability of one. Many characteristics display a difference in degree between traditional and complex (group 2). These reflect a spectrum from most traditional to most complex. Examples are “degree of uncertainty,” with traditional being the most certain, and “degree of autonomy,” with the traditional being the least autonomous. Finally, some characteristics represent a difference in kind (group 1). For example, a complex system can learn, while a traditional system cannot. This depiction of these groups of characteristics, to the extent that it reflects the actual relation between traditional and complex systems, argues for a unified systems engineering. Our approach to bridging and integrating systems engineering has two dominant features, namely, the incorporation of a foundation of supporting sciences, and a framework of model orientation.

biology, nanosystems sciences, psychology, sociology, economics, organization theory, anthropology, political science, urban planning, operations research, computer and computing science, game theory, network science, and linguistics and formal languages. In addition, the foundation includes both continuous math (such as calculus) and discrete math (such as logic). These latter two map approximately to quantitative and qualitative models. Unification: Model Orientation Model orientation is the most important factor in the unification of systems engineering, and is pervasive throughout the taxonomy shown in figure 1. The basic concept of model orientation is that one regards all artifacts across the engineering spectrum, as well as the scientific and mathematical foundation, as models. Our view is that model orientation is the culmination of a trend over the past decade. The practice of modeling and simulation has long been a significant element of traditional systems engineering. In recent years the flavor and scope of modeling has been evolving and extending beyond simulations. A number of modeling languages, standards, and methods have emerged in software engineering and systems engineering: • Wayne Wymore’s 1993 book, ModelBased Systems Engineering, describes an approach to systems engineering using discrete mathematical models for all artifacts. • Unified Modeling Language (UML) for software engineering, defined in the late 1990s, has been modified and extended into the systems engineering area as the Systems Modeling Language (SysML) (OMG 2007). • INCOSE’s Technical Vision 2020 (2006) discusses model-based systems engineering. Friedenthal (2006) discusses the benefits and requirements of model-driven systems engineering, and Friedman (2006) discusses the opportunities and challenges of unifying systems engineering through modeling. These examples show that model orientation is being extended from traditional

Special Feature

Modeling Space In a model-oriented approach, a structure called the modeling space plays a dominant role. The modeling space func-

Highest-level system

tions as a systems engineering knowledge repository as well as an engineering workspace of the models for developing a specific system. More specifically, it contains and organizes all models—not only systems engineering artifacts but also models of supporting sciences and mathematics. Partial modeling spaces come in various forms, including traditional engineering handbooks, published bodies of knowledge, patterns books, reference architectures, and standards. In the future, perhaps online hyperlinked virtual repositories of models will be the norm. How is the systems engineering modeling space structured? We distinguish and structure models according to the following four dimensions and one unconstrained concept, as shown in figure 2. (1) Composition. Composition exhibits a repeating, self-similar pattern in that a given whole is part of a larger whole. Models in this dimension address the concepts of whole and part. (2) Commonization. Categorization tells us what is common among a set of individuals. Generalization tells what is common among a set of categories or kinds. These relations are types of commonization. Models in this dimension address the concepts of category or instance, along with general category or specific category, such as class or subclass. (3) Conceptualization. By its nature, systems engineering is multi-lingual and > continues on next page

Modeling space Composition

Recognizable in this sampler are classical engineering artifacts such as requirements and design. Traditional engineering artifacts include the concept of operations, the requirements, and the architecture or design of a system (including hardware drawings and diagrams, software documentation, and source code), as well as simulation models of a system. Clearly, simulation models fit the definition of model we have given. What about the other artifacts listed? What is the benefit to thinking of these as models? This is an important question. We claim that calling a document a model, while it does not change the document, does tend to change the perspective of the observer. We may have been content with the material as a narrative or graphic in a document, but when we think of it as a model, we start think-

ing about what variables, properties, behaviors, interactions, and constraints are involved, and which are the most important. In a word, we start thinking more precisely. For example, suppose we have a set of “shall” statements in a requirements document, such as “The system shall do function A,” “The system shall do function B,” and the like. If this is simply a document, we tend to think in terms of whether the functions are properly stated, whether we have included all the necessary functions, and so on. But if we now think of this as a model of the desired system, it naturally causes us to think more comprehensively about the system and its environment. Under what conditions do we want the system to do A or B? Do A and B interact or interfere with each other? If there is a conflict, which is to take precedence? Can A and B occur together? If so, under what conditions? Or if not, how do we make that clear? Other questions involve dependencies, ambiguity, what levels of quality and performance are needed, and whether the models are too general, too specific, or over-constraining. The number of questions and quality of the system thinking increase just because we think of the artifacts as models, for we know how to question models.

Indivisible Unit

Engineering domain

Model of individual system or component

Universal model

C • omm • K in d on i Ca s z a t io t eg n or i es

simulation models to a more pervasive concept of models. Model orientation considers the artifacts of engineering and the theories, laws, and observations of science to be models of systems. This perspective aligns systems engineering with related disciplines, based on our belief that models are the naturally dominant perspective, repository of knowledge, and vehicle of communication in all engineering and science disciplines. In systems engineering many qualitatively different things are modeled: • whole systems — parts of systems and their interaction; • the system’s environment and the interaction of the system with that environment, such as with suppliers or service providers, with customers or service consumers, or with peers; • structure, behavior, entities, interactions, and relations; • properties — including traditional ones such as performance or quality, as well as fuzzy, and stochastic ones; • attributes, qualities, and categories; • operations or processes; • change, cost, and constraints; • what is allowed, what is mandated, and what is prohibited; • what is common and what is unique; • views; and • information about the models themselves.

Problem/user domain Conceptualization • Language/notation • Universe of discourse

Time is another dimension: models change or represent change across time Views exist within and across all the dimensions

Figure 2. Structure of the modeling space

INCOSE INSIGHT

January 2008

15

Special Feature

Learn and practice the concepts, and the methods are easy!

Systems of Systems

Real student comments explain it best:

3 days

Technical Leadership in a Networked World

“With this better understanding, I can now provide more effective inputs for the overall system development.”

A truly unique course combining complexity theory and its application to very complex, networked systems – solutions in the areas of architecting, integration, collaboration, and T&E – with the SwarmBot Collective Emergent Robotics exercise. Orlando, FL Baltimore, MD Minneapolis, MN

Honourcode, Inc.

3008 Ashbury Lane, Pensacola, FL 32533

Old and New SE Elements continued

has multiple universes of discourse, due to the variety of application domains, typically even within one system. Models in this dimension serve as representations of systems or other universe of discourse elements in a specific language; they can be formal (uninterpreted), or interpreted with a particular semantics; they can also play the role of an ontology. (4) Time. Models and systems have a lifespan in which they are created, in which they exist and change during their existence, and in which they come to an end. We need a time variable to accommodate change and to address past and future, evolution, differences over time, and rates of volatility and stability. Models in this dimension represent processes, events, change, trajectories, or other temporal elements. View is a concept of unconstrained structure; it can exist within or cut across dimensions. A view is a subset of a model, or of a collection of models. We need to look at cross-cutting issues, and to have the flexibility to combine Volume 11 No. 1

INCOSE INSIGHT

“Excellent course. One of the most useful in recent years.”

26-28 Feb 08 8-10 Jul 08 4-6 Nov 08

Instruction Instruction focused focused on on why why we we do do it, it, not not just just what what to to do do

16

“The robotics were interesting and provided a direct tie-in to the material.”

Applied Systems Engineering

4 days End-to-end instruction on SE and the thought patterns that underlie it – includes a System Challenge to build interoperating Lego robots Minneapolis, MN Orlando, FL Washington, DC

15-18 Apr 08 25-28 Aug 08 10-13 Nov 08

Register for classes or get more information at our web site +1 (850) 479-1985

[email protected]

into one entity or view any collection of items from anywhere in the modeling space. The modeling space defines a starter set of generally applicable views. Models that play the role of view can be positioned in any or all of the four dimensions. Each of the dimensions is self-similar at different levels or scales. For example, the same constructs and relations — and in fact all aspects of model-oriented systems engineering described in this article — support the systems engineering of a large system, such as an aircraft, and the engineering of any of its parts, such as an engine. The approach scales from nanosystems to large enterprises, and extends across multiple time scales. We believe the science foundation and model orientation provide a sound approach for bringing together the traditional mechanistic methods and the extended organic methods into a unified systems engineering discipline of the future.

http://www.hcode.com

References Axelrod, R., and M. Cohen. 1999. Harnessing complexity: Organizational implications of a scientific frontier. New York: Free Press. Boccara, N. 2004. Modeling complex systems. New York: Springer. Holland, J. 1992. Adaptation in natural and artificial systems: An introductory analysis with applications to biology, control, and artificial intelligence [complex adaptive systems]. Cambridge, MA: MIT Press. INCOSE 2006. Systems Engineering Vision 2020., Version 2.0. Seattle: INCOSE. Friedenthal, S. 2006. Reaping the benefits of model driven systems engineering (MDSE). INSIGHT 8 (2): 14–15. Friedman, G. 2006. On the unification of systems engineering. INSIGHT 8 (2): 16–17. OMG (Object Management Group). 2007. OMG model driven architecture. http://www.omg.org/ mda/. Sussman, J. 2002. Collected views on complexity in systems. MIT ESD Working Papers Series, ESD-WP-2003-01.06, May 2002. Available directly at http://esd.mit.edu/WPS/ESD Internal Symposium Docs/ESD-WP-2003-01.06-ESD Internal Symposium.pdf or at http://esd.mit.edu/ WPS/topic.htm.

Wymore, A. W. 1993. Model-based systems engineering: An introduction to the mathematical theory of discrete systems and to the tricotyledon theory of system design. Boca Raton, FL: CRC Press.

Special Feature

Complex and Complicated Systems Engineering Craig Hayenga, [email protected]

I

n a recent Newsweek commentary, Jerry Adler (2007) suggested that the first rule of modern political discourse is that before addressing any empirical problem each side must “frame the debate” in the most favorable way. This often shows up as a struggle over what we should even call something. We see this from time to time as we continue to struggle with a definition of system and we have also seen it in recent struggles with definitions of systems of systems. As we grapple with defining the foundations of systems engineering in our Systems Science Enabler Group and with exploring new ways of doing systems engineering that embrace the new field of complexity theory, I believe one way to gain insight into the debate is to frame it with the exploration of two terms: complicated and complex. From a quick survey of the systems engineering literature I have found that the words complex and complicated are used interchangeably throughout. This is to be expected, as the standard dictionary definitions also tend to treat the terms as synonymous. Dictionary. com defines complex (as a noun) as “an intricate or complicated association or assemblage of related things, parts, units, etc.” and (as an adjective) as “composed of many interconnected parts; characterized by a very complicated or involved arrangement of parts, units, etc.” Similarly, this dictionary defines complicated as “composed of elaborately interconnected parts; complex.” These circular definitions show that common usage does not make any distinction between the two words. So why would I suggest having them carry separate meanings rather than continuing with the common practice of using them interchangeably? I would suggest that the separation will help illuminate a significant — if nascent — change in how we engineer systems. As we move beyond the confines of our historical systems engineering literature, we are encountering the new

field of complexity theory (alternately called complex systems sciences). Within this field the concept of complex takes on a new specific meaning, a new technical usage that can prove problematic to systems engineers’ habit of using the term interchangeably with complicated. Complexity theory has a much different take on complex systems, many of which are not complicated at all. Quite often, we hear systems with many thousands of interacting parts, like the Space Shuttle or B-2 bomber, described as complex. I would suggest that maybe we need to consider those with many interacting parts to be complicated rather than complex. This is not a suggestion merely for semantics alone. First, this way of describing things allows a more informed dialogue with the complexity community and avoids confusion in meaning. The second reason to use this terminology is to explore what might change in how we engineer systems as a result of that dialogue. This is a bit speculative for now, but the separation of terms helps clarify some of the changes that are appearing on the horizon. While many discussions continue on the span of complexity theory, as it makes inroads into fields from business organization to the humanities and physics, most researchers, scholars, and thinkers agree that complex systems have emergent properties that are not predictable in advance. Such properties are often demonstrated with computer simulations. These emergent properties are repeatable, assuming the composition and interactions of the system are identical. But any small change will result in a behavior that is not predictable in advance. This impact of small changes was discovered in the sister field of chaos theory, which had its beginnings in weather models. It was not the uniqueness of the model that led to chaos theory, but a new way of seeing and interpreting the results of the model. We still see these effects in models of climate change, which have become more and

more complicated as more variables and interactions have been added to make the models more realistic. Complex interactions emerge, showing unfolding patterns of change, the consequences of which cannot be foreseen. When working with complex systems, one usually can only forecast general trends. I don’t believe the process of engineering a system is that much different. Traditionally within systems engineering we work to a specification or a set of requirements that defines the positive attributes of the behavior of a system. Quite often in practice, when we actually design and build the system, in order to make those positive behaviors respond appropriately, we end up adding a number of complications to the design to eliminate undesirable behaviors. For example, to meet a stability requirement in a power supply, we might have to add a snubber circuit to prevent oscillations. The emergent property is seen as deleterious, and more complications are added to maintain a stable supply. The net effect is that the design becomes more complicated, even though no new requirements have been added. Eventually we have a design that meets our requirements, as we demonstrate through our testing. In reality, we have tested a safe operating area wherein we have a system we believe to be stable under the defined conditions of the safe operating area (our test cases). Since the early days of cybernetics, control and stability have been at the forefront of the systems we engineer. We also learn that emergent properties will still lurk undetected, and we usually discover these new ones through failure analysis after something has gone wrong, again with an assumption for the most part that uncontrolled and unpredicted emergence is seen as negative. The challenge here is that complexity has been a consideration for engineering since its beginnings We have done some amazingly complicated things to remove the effects of complexity from our designs, because we have seen complexity as problematic. So what is the change we are exploring? I would suggest that what is changing is that we are now exploring the possibilities of no longer looking at complexity as something to be removed or designed out, but rather as something > continues on next page INCOSE INSIGHT

January 2008

17

Special Feature

Complex and Complicated SE continued

to be embraced and incorporated within our designs. New demands for our systems to be adaptable, evolvable, and scalable, combined with the recognition that we live in a rapidly changing world, have turned the assumptions of control and stability that formed the basis of traditional systems engineering into something of a myth. No longer is stability the pinnacle of design, but rather it is one of the factors within the trade space. We cannot live with systems that are so stable that they are obsolete by the time they are delivered. One solution that is being considered is the extended use of computer simulation to enhance the design process, making this process more effective and therefore more able to keep up with the time constraints we now feel on our design efforts, as well as to discover the positive benefits of emergent properties. There is room for both optimism and caution here. In his 1994 book, Out of Control, Kevin Kelly explores the use of a famous simulation, “The Limits of Growth,” and showed the areas that were lacking. He found several weaknesses: • Narrow overall scenarios (minor variations upon on fairly narrow set of assumptions), • Wrong assumptions (some very questionable initial premises), • No room for learning (some adaptation through feedback, but neither open-ended nor decentralized learning), • World averages (poor uniformity in input conditions actually under complicating the model), and • The inability to model open-ended growth of any kind. As Kelly (1994, 446) states, “The scenarios in Limits to Growth collapse because that’s what the Limits of Growth simulation is good at…  The Limits of Growth cannot mimic the emergence of the industrial evolution from the agrarian age.” The point for us to consider is that a model is no better than what you create it to do and what you look for it to produce. We will not recognize the beneficial ways that simulation can guide us in demonstrating positive emergence and complexity until we know how to allow 18

Volume 11 No. 1

INCOSE INSIGHT

for such properties in the simulation and look for them in the results. Familiarity with complexity theory and the types of complex systems being studied, such as biological or economical systems, will aid us in seeing the possibilities for the systems we engineer. There is a popular point of view that the essence of complex systems lies in the emergence of complex structures from the nonlinear interaction of many simple elements that obey simple laws. Many of us had our first introduction to complexity through such simulations, such as John Conway’s “Game of Life ,” 1 and have marveled at the intricate patterns and structures that can occur within such systems. While such simple simulations are educational, we also need to explore the possibilities that the real systems we work with consist of elements that individually are quite complex themselves. So we often flip to another point of view that what makes our systems complex is that now human agents, complex in themselves, create the complexity within our system. When we put the humans into the loop, their unpredictability as complex agents creates the complexity of the system. Atay and Jost (2003) explore a new aspect that seems essential to the emergence and functioning of complex systems, namely, the coordination of individual agents or elements that are complex at their own scale of operation. The authors suggest that this coordination reduces the degrees of freedom of those participating agents. They give the example of an economic system consisting of the interaction of humans — obviously highly complex agents themselves. Standard economic theory is rather successful even though it assumes that agents follow simple rules of utility functions and optimization patterns. Just any group of people will not automatically build a smoothly functioning economic system. The functioning economic system has some subtle means to suppress the individual and disruptive behavior of its members and coerce them to operation in a manner that is predictable for others, thus supporting the higher goals 1. http://www.bitstorm.org/gameoflife/.

and structure of the economic system. By taking on these limitations, the individuals allow the economic system to emerge. The potential complexity of the individual agents becomes simplified through the global interactions within the system. The system becomes able to develop and express a more coherent structure at a higher level than the individual is capable of when the individuals express limiting behavior. The economy can be seen as a complex adaptive system, but the human elements are not treated in this representation as complex adaptive systems themselves. (However, because humans are complex, fruitful research could be done to explore the influence of the unique individuals as an added stimulus to the evolution of a higher-level complex system such as the economy.) The caution here is that we have so much more to continue to explore and learn about what makes our systems complicated and what makes them complex. Simplification (encapsulation) of behaviors at one level can produce emergence at a higher level. Complication and complexity do not necessarily go hand in hand, nor do they necessarily diverge. We need to do more research to understand their interactions. We need to understand where we want to encourage emergent behavior and where we still need to maintain structure. Kelly (1994, 448) puts it this way: The key insight uncovered by the study of complex systems in recent years is this: the only way for a system to evolve into something new is to have a flexible structure. A tiny tadpole can change into a frog, but a 747 Jumbo Jet can’t add six inches to its length without crippling itself. This is why distributed being is so important to learning and evolving systems. A de c ent r a l i z e d , re du nd a nt organization can f lex without distorting its function, and thus it can adapt. It can manage change. We call that growth. Two examples of systems that have grown through the means Kelly addresses here are the Internet and the Linux operating system. What were

Special Feature

the original intentions (design goals) that led to the Internet and Linux, and would we be better off if they had only met those original intentions rather than what they have each grown to become?  We cannot say that the driving force for either has been traditional systems engineering, but we can see their success in evolving into very complicated structures. There is a core of structure (e.g., TCP/ IP) upon which each is built, but that framework became the catalyst for growth rather than a limiting factor. In the latter case, an excellent resource for exploring the challenges ahead for INCOSE and systems engineering is The Cathedral and the Bazaar, by Eric S. Raymond (1999). While we have built some beautiful “cathedrals” with traditional systems engineering, Raymond suggests an alternative with the model of the bazaar, and the continued success and adaptation of Linux since this book was written shows how relevant it still is. Many have claimed that gardens represent the epitome of human design. A well-structured garden provides a place of solace and structure that isolates a person, providing a “safe operating area” from the wilds just outside the garden wall. Gardens can be quite complicated in design, and their perfection is often contrasted with the chaos of the world just beyond them. But what is the intention of a design like a garden?  A garden provides formal structure often at the expense of sustainability and maintainability.  It is becoming more important that we consider the latter.  Now we are seeing that often gardens require maintenance, protection, and can be quite fragile to changing environmental conditions. Growth is often seen as something to be pruned out, because it interferes with the formal design intent. On the other hand, the wilds just outside the wall need to be reexamined and understood as complex eco-structures that have evolved to

a high degree and are much more adaptable and sustainable than a garden. They may not have the structure we have been trained to appreciate in the formal gardens we designed, but now we are seeing them as a little less wild and untamed than we had in the past. We may not see them as intentional designs that we engineer. The wilds have their own perfection in their complex structure, and there may be lessons to be learned by exploring them and other biological systems. As we learn more about complex systems from complexity theory, we can begin to explore how to co-evolve systems to meet our purposes, rather than destroying natural systems and replacing them with our designs. And as any gardener (or farmer) knows, we need to learn to appreciate and live within the “life cycles” that are provided to us and learn that we cannot just plan any life cycle and force it on the engineering of a system. In fact, we are discovering in our work with systems of systems that there may be more than one life cycle and that the various life cycles may not be in sync. We need to learn to look for the best on both sides of the garden wall so that we may find the examples, both complicated and complex, for our future engineering efforts. References Adler, J. 2007. The war of the words. Newsweek. 16 April. Atay, R., and J. Jost. 2003. On the emergence of complex systems on the basis of the coordination of complex behaviors of their elements. http://www.santafe. edu/research/publications/workingpapers/04-02-005.pdf.

Kelly, K. 1994. Out of control: The new biology of machines, social systems and the economic world. New York: Basic Books. Raymond, E. S. 1999. The Cathedral and the bazaar: Musings on linux and open source by an accidental revolutionary. Cambridge, MA: O’Reilly Media, Inc.

University of Missouri – Rolla is seeking faculty candidates with expertise in Systems Engineering to fill a non-tenure-track teaching faculty position in the depar tment of Engineer ing Management and Systems Engineering. UMR’s Systems Engineering Graduate program is ranked in the top ten percent among similar programs in the world. This 21st century Systems Engineering Graduate program builds on sound engineering undergraduate education and experience, and maintains engineering specialization diversity in its graduates at both the MS and PhD level. The diversity of specializations is attained through the teaching and research contributions of core and contributing faculty from a number of campus graduate programs including Computer Engineering, Computer Science, Aerospace Engineering, Engineering Management, and Systems Engineering and through a matrix organization administered by a program director. Successful candidates must have a BS in engineering or science and a PhD in Systems Engineering, Industrial Engineering or a related field. Industrial experience is desired but not required. The applicant must have the ability to teach graduate courses in Systems Engineering topics as his primary responsibility. It is also expected that the candidate to contribute through advising graduate students. The appointment is anticipated to be at the non-tenure-track teaching assistant professor level. However, qualified candidates at all levels will be considered. Specific information about the position and the search process may be obtained by contacting the chair of the search committee, Dr. Cihan Dagli, at 573-341-4374 or 573-647-9125. Information about the campus and department can be found at http://syseng.umr.edu. Please submit an application by November 2, 2007 consisting of current curriculum vitae, teaching evaluations (if available), and complete information for three references to: Human Resource Services ([email protected]) Reference Number: R36501 University of Missouri – Rolla 113 University Center East 1870 Miner Circle Rolla, MO USA 65409 UMR is an AA/EEO employer. Females, minorities, and persons with disabilities are encouraged to apply. Effective Jan. 1, 2008, UMR will become Missouri University of Science and Technology (Missouri S&T).

INCOSE INSIGHT

January 2008

19

Special Feature

Systems Engineering and Complexity Eric Honour, [email protected]

T

he discipline of systems engineering has been recognized for over fifty years, with the first known textbook published in 1957, Harry H. Goode and Robert Engel Machol’s System Engineering: An Introduction to the Design of Large-Scale Systems (New York: McGraw-Hill). Despite this, systems engineers are still struggling today to understand what their discipline is. Other engineering fields do not seem to have this same confusion. The term software engineering was first used in the 1970s, at least thirty years after the term systems engineering, and yet the field of software engineering is well defined and generally agreed upon today. One reason for this is that other engineering fields have an underlying foundation of theory that informs the practice of the field. Systems engineers, on the other hand, usually rely on pragmatic methods that have simply developed over time from what have seemed to be “good practices.” We desperately need the underlying theory that can inform us as to what we do and why we do it. Due to recent research and work, complexity theory is emerging as a possible foundation for systems engineering.

Complexity Theory Complexity theory is somewhat newer than systems engineering, having arisen out of interesting and puzzling observations about the behavior of seeminglysimple structures. Studies of cellular automata in the 1960s and 70s showed that surprisingly unpredictable results can often occur through the use of simple rules of interaction. The more theoreticians studied the field, the more they found behavior that simply could not be explained with traditional theories. The field of complexity theory has for the most part focused on descriptive research centered on economics, mathematics, and physical phenomena. Much of this work has been done at the Santa Fe Institute, which has invited key figures from many disciplines to work together to discover common effects in their disparate fields. 20

Volume 11 No. 1

INCOSE INSIGHT

“Complexity” falls between the extremes of chaos and determinism. At one extreme, chaos theory (which is not complexity) deals with situations in which the behavior of the elements is completely random and unpredictable, as in the Heisenberg Uncertainty Principle. In such cases, however, the mathematics of probability and statistics can apply to make useful predictions of the aggregate behavior. At the other extreme (also not complexity), many systems seem to be composed of elements with predictable behavior. The engine of an automobile, for instance, continues to provide rotary power so long as it is intact and supplied with fuel, air, and exhaust. Behavior of the automobile as a whole is predictable based on the predictability of its elements. The field of complexity has often been characterized as operating at the “edge of chaos” between these two extremes. Complexity occurs in systems that have sufficient chaos to be puzzling, and yet sufficient order to provide recognizable patterns. This is an interesting and useful place for systems to lie, because complexity causes a delicate balance between order and chaos that creates the desirable traits of spontaneity, adaptation, and “life.” Agents. Complexity often happens because the structure is made of many independent “agents.” Each agent operates separately, and it is through the combination of the individually-motivated interactions of the various agents that emergent properties appear. In the stock market, each investor and each public corporation is such an agent. The investors buy and sell shares; the corporations provide or retain information about their operations; and each agent, investor, or corporation is trying to achieve a better profit from his participation in the market. The result is a constantly changing, dynamic, and growing market. Reflexivity. The essence of reflexive interactions is that the actions of each agent cause other agents to respond in ways that affect the original agent. Each agent acts, and that agent’s actions have impacts on the other agents around him.

Other agents act in response, thereby changing the environment for the original agent. In this complex structure there are many feedback paths that cause reflexive interactions to abound. The classic Cold-War dark comedy Doctor Strangelove exemplified such a reflexive complex system. Each major character in the movie escalated his actions, based on his own perceptions, until Slim Pickens was left riding the atom bomb down to a world-destroying explosion. Local Information. In such a structure of agents and reflexive interactions, it is typical that each agent operates only on local information, and there are no agents that have access to global information. In the case of the Internet, for instance, each computer communicates with only a few other computers at any given time. The responses and operation of each computer are therefore governed only by the environment evidenced by those few. Emergent Properties. Emergent properties are those behaviors that are perceptible only at the system level. An automobile is made up of wheels, chassis, engine, interior, controls, and other parts, yet none of these parts single-handedly provides the capability to transport people from one place to another — an emergent property of the entire automobile. Emergent properties may be useful and designed, as in this property of the automobile, or they may be destructive or surprising behaviors. Complex Adaptive Systems. At the highest level, complexity often leads to adaptation, in which the complex structure changes itself to better fit its environment. Adaptation happens when the structure has self-modifying abilities, local information, and some self-attaining measure of fitness. The complex structure responds to environmental inputs that act either as threats or opportunities against the measure of fitness. An obvious example of this is Darwin’s theory of evolution in The Origin of Species (1859). Other examples also abound, however, including seemingly-simple structures, such as agent-based models, and very large

Special Feature

structures, such as military information networks. Complex adaptive systems are the result of the bottom-up interactions of the agents in the system, as opposed to the top-down design methods of classical systems engineering. Systems Engineering is the Engineering of Complexity The development of systems engineering as a discipline is closely aligned with the creation of the most complex systems of each decade: • 1940s – The unknown but anecdotal start of systems engineering was in the development of communications systems during World War II, particularly at Bell Labs, related to the development of both cryptology and the digital computer. • 1950s – Systems engineering continued developing military systems for the cold war, particularly nuclear submarines and missile programs. • 1960s – The space programs and military programs fostered a heavy

use of systems engineering, leading to the development of the first standard, MIL-STD-499. • 1970s – Systems engineering fell into decline in this decade in most areas, as managers came to believe that it was no more than just common sense. In a few areas of extreme complexity, however, such as the U.S. Navy’s AEGIS program, its use continued to increase. • 1980s – Some highly-public failures caused a resurgence of systems engineering in military systems. Rigorous requirements management began to be augmented by the use of general-purpose computers. • 1990s – Software development, which made tremendous advances in the 1980s, came to realize that its next frontier comprised the limits placed on it by the lack of higher-order systems engineering. As a result, systems engineering was applied to many domains of complex software development. In addition,

the discipline of software engineering encouraged the documentation and formalization of systems engineering in community standards and maturity models. I have come to believe that the activities of systems engineering have developed over time specifically to work with the complexity characteristics of each decade. The table shows how systems engineering activities help to solve complexity issues. As systems have grown, decade by decade, the leading edge of complexity has changed. As the characteristics of complexity have changed, the teams of engineers working on the most complex system developments have spontaneously created methods and means to manage those characteristics. It is the collection of those methods and means that we now call systems engineering. Systems engineering is the engineering of complexity, and it always has been!

How Systems Engineering Activities Address Complexity

Agents

Reflexivity

Localcy

Emergence

Adaptation

Define emergent properties

Define desirable adaptations

Maintain a broader set of information

Specify desirable and undesirable properties

Limit uncontrollable selfadaptation

Define the meaning of “local”

Design emergence

Design for or against adaptation

Mission/ Purpose Definition Requirements Engineering

System Architecting

Define the agents and their interactions

Explore possible reflexive interactions

System Implementation

Create effective agents

Discover reflexive interactions

Discover surprise emergence

Discover adaptations

Predict interactions and their impacts

Predict emergence

Predict adaptation

Guide emergence development

Adapt to changing development environment

Technical Analysis

Technical Management/ Leadership

Monitor/ control agent development

Scope Management

Control agent development

Verification/ Validation

Prove agents

Monitor/ control information localcy

Control the changing development environment Prove reflexivity

Prove emergence

INCOSE INSIGHT

January 2008

21

Special Feature

Boundaries and Complex Adaptive Systems | Bill Schoening, [email protected]

B

oundaries create categories that help us interpret the world around us. For example, societies have rules and descriptions for acceptable and unacceptable behavior, which form the boundaries for how to act in each society. Even though boundaries of this kind describe behavior, people use physical terms to describe most boundaries, probably because physical differences are more easily envisioned than behavioral differences. Race, religion, and ethnic origin are representations of boundaries that are mostly about behavior. The boundary around a state or country is not just an imaginary line on a map; it also differentiates the laws and social customs within the boundary from those outside the boundary. The correspondence between physical and behavioral boundaries, however, is not one-to-one, and that causes problems. In engineering, we are taught to define the boundary around a system early in development so we can separate the behavior of the system from the behavior of the outside world, and then identify the information that must pass across that boundary. While this technique is very useful, the system boundaries that result are fairly static. Once the system is fielded, behavior inside the boundary does not change from the design unless the system is altered with a new design. Even during development, the boundary is likely to change very little. As a result, it may be difficult to adequately alter the behavior, much less the boundary, to accommodate previously unknown external conditions. In fact, we often go to great lengths to prevent the system from lapsing into behavior that is not part of the intended behavior. Unfortunately, the boundaries we set on a system’s behavior are based more on our belief that the system will never encounter conditions outside of those boundaries than on the system’s inherent inability to respond to those conditions. I define a “complex system” as a collection of systems that (1) interact, (2) are interdependent, and (3) have developers and operators who can make 22

Volume 11 No. 1

INCOSE INSIGHT

unilateral decisions about the behavior of their own systems. The third condition is what separates complex systems from noncomplex (but sometimes very complicated) systems. This third condition makes it possible for complex systems to adapt to previously unknown contexts, which is why this type of system is called a “complex adaptive system” or CAS. Adaptation frequently results in modifications of the boundaries around and within the complex adaptive system. Consider a CAS working to accomplish a particular goal, and suppose it is confronted with a new situation. The collection of systems within the CAS might reorganize by no longer using some of the systems, adding systems not previously included, redeploying the behaviors (changing the roles) of the systems, or — more likely — some combination of these approaches. We see this all the time in complex adaptive systems made up of humans (e.g., the work force in your company), and it is typical of a military organization shifting from one mission to another. The ability to shift boundaries on the fly rather than by design is a common characteristic of successful complex adaptive systems. What is inside the boundary today may be outside that boundary tomorrow, and we might never have envisioned the new conditions. This ability to shift boundaries without having a prearranged design or architecture is what allows complex systems to adapt. If the adaptation is successful, the new complex system survives. If it fails, the new complex system dies unless artificially sustained. In addition, the physical boundaries for this type of system often change more frequently than boundaries described in behavioral terms because the same behavior can be reassigned to other physical entities. The ambiguous and uncertain nature of boundaries in complex adaptive systems creates a problem for those most comfortable with the static nature of boundaries commonly employed for development of individual systems. The most common response is to force the static boundary concept onto a complex system even

though the resulting constraints might inhibit the ability of the system to adapt successfully. This is not simply an academic issue, because all of our systems reside in some larger complex system, most of which are adaptive at some level above where our systems reside. Our challenge is to figure out how to develop systems that will be successful members of larger complex adaptive systems and help the complex system adapt successfully. Top-down decomposition with relatively static boundaries can succeed if there are just a few well-defined alternatives and the uncertainties are no more complicated than simply knowing which alternative is in play at a particular time, but it does not appear to be an effective approach for dealing with the uncertainties and ambiguities inherent in complex adaptive systems. Usually, we do not know how a CAS will reorganize itself for as-yet unknown operational contexts and objectives. A CAS must find its own adaptation and rapidly. Some systems may be brought inside the boundary to aid adaptation while others may be sent outside the boundary if they have inadequate value for meeting the objectives of the CAS. Moreover, the roles (actually, the associated behavior) of some systems may be reallocated among the systems within the complex adaptive system. Boundaries for complex adaptive systems do have uses, but they are transient, so we must find better ways to capture and employ our understanding of that transience. One commonly used perspective is to define boundaries in terms of the communication links: systems linked to a common net are within that boundary and those not linked are outside the boundary. However, interfaces and information exchange across the changing boundaries of a CAS raise interesting problems. Since we have less than absolute control over each system, some may use sources of information that are jointly inconsistent. While this may seem like a sensor fusion problem, the difficulty is that we may know little about the provenance of the information. While we think we know and understand the interfaces across the boundary in a particular situation, that knowledge may be transient. Before getting overly > continues opposite

Special Feature

Emergence in Systems Engineering Alex Ryan, [email protected]

R

ecently the Systems Science Enabler Group has spent a lot of time discussing fundamental concepts in systems science. The INCOSE Systems Engineering Handbook (Haskins 2006)recognises that the “systems engineering perspective is based on systems thinking,” and that “systems engineers uncover the real requirements and the emergent properties of the system” as they implement the systems engineering process. This implies that improvements in systems engineering methodology need to have a foundation in systems thinking — as opposed to reductionist analytic thinking. Secondly, if systems engineers are in the business of uncovering emergent properties, we ought to be able to say exactly what they are. In this essay I will address these two issues by discussing the importance of emergence in systems thinking, and giving a simple but precise definition of an emergent property. In the West, Bertalanffy’s seminal paper on open systems, published in 1950, is usually attributed as seeding the rise of the systems movement. In this paper, Von Bertalanffy argued that flows across the border of an open system meant that its behaviour could not be reduced to physical laws of closed systems, but that open systems must always be understood in the context of their

environment. Thus, even though the second law of thermodynamics underwrites the inevitable decrease in order in any closed system, open systems can and often do show sustained increases in order. In 1954, Bertalanffy helped establish the Society for General System Theory (now the International Society for the Systems Sciences), whose yearbook became a hub for systems thinking. The history of systems engineering predates the systems movement, and is actually quite distinct from the history of systems thinking. INCOSE’s Systems Engineering Handbook identifies precursors of modern systems engineering dating back to the development of the rocket locomotive in 1829. However, the Bell Telephone Laboratories and Western Electric Company’s design and manufacture of the Nike air defence system, commenced in 1945, is widely cited as one of the first systems engineering projects in the modern sense. Following the success of individual systems engin eering projects such as Nike, Bell Labs structured itself around the new systems engineering approach. Bell Labs was organised into three areas: basic research, systems engineering, and manufacturing projects (Kelly 1950). The systems engineering area provided the interface between advances in communications theories and

Complex Adaptive Systems continued

While diversity within the complex adaptive system might appear to make development more difficult, that diversity is likely to result in a greatly enhanced ability to solve problems. Stated another way, stamping out diversity and fixing the boundaries may make it seem easier to engineer aspects of a complex adaptive system, but the long-term consequences are probably very adverse. While carefully defining boundaries early on has been very useful for developing traditional systems, doing so for complex adaptive systems appears to be much less useful. Nonetheless, they should not be ignored; it might be that we simply do not yet understand how to employ them effectively for complex adaptive systems.

excited and attempting to stamp out all but the formally acknowledged sources, we should ask which of the sources is best for use by the complex adaptive system. That is not an easy question to answer. In fact, it may be unanswerable except in a few isolated situations. One approach for overcoming the inherent uncertainties and ambiguities in complex adaptive systems is to stamp out variation across the system to limit the issues associated with transient boundaries. However, as Scott Page points out in The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies (Princeton: Princeton University Press, 2007), diversity among problem solvers always trumps ability.

the manufacture of commercial systems. Because of the “whole system” perspective within the systems engineering area, it was responsible for prioritising the activation of projects with the greatest potential user benefit, within the technical feasibility of communications theory. It is only relatively recently that the link between systems thinking and systems engineering has received attention. Perhaps this is due to systems engineers searching for new techniques to cope with the increasing complexity associated with engineering systems of systems and enterprises. At the same time, the popularity and success of the systems approach known as complex systems has led to a growing realisation that complex systems theory can help with systems engineering practice. But what does it mean for systems engineering to be based on systems thinking? According to Checkland (1981), systems thinking is founded on two pairs of ideas: • emergence and hierarchy, arising from organismic biology; and • communication and control, originating in communication engineering. The latter pair ought to be intimately familiar to this audience, but concepts from organismic biology may be a little more foreign. Hierarchy is straightforward enough — we all work inside them, and Simon provided a succinct definition in 1962: “a system that is composed of interrelated sub-systems, each of the latter being, in turn, hierarchic in structure until we reach some lowest level of elementary subsystem.” That leaves us with the concept of emergence, which is the most important but also the most difficult concept to define. It is the most important because emergence is the most common reason a reductionist approach fails for engineering systems. If the whole is only the sum or difference of its parts, then we don’t need to think of the whole as a system: calling it a system just provides a “container” for the parts, which can be analysed in isolation to understand the whole. On the other hand, when a system has properties that its parts don’t > continues on next page INCOSE INSIGHT

January 2008

23

Special Feature

Emergence in SE continued

have — emergent properties — then a new approach is needed. Emergence is the barrier to the application of reductionist techniques that motivates the systems approach. Emergence has a common English usage, such as “the sun emerged from behind the clouds”. However, a scientific usage of emergence needs to be much more precise. I do not have sufficient space here to develop the rigorous conceptual framework this demands, but I have done that previously (Ryan 2007). Here I merely wish to give a flavour of the scientific definition of emergence, in order to provide an operational usage within systems engineering. Firstly, we need to say what an emergent property is. Quite simply, an emergent property is a difference between local and global structure. A simple example from topology is the Möbius strip, depicted in figure 1. Locally, the Möbius strip has two sides, a front and a back. Yet globally, the Möbius strip is one sided. Because of the twist, an ant walking along the surface would traverse the ‘back’ and ‘front’ as a single surface before it returned to its starting point. The difference in local and global structure means that if an observer only looks locally, she will not see the emergent properties of a system. Therefore, an observer must have a sufficient scope of observation before she can recognise an emergent property.

Figure 1. A Möbius strip has emergent properties such as one-sidedness.

We do not need to look very far to find emergent properties in engineering. The problem of building a reliable system from unreliable parts (Neumann 1956) is an example of a clear difference between local and global structure. More generally, almost all of the functions we engineer systems to perform — as well as their unintended consequences — are emergent properties. This is because they emerge from the structure of interactions 24

Volume 11 No. 1

INCOSE INSIGHT

NEW

between their components, rather than as the simple aggregation of the functions of the parts. If the latter were the case, we could arrange the components in any order and the system would still function as intended. In the scientific sense, emergence is a process that generates emergent properties. Biological evolution and engineering are two of the most important processes that produce systems with emergent properties. This explains why the systems approach derives from the two pairs of ideas from biology and engineering. However, it also demonstrates the relevance of systems thinking to systems engineering, and why a better understanding of emergent properties can help improve systems engineering practice. In conclusion, emergence is not mysterious and can be precisely defined. It is important to carefully communicate what we mean by emergence and emergent properties, because these concepts play a central role in systems thinking. These are the kinds of insights that the

Systems Science Enabler Group hopes to contribute to systems thinking through its research, with the aim of helping to build the foundation for future advances in systems engineering. References Bertalanffy, L. von. 1950. The theory of open systems in physics and biology. Science 111 (2872): 23–29. Checkland, P. 1981. Systems thinking, systems practice. Chichester, U.K.: Wiley. Haskins, C., ed. 2006. Systems engineering handbook: A guide for system life cycle processes and activities. Version 3. Seattle: INCOSE. Kelly, M. J. 1950. The Bell Telephone Laboratories: An example of an institute of creative technology. Proceedings of the Royal Society of London, Series A 203 (1074): 287–301. Neumann, J. von. Probabilistic logics and the synthesis of reliable organisms from unreliable components. In Automata Studies, ed. C. E. Shannon, and J. McCarthy. Princeton, NJ: Princeton University Press, 1956. Ryan, A. J. 2007. Emergence is coupled to scope, not level. Forthcoming in Complexity. Simon, H. A. 1962. The architecture of complexity. Proceedings of the American Philosophical Society 106 (6): 467-482.

Special Feature

Asks the Chief Engineer, “So What Should I Go Do?” Doug Norman, [email protected], and Brian White, [email protected]

I

NCOSE’s Systems Science Enabler Group (SSEG)1 has taken on quite a challenge. We are actively exploring, presenting, and debating ideas and methods beyond the boundaries where systems engineering is currently defined, and, more importantly, practiced. Most notably, the ideas that seem to offer the most value are being taken from “complexity science,” and are expressed in ways that seem like a foreign language to many systems engineers. Furthermore, many are uncomfortable with adopting a broader perspective of systems engineering and using and formalizing complementary techniques that may help greatly in practicing systems engineering. Therein lies the challenge, because systems engineers require ideas, concepts, mechanisms, and processes, in a language that is relevant to our need to produce useful results at multifarious scales.2 With any new idea that exposes and articulates potentially new values, there is usually a gap between expression of the essence of the idea, and transformation of the idea into common understandings, expectations, and processes by which the idea impacts the real world. Systems engineers are being asked to apply their engineering acumen in larger and more complex 3 contexts. As these contexts

1. The group’s Web site is at http://www.incose. org/practice/techactivities/wg/sseg/. 2. Brian White has proposed using the word view instead of scale, where each “view” is defined as a combination of “scope, granularity, mindset, and timeframe.” B. E. White, “On Interpreting Scale (or View) and Emergence in Complex Systems Engineering” (paper presented at the first annual IEEE Systems Conference, Honolulu, HI, 9–12 April 2007). 3. We do not mean merely complicated. Complexity here is better defined as a technical term qualitatively describing an entity that (1) continuously evolves dynamically by organizing its own internal relationships; (2) requires multiview analysis to perceive different non-repeating patterns of its behavior; and (3) defies methods of pre-specification, prediction, and control. See for example, S. A. Sheard, “Principles of Complex Systems for Systems Engineering,” in Proceedings of the Fifteenth Annual Symposium of the International Council on Systems Engineering (Seattle: INCOSE, 2005).

expand, the assumptions that underlie the application of our systems engineering practice are violated more and more. Thus ideas, methods, and tools that were previously unquestioned have come up against some limits, and the failures of many complex systems can be traced to the shortcomings of traditional, conventional, or “reducible” 4 systems engineering. Some new ideas have been proffered for tackling systems engineering challenges at these greater contexts. There are rather clear boundaries (as described by Norman and Kuras 5 and others) beyond which the currently accepted systems engineering practices6 can be unhelpful and even counterproductive. So, what is the language of complex adaptive systems as applied to systems engineering? From ecology we take the conceptual elements of “interaction webs,” “rhizomes,” 7 “niches,” and competition. We also recognize energy flow across and between all the interacting elements, and thereby come to appreciate the interconnectedness of things, and the dynamic nature of stability and change. As we add the concept of evolution, we 4. M. L. Kuras, “An Introduction to ComplexSystem Engineering” (paper presented at the Seventh International Conference on Complex Systems, New England Complex Systems Institute, Boston, MA, 28 October –2 November 2007). 5. D. O. Norman and M. L. Kuras, “Engineering Complex Systems,” in Complex Engineered Systems: Science Meets Technology, ed. D. Braha, A. Minai, and Y. Bar-Yam (Berlin: Springer, 2006). 6. For a description of these methods, see, for example, the Systems Engineering Handbook, version 3.1, available from INCOSE at http://www. incose.org/ProductsPubs/products/sehandbook. aspx.

7. “Rhizome acts as a web-like structure of connected but independent nodes, borrowing its name from the structures of plants such as bamboo and other grasses... In human terms, such a node represents an economic and a cultural unit at the size preferred by our genome: the household and the tribe. Functionally self-sufficient but not isolated, cooperating but not controlled, the rhizome economy, combined with a self-awareness of control structures, provides the real-world foundation of stability and freedom.” Jeff Vail, A Theory of Power (New York: iUniverse, 2004), 41. Available online at http://www.jeffvail.net/atheoryofpower.pdf.

must begin to consider the notions of change and adaptation in populations.8 Complexity science gives us a language and some additional tools to both qualify and quantify the interactions among the elements that we now acknowledge to be parts of our system.9 On the technical side, we must ensure that our elements are composable (capable of being integrated adaptively) with other elements occupying the flow, and that the elements can thus be composed into assemblies that will satisfy emergent needs and accommodate themselves to new operational understandings that may arise. Not surprisingly, this usually doesn’t communicate very well with the program’s chief engineer, who often asks the key question, “So what should I go do?” What We Do Today Let’s recognize that acquisition programs, and the systems they produce, tend to be insular (i.e., “stovepiped”). Why is this necessarily so? We would argue that the insular nature of acquisition programs comes from two fundamental conditions, each of which supports the interlocking character of the other. First, it comes from the way good10 engineers have been taught to think about problems, ways of thinking that the best engineers internalize. Secondly, insularity is encouraged by the incentive structures that penalize rather than reward behaviors embracing interoperability and “horizontal” (as opposed to “vertical”) integration. The best systems engineers approach a new problem by asking a series of ordered questions, and we acknowledge that this approach is useful for a certain class of problems. But the nature of this questioning process can lead to an insular attitude that does not prepare these engineers to ask the best questions when dealing with problems outside that class — especially in the case of large enterprises. 8. Kuras, “Complex-System Engineering.” 9. Those who do systems engineering have always known these aspects were present, but the rules for performing the job encouraged practitioners to view these as external anomalies somehow to be conquered and controlled outside of the systems engineering practice. 10. We’re not referring to a small minority of poor performers. > continues on next page INCOSE INSIGHT

January 2008

25

Special Feature

So What Should I Go Do? continued

For example, a systems engineer will normally begin solving a problem by asking two first-order questions. First, “What are the boundaries for this system?” Clearly, one wants to expend one’s usually limited resources solving the problem at hand, not wandering elsewhere and squandering time, money, equipment, and people on inconsequential issues. Second, “What is the most challenging limiting case for this system’s use?” By understanding and making explicit the stressing cases for the system, we inform all design aspects that follow to ensure that the system will perform well in those cases. The logic as to how the questioning process leads to insularity is as follows: We know what we want to build; that is, we know the requirements to the level of detail required to answer the two first-order questions. We know what external things our system will touch, and we know what external things touch it. We know the environmental challenges that are likely to stress the system. And knowing all this, we have designed strategies and structures, and employed architectures and technologies, to mitigate these issues. In doing so, we have introduced many specializations at many of the points of articulation between the various elements. Doing this, elements that must cooperate and interact are tailored for this interaction to prepare for the limiting, most stressing case. It may be that we succeed in providing the needed functionality in a system that will work properly in such an environment. The specialization of the interfaces between the interacting pieces is not an issue because, as an independent, standapart system, we are free to do what is needed to meet the known requirements, external constraints, and environmental challenges. These latter factors are represented in the predicates we developed to define, understand, and compensate for (in our interfaces and interaction mechanisms) the stress. Thus, any external problem doesn’t really exist, Q.E.D. What we have outlined represents the goals of good systems engineering as we understand and expect it to be performed — and one could argue that it is necessary to get on with the job. Yet 26

Volume 11 No. 1

INCOSE INSIGHT

these single-system answers, when considered in isolation, i.e., in the context of the system under consideration as a stand-alone entity, tend to act against the needs of the enterprise. And that is precisely what is done today. Why? Because of the prevailing incentive and execution structures. For example, despite “encouragement” from high-level leaders to enable horizontal integration and interoperability, most program managers feel constrained to work within their official program management directives, concentrating on achieving objectives for which their personal performance is being measured. If these directives are “stovepiped” in nature, and a program manager must choose between two options, both of which satisfy her directives, perhaps the most one can hope for is that she will be informed enough to choose the one that serves the common good. Not only is there little tangible reward for being mindful of the enterprises in which the system is embedded, there is almost punishment for those who pay too much attention to the enterprise. How so? Consider what is not rewarded. Relying on an external entity causes a schedule risk that cannot be mitigated internally. One is also in danger if external access to the system’s functionality is offered to “outsiders.” If one’s offer to external parties is accepted, then one is on the critical path for another, so how does one respond to technical difficulties that impact the promised functionality? Also, whose need is being satisfied when local development is done for an unknown, unidentified, external third party? Who “pays the freight” for that one? Who potentially benefits? Isn’t this a case of either “gold-plating,” or fraud, waste, and abuse? And what happens when some of the presumptions are changed? Imagine that you have produced a highly-valued and desired element of functionality that is widely successful and comes to be used by a large number of external parties: this sounds like a true success story, yet what do you do when the usual request for changes arrive? Who pays? How does this impact schedules? Where are the new background requirements articulat-

ed such that there are justified, approved, and valid needs? What We Might Do Differently We can increase the utility of elements of systems by augmenting our thinking, analysis, and synthesis so that today’s systems provide opportunities for assembling and creating tomorrow’s systems  which generally will have a different quality from today’s systems. While tomorrow’s systems may be systems in name, they won’t have the permanence that today’s systems do: they will be systems only for the duration of use. This is called “late binding.” At other times, these same elements will be members of other collections, which can be assembled in many different ways for many different purposes. How will this come about? We must learn how to build with the equivalent of LEGO® bricks. These toys are useful for building things because they are so easy to fit together. Each piece can be affixed easily and in a variety of ways to what has already been built. The problem with composing with pre-fabricated blocks is that you can’t achieve perfect fidelity to the structure you are trying to create. But building with LEGO® bricks doesn’t have to end with these approximations. A LEGO® set provides many speciallyshaped pieces and mechanical parts, with which anyone can improve the functionality and beauty of the composite, e.g., by smoothing a discontinuous edge. In this way the approximation can have a greater fidelity to the desired end. Most military users want to acquire new mission capabilities that can “plug and play” into their existing system without changing the existing interfaces. In effect, they want to be part of an open architecture that enhances interoperability. From a chief engineer’s point of view, a few heuristics can turn the above concepts into operational practice to avoid insularity: 1. Focus on the fundamental unique value your system offers to the enterprise. This core value is the essential capability motivating why your system was to be built in the first place. In effect, you are offering your principal specialty piece for use by others to discover new value-chains.

Special Feature

2. Develop and use “casual” 11 technical composition mechanisms first. A concept seemingly missing from our technical considerations is one that recognizes explicitly a continuum of technical relationships from the casual to the intimate. A casual technical relationship should require a minimum set of unique interface protocols and no understanding of local context. This requires only a low investment, yet allows us to test our ideas about the value of a particular collection and set of interactions. 3. Know how you will offer access to your elements of fundamental unique value and what interaction models will be proffered. This will suggest how to structure initial offerings. For example, some products are consumed by many already-existing systems. It seems reasonable to expect that it also would have utility to others. By this reasoning, it was made available as an XML-structured data payload accessed through a simple query/ response mechanism. 4. Provide a mechanism for reducing the integration barrier, such as a “developers’ network,” “points-ofpresence” with offered functionality exposed as live services.12 Integration is an existing open-ended problem for achieving the agility demanded by the push for “net-centricity,” for example. At present, when one expects to integrate with an existing system, one usually looks to get a copy of that system into one’s own development environment. This requires a longterm commitment to this foreign system, something untenable for 11. An example of a “casual” composition method is a RESTful call to a Web presence. This is a stateless query/response type of interaction with a minimum of a priori agreements needed and which uses a ubiquitous infrastructure. Another would be Really Simple Syndication (RSS). 12. Considering how difficult the integration challenges are for one to use others’ systems, what would make it easier (and symmetrically, easier for others to use yours)? A proven solution is the creation of a point-of-presence on the net where the offered functionality can be accessed and exercised. Generally, the functionality is packaged as “services,” and if structured with casual interaction models (e.g., query/response), potential users of the functionality require little investment in exploring and integrating with the offered functionality.

more than a small number of foreign systems. As communities of developers’ networks are “stood-up” and used, a new dynamic for design, development, and use may emerge. This dynamic will support exploration and discovery, and may result in a reinterpretation of what it means to be a system. An Unmet Challenge We have made a case for why and how to accelerate movement in these directions technically and operationally, and what one might tell a chief engineer. However, we’re not so sanguine as to believe that these aims will be achieved on a large scale anytime soon, since the economic and business structures do not support them very well. Nevertheless, we should endeavor to continue experimenting with these techniques in pockets of opportunity. We believe such efforts will prove successful and will, by example, gradually change the way the world works for the better. If the above four heuristics do not promise to assist chief engineers and their program offices, from where would the incentives come to do such things? Presenting collections of composable elements of valuable functionality is bound to create new opportunities, but for whom? Perhaps the end users. Today, end users have two basic options: (1) self-service (i.e., building their own tools and solutions using local talent and discretionary funds), or (2) reciting their perceived needs in the form of written requirements that then enter the formal acquisition system. Providing a third option seems worthwhile: having accessible functionalities easily composed into new systems meeting current needs (or enabling new ways to approach those needs) may allow end users to satisfy their objectives. This new way of doing business 13 also suggests that such developments will deliver both elements of systems and systems themselves. Revenues might be directed (after the fact — that is, paying for

results 14) to those organizations whose elements are used in the field within real solutions, and for which specializations of the elements are needed. While this hypothesis keeps the current framework with which we hire contractors, there is still a need to develop a system of revenue flow which rewards actual use instead of paying for development.15 For example, in everyday provider– consumer terms, when elements are selected for mission application, the activating users could trigger payments to responsible organizations, from reservoirs of available funds set up for such purposes. Gradually, over time — it would certainly take years and perhaps even decades — the acquisition system might change in transferring more of the up-front funding for development to the back-end operational use. Is this whole concept sufficient for achieving full net-centricity in the large? Probably not, but it provides an approach to convert ideas into actions, and provides a useful starting point and some suggested guidelines for moving forward and changing the acquisition world to be more effective in complex environments. Most importantly, it answers the chief engineer’s question, “So what should I go do?”

14. This is a fundamental tenet of complex systems engineering, in contrast to paying up front for perceived promises; for example, see M. L. Kuras and B. E. White, “Engineering Enterprises Using Complex-System Engineering,” in Proceedings of the Fifteenth Annual Symposium of the International Council on Systems Engineering (Seattle: INCOSE, 2005). 15 One issue is at least the initial high-risk research and development support for relatively small firms, entrepreneurs, academic researchers, and the like, which have been primary sources of innovation. For lower-risk innovations, venture capital will continue to be the primary source of funding of such concerns for the foreseeable future. Very high-risk R&D support for small and medium businesses only comes through public finance, and the U.S. government has been reducing that source of support for many years now, except in some very specialized domains. Our primary means for supporting high-risk R & D are options 1 and 2 above.

13. Similar emerging business models that have seen success are known as “service-oriented architecture” (SOA) or “software as a service” (SAAS).

INCOSE INSIGHT

January 2008

27

Special Feature

Ethnic Culture and the Systems Engineering Process Tim Ferris, [email protected]

B

efore the formalization of systems engineering, engineering projects were executed using processes chosen by the managers, who tailored insight from previous experience to their understanding of the present need. The emergence of engineered systems with strong interdependency of components soon after World War II led to significant problems with the effectiveness of product systems (Ferris 2007, part 1) and fostered the development of an embryonic form of systems engineering in an attempt to prevent the problems (Ferris 2007, part 2). By 1960, the systems engineering process had become a rather simplydescribed sequence of steps required to complete an engineering project.

The Evolution of Systems Engineering Over time the United States Department of Defense increased the documentation required, thus compelling the systems engineering process to evolve to ensure that the necessary work needed to develop the product and documents was done and made traceable. Also, while the embryonic method worked effectively for the early systems developments, the systems under development became more complex, and still some projects were unsuccessful. These factors led to the further refinement of the systems engineering process, leading to a tighter specification of the process. The outcome of this work was the development of the MIL‑STD‑499 standard, which defined in detail, in a procedural manner, the activities to be performed and the documents to be written in the systems engineering aspect of projects. This standard proved so helpful for contractors and engineers that when support for MIL‑STD‑499 was discontinued there were combined efforts of industry and professional associations to develop a new standard. The outcome was the writing of IEEE 1220 and EIA‑632 (Sheard 2001). Both of these standards continued the general philosophy of defining processes and documentation of MIL‑STD‑499. The 28

Volume 11 No. 1

INCOSE INSIGHT

systems engineering process described in the standards has been shown to be useful in improving the ability of contractors to deliver product systems on time, on budget, and providing intended performance (Honour 2004). When a method of work is successful one is tempted to believe the non sequitur that the success is innate to the method. The practical consequence of this belief is to replicate the work process in all situations. This reasoning has led to some inappropriate copying of process across industry or cultural boundaries with undesirable outcomes, which have led to disappointment and possibly “throwing the baby out with the bathwater.” The ISO 15288 standard differs from the other standards in that it does not attempt to specify what activities will be done nor what documentation will be written. Instead, the standard identifies the matters that need to be appropriately addressed. The details of the processes and documentation activities required to address the matters are left to the project leadership to determine. The advantage of the ISO 15288 approach is that the standard provides opportunity to develop specific methods, processes, and documentation forms which suit the particular needs of the project in the context in which it is done. The disadvantage of this approach is that it does not define how the work will be done, demanding consideration of this detail within the organization doing the project (Ferris 2006). ISO 15288 shows a return to some of the early roots of systems engineering: most particularly, it addresses the concern that engineers need an effective means to address the matters of product system performance, project budget and schedule, and the matters of probity associated with the project. Ethnic Culture and Systems Engineering We confront the question: “Is there one systems engineering methodology that is suitable for use in all countries?” If we answer “yes,” we assert that it is appropriate, in all cultural contexts, to

apply the same methodologies for guiding the processes of the project. If we answer “no,” we reflect the view that there is a difference in the systems engineering methodology that should be applied in different cultural contexts. The “no” answer also suggests the view that there is matter which is of the essence of systems engineering, which will be constant in all contexts, and other matter which is the accidents of systems engineering, and culturally relative. Further, the “no” answer demands that we identify the essence and the accidents so that we can develop appropriate processes that are suitable to effect the essence in the local context. The Attractiveness of “Yes” Systems engineering is about the development of socio-technical product systems. The systems are made of material that has been manufactured to a particular form. The material of the product systems conforms to the physical, chemical, and logical nature of what it is. One of the foundations of science is that material is independent of the observer, and engineering uses the knowledge developed in science as a foundation in design. Engineering design relies on a combination of scientific knowledge in analysis, and observations and experience, which are incorporated into judgments about appropriate designs. However, a technical system behaves in the same manner regardless of who operates it. The systems that are developed through the systems engineering approach are socio-technical, and therefore incorporate people as significant elements. But any system is designed with a particular class of users in mind, and the characteristics of those users, after discovery through the investigation parts of the project, become part of the information informing the design of the technical aspect of the system. The characteristics of the user community are separated from the product system development process. Therefore the diversity of user characteristics does not necessarily affect the design process, only the product design produced. The idea that one needs to have the same process by which the engineering work of a product system is designed is attractive at first glance. The commonality of methods would appear to

Special Feature

enable an outsider to enter the project and understand what is happening and how to participate in the team. This capability is particularly beneficial in multinational organizations, where it is common for managers and specialists to move between sites, often internationally, to make their contribution to projects. Commonality of methods also appears helpful where a large project is distributed between sites, so that all the documentation produced will conform to the chosen standard. But are these benefits really sufficient to justify the risks? And is standardization of process appropriate for projects performed in contexts very foreign to the North American origins of the systems engineering methodology? One argument supporting commonality of processes is that there are several systems engineering software tools to support the work. These tools are provided by vendors who have designed them to perform certain aspects of the systems engineering process, such as requirements engineering or functional analysis. These tasks are generally accepted as vital parts of the systems engineering methodology. The track record of the use of these processes shows that they have been very helpful in ensuring the clarity of thinking about the proposed product system that leads to project success. Therefore it seems good to use software that assists the rigorous fulfillment of the processes. But the matter is not so obvious. Software tools necessarily structure the work and the arrangements under which the work is done according to a particular standardized approach. In addition, the software tools are written to support projects of a certain magnitude and complexity. These characteristics mean that the use of a software tool may impose a certain approach to work on the project processes to be done, which may create difficulties for organizations whose scale of work (perhaps as a minor supplier into a large project) is much smaller than the scale for which the tool was designed. The Need for “No” There can not be one universal systems engineering methodology that will be suitable for use in all ethnic cultures. This is clear because the engineering work is done by a group of people. We must not confuse the subject matter of engineering work (the

production of the product system), with the means by which that work is done (the performing system). These two systems are obviously distinct. However, they are also of different kinds. The product system concerns things that are made and the interaction that those things have with stakeholders. The performing system is a human system that does work. Each community establishes norms for how its members should interact with each other to achieve particular ends. These norms are taught to the members of the community during their early life experiences, and repeatedly reinforced both through reward when acting in the manner accepted as normal and through disadvantage when ‘breaking the rules’. The reinforcement message strengthens the individual’s tendency to act in the manner expected in his society. Successful people have generally mastered the rules of behavior expected in their society, and developed a knowledge of the ways in which they can stretch the rules, and of how often such stretching is permissible. People who immerse themselves in another culture, trying to live in the normal environment of a foreign society, experience considerable dislocation as they need to adjust to different modes of behavior and different value systems. The dislocation involves some factors that are obviously different, and may also involve some very subtle effects. For example, I have found that Australians and Americans have quite different personal styles when trying to convince another person of their point of view, and very different views of the place of government, regulation, and law in society, as well as different views on the concept of “reasonable private use” of employer-provided resources in the workplace. The difficulty arises because we use the same words with different meanings. The issues are different in every cross-cultural situation. In my own experience I have found that the issues are more obvious, and therefore easier to accommodate, when dealing with a cultural difference that includes a different language. Therefore, the systems engineering methodology used in different cultural contexts must respect the distinctive characteristics of those contexts. Since people interact quite differently in different ethnic cultures, it is necessary to build

the process on the kinds of interaction that are normal in the ethnic culture, and then to find ways to achieve the desired outcomes. The fundamental issues that prompted the development of systems engineering were the parallel needs to maintain performance, schedule, and budget in ambitious engineering projects, in a manner that that demonstrably produced the best possible outcome from the sponsor’s viewpoint. The traditional approach to systems engineering is the North American solution to this need. Other ethnic cultures may require a different approach; engineers must find a method to suit each particular context. The Case of Taiwan I have had the opportunity to do some work exploring the application of systems engineering methodology with collaborators in Taiwan (Ferris, Wang, and Peng 2007). In this work we considered using an analytical framework for the comparison of cultures, such as that of Hofstede (1984), but concluded that to do so would not allow an understanding of the nuances of the contrasted cultures. We explored certain topics within Chinese culture that we believed to be sources of potential difficulty with respect to the application of the traditional systems engineering methodology in Taiwan. Two such difficulties are the notion of “face” and the nature of leadership. Both Chinese and Australian cultures are interested in “saving face,” but they have different understandings of what that means. The Chinese culture considers it to be the community’s responsibility to help each individual save face, following this reasoning: I have face which must be preserved and if possible enhanced. Then, suppose I do something not good, which if it were known would cause me to lose face, then it is the responsibility of everyone else never to mention what I did, so that my face will be maintained. If someone mentions it, then I lose face and am embarrassed because my fault has become known, but the greater problem is that the person has done the offence of causing me to lose face by revealing what was previously hidden. That person could, and maybe even should, be punished or reprimanded, because it is his fault that my face has diminished. > continues on next page INCOSE INSIGHT

January 2008

29

Special Feature

Ethnic Culture and the SE

continued

Australian culture, by contrast, considers saving face to be the individual’s own responsibility, according to this kind of reasoning: I have face which must be preserved and if possible enhanced. Therefore I am responsible to behave in such a manner that if anything or everything I have done becomes known then my face will be maintained. Suppose I do something not good and someone finds out and mentions it: then I lose face and am embarrassed because of the knowledge of my fault, and I must bear the consequences of the outcome, because I did the original action that, when known, led to the loss of face. The issue for both cultures is how I appear in front of others, which is important to everyone. However, there is a fundamental difference in who is considered to be responsible for ensuring that my “face” is maintained. This cultural difference affects the type of relationship staff members have with their manager. The effect on modes of relationship is accentuated because Australian culture de-emphasizes the relative rank of people except where the notion of rank is critical, in contrast to Taiwanese culture, in which issues of relative rank are always fairly close to conscious awareness. The way a particular culture constructs the concept of leadership is critically important in considering the relationship between staff and their managers, and in turn the effectiveness of processes, which necessarily make assumptions about the relationships between the people. The construction of the idea of leadership in Western contexts has been heavily influenced by Christian concepts, even though a separation of practice and origin exists. Chinese social and governance culture has been overtly constructed around Confucianism (along with other influences), with quite different practical manifestations in society. The significant outcome is quite different views of the nature of leadership and governance. The practical consequence in systems engineering of the Western idea of leadership is that the leading engineer in a project is willing to accept a report of a problem with the project as a matter to be dealt with, not as a challenge to his 30

Volume 11 No. 1

INCOSE INSIGHT

or her personal authority. The processes for systems engineering developed in the United States assume this willingness to deal with the project, warts and all, without inhibition on the part of lowerranking staff, and without perceiving personal threat by the senior leadership. These assumptions do not hold true in the Chinese cultural context. The discussion following the presentation of Ferris, Wang, and Peng (2007) in Singapore included this very interesting exchange: U.S. systems engineer: “How would a junior engineer make the team aware of a technical problem … discovered?” Engineer of Chinese background: “It is the team leader’s responsibility to identify errors.” 1 Clearly, a process originated in the United States, established on assumptions about behavior that are valid in that country, would not achieve satisfactory outcomes in the Chinese cultural context. Consequences We can see from the discussion above that cultural differences can make it difficult to apply a uniform systems engineering process across different cultures. Similarly, when dealing with the cultures of different industries or organizations, we must be careful to ensure that the process actually stipulated achieves the desired product system quality outcomes. It is particularly important that a process adequately addresses, in the cultural context of the workplace, the issues identified in ISO 15288 be used. A lot of engineering work is now conducted in multinational projects. The arrangements for such projects include diverse scenarios. In some cases the team working on any particular segment of the project is widely distributed. In other cases the project is divided into portions to be performed at different sites, with a need to integrate the products of the multiple sites into the final product system. Of course, these situations describe extremes; a project may have combinations of these approaches and other factors. 1 This account was received in an e-mail from one of the two participants and has been reworded as direct quotations.

In projects with distributed teams it is necessary to establish a common process to perform the work that is supported across the team. There is a broad body of literature about the issues of distributed teams, much of which concentrates on the processes required to establish and maintain an effective communication space between the team members. However, it is difficult to find much in the literature about how to deal with the reluctance of some team members to speak up about bad news. At the other extreme, in projects where parts of the project are distributed to different teams, the matter of process is different. The interface between the teams needs to be well defined, with wellunderstood communication processes and deliverables. However, it is not essential for the work within each team to be organized and done the same way. The overall project process must be defined in terms of the responsibilities of each of the teams, the deliverables required from each, and the information each is required to provide to others outside their own team. However, within each team there is freedom to use the most effective process to achieve the defined deliverables and communications, however best fits the cultural context. To approach the matter any other way is to impose processes that presuppose behaviors of all participants which are not natural to them. To achieve the goals of systems engineering, and to effectively manage all the matters that systems engineering addresses, requires organizations to develop (or: engineers to develop) local­ ly specific processes that rely on the assumptions about behavior and values underlying the local ethnic culture. References Ferris, T. L. J. 2006. Cross-cultural issues associated with the application of ISO/IEC 15288 standard. In Proceedings of the Sixteenth Annual International Symposium of the International Council on Systems Engineering. Seattle: INCOSE. . 2007. Some early history of systems engineering - 1950’s in IRE publications. In 2 parts. In Proceedings of the Seventeenth Annual International Symposium of the International Council on Systems Engineering. Seattle: INCOSE. Ferris, T. L. J., T. J. Wang, and W. Y. S. Peng. 2007. The interface of Chinese culture and systems engineering process. Paper presented at the Asia-Pacific Systems Engineering Conference, Singapore. > continues opposite

Special Feature

Is INCOSE a Complex System? Sarah A. Sheard, [email protected]

esearch in complex systems sciences can provide critical insight for systems engineers, but engineers must first realize they are working with systems whose primary characteristics are not those of mechanical systems. To date, systems engineering has been looking primarily at exploiting the “order” side of the order-to-chaos spectrum. This means thinking in terms of deterministic and mechanistic systems that are strictly controlled. Since systems are becoming ever larger, more interconnected, and more an evolution of legacy systems rather than a new system, it is now an appropriate time to understand and begin to utilize principles from the middle and from the chaos side of the spectrum. This article, based on my 2007 paper “Principles of Complex Systems for Systems Engineering,” describes INCOSE as this kind of complex system, and hints at some of the implications for working with INCOSE to make a difference: to improve systems engineering, to make good systems, and to improve the probability of having successful programs. Research in the world of complex systems (sometimes called complexity theory) is beginning to produce results that can be used by systems engineers, particularly those whose task is mostly analysis (Sheard 1996). Many complex systems sciences are making major strides yearly, which from the point of view of systems engineering means their recommendations are constantly changing. Viewed from a systems science perspective, we see that INCOSE as a human organization must be addressed as a complex system rather than as a mechanical system. Ferris

continued from page 30

Hofstede, G. 1984. Culture’s consequences: International differences in work-related values. Abridged ed. Beverly Hills: Sage Publications. Honour, E. C. 2004. Understanding the value of systems engineering. In Proceedings of the Fourteenth Annual International Symposium of the International Council on Systems Engineering. Seattle: INCOSE. Sheard, S. A. 2001. Evolution of the frameworks quagmire, IEEE Computer 34 (7): 95–98.

Definition of Complex Systems Articles in this issue of INSIGHT give several closely related but distinct definitions for the term complex systems. This article is in general agreement with the others, but specifically emphasizes that complex systems do not have a centralizing authority and are not designed from a known specification, but instead involve disparate stakeholders creating systems that are functional for other purposes and are only brought together in the complex system because the individual “agents” of the system see such cooperation as being beneficial for them. The following detailed definition collates ingredients of definitions from my own work (Sheard 2006), the INCOSE Systems Engineering Handbook (Haskins 2006), the Center for the Study of Complex Systems at the University of Michigan (2006), J. Maier of Clemson University (2006), D. O. Norman and M. L. Kuras of the MITRE Corporation (2006), and Y. Bar-Yam of the New England Complex Systems Institute (2006). Definition of Complex Systems 1. Complex systems have many autonomous components; i.e., the basic building blocks are the indi­vidual agents of the system. • The elements are heterogeneous (they differ in important characteristics), i.e., they have variety. • The system boundary is often hard to pin down. 2. Complex systems display emergent macro-level behavior that emerges from the actions and inter­actions of the individual agents. • They are non-deterministic, i.e., they exhibit unpredictable behavior, including chaotic behavior under certain conditions. 3. Complex systems are self-organizing (they show a decrease in entropy using energy from the environment). 4. The structure and behavior of a complex system is not deducible, nor may it be inferred, from the structure and behavior of its component parts.

• Generally the behavior involves nonlinear dynamics, sometimes chaos, and rarely any long-run equilibrium. • Often the agents are organized into groups or hierarchies; in which case the structure influences the evolution of the system. However, the complex system is not run by a central authority, nor could it be, in most cases. • Such structures tend to highlight a number of different scales, any of which can affect the behavior of the complex system. 5. Complex systems adapt to their environment as they evolve. • In particular, as they evolve they continually increase their own complexity, given a steady influx of energy (raw resources) and feedback among elements. Over time, they display increasing specialization and increasing capability. • Their elements change in response to imposed “pressures” from neighboring elements. This article uses these characteristics to analyze whether INCOSE is in reality a complex system, for if it is, then principles of complex systems should be able to provide insight into its evolution and operation. Complex Systems Definitions Applied to INCOSE This section shows how each of the above characteristics applies to INCOSE (see table 1 on following page). Implications INCOSE is clearly a complex system rather than a machine that can be designed once and only oiled occasionally. As a complex system dependent on the contributions of willing individuals, INCOSE can be managed top-down with only limited success. Rather than assign tasks, the leadership should think of itself as growing a fertile garden of agents who can take on difficult tasks as they see is necessary. Because INCOSE cannot assign rewards and punishments like salary increases or the threat of firing, INCOSE guide its members by making the advantages of participating clear to the many varied subtypes of stakeholders. > continues on next page INCOSE INSIGHT

January 2008

31

Special Feature

Is INCOSE a Complex System? continued

Table 1. Characteristics of complex systems as compared with those of INCOSE Complex Systems Characteristic

INCOSE Characteristics

Implications

Autonomous interacting parts (agents)

Members, Corporate Advisory Board (CAB) companies, working groups, chapters

Individuals are both the major strength of INCOSE and a weakness. They cannot be controlled (told what to say) and may not always “toe the company line.” They also have many conflicting loyalties such as loyalties to their employers and to other societies.

Fuzzy Boundaries

Who in CAB companies is included in INCOSE? Only the representatives? Anyone who reads CAB-accessible documents? Intellectual property issues when members contribute to INCOSE products. Cross-organizational joint efforts; members participate in multiple societies.

INCOSE often suggests its members approach engineering a system by drawing the system boundary. INCOSE itself, however, has a fuzzy boundary. Is INCOSE just the leadership? Is it all paying individual members only or the corporations that employ them and pay their dues as well? Different boundaries apply for different purposes. In addition, energy necessarily comes into INCOSE via these permeable boundaries (e.g., funding, enthusiasm of members, papers)

Self-organization (emergent order)

Members form interest groups and chapters; also groups of friends

INCOSE began with a small number of charter members and ever since, it has been growing in complexity as it has grown in numbers.

Become more complex with time; increasingly specialized

Multiplying and specializing working groups; governance structure includes positions not imagined ten years ago; certification and certification preparation courses

The initial structure of chapters plus a national body became chapters, regions, nations, and an international body. Interest groups, working groups, enabler groups, and the like perform different tasks.

Can’t design or run top-down because ...

Volunteer organization; systems engineers don’t try to fit into predetermined boxes; technology and competitors evolve (e.g., softwareintensive systems, systems of systems)

Planning complex systems tends to reduce the capability of the individual parts. Individuals will subsume themselves to an employer for sufficient remuneration, but volunteer organizations have to make use of their skills to attract them to stay.

Structure not deducible As with any social institution, structure is not from structure of tied to human bodies. component parts

The way the INCOSE structure has evolved is not a reflection of the way individual humans are structured. There are similarities to systems engineering companies, however.

Nonlinearity

The number of attendees at a conference varies Many ideas are adopted by members independent of the number of words in a significantly from year to year for reasons not paper or the number of papers on a subject: meaning is derived from inputs in linearly related to conference price. a nonlinear manner.

Energy in and out (examples)

Member dues and fees are paid by members from personal or company funds. Members bring energy to the INCOSE cause.

INCOSE boundaries have to remain perme­able. Fighting to become a “winning” society suggests INCOSE members belong only to INCOSE, when in fact many belong to compe­titor societies. Other metaphors like “adaptive” may be better suited in the long term.

Adaptation to surroundings (environment)

INCOSE meetings compete for members with IEEE, AIAA, and other groups, for example by creating a certification program.

It is advantageous for INCOSE to keep apprised of trends both in systems engineering practice and in its major customers, such as governments. What approaches will best serve the individuals who have the option to participate or not?

Systems engineers should become more aware of the com­plex systems that surround them every day, including, of course, the system that is systems engineering practice itself, and the system of INCOSE. By using complex systems principles to manage such systems, we will be able to improve the effectiveness of systems engineering in ways we cannot now anticipate. References Bar-Yam, Y. 2006. Engineering complex systems: Multiscale analysis and evolutionary engineering. In Complex engineered systems: Science meets technology, ed. D. Braha, A. A. Minai, and Y. Bar-Yam. Cambridge, MA: Springer. Bar-Yam, Y. 2007. Characteristics of complex systems (figure). http://necsi.org/projects/mcle-

32

Volume 11 No. 1

INCOSE INSIGHT

mens/cs_char.gif. Accessed December 3, 2007. Education and Research Technical Committee of INCOSE. 2005. Guide to the Systems Engineering Body of Knowledge (G2SEBoK). http://g2sebok.incose.org/, accessed 3 December 2007. Haskins, C., ed. 2006. Systems engineering handbook: A guide for system life cycle processes and activities. Seattle: INCOSE. Hybertson, D. 2006. What concepts of systems science support systems engineering? Presentation to the INCOSE Systems Science Enabler Group, July 2006. Maier, J. R. A., and G. M. Fadel. 2006. Understanding the complexity of design. In Complex engineered systems: Science meets technology, ed. D. Braha, A. A. Minai, and Y. Bar-Yam. Cambridge, MA: Springer. Norman, D. O., and M. L. Kuras. 2006. Engineering complex systems. In Complex engineered systems: Science meets technology,

ed. D. Braha, A. A. Minai, and Y. Bar-Yam. Cambridge, MA: Springer. Sheard, S. A. 1996. Twelve systems engineering roles. In Proceedings of the Sixth Annual International Symposium of the International Council on Systems Engineering (Boston, MA). Seattle: INCOSE.  . 2006. Definition of the sciences of complex systems. INSIGHT 9 (1): 25. Seattle: INCOSE. . 2007. Principles of complex systems for systems engineering. In Proceedings of the Seventeenth Annual International Symposium of the International Council on Systems Engineering (San Diego, CA). Seattle: INCOSE. Center for the Study of Complex Systems at the University of Michigan. 2005. About the science of complexity. Center’s Web site. http:// www.cscs.umich.edu/about/complexity.html. Accessed 3 December 2007.

Fellows’ Insight

Fellows’ Insight Architecture Follies: Common Misconceptions and Erroneous Assumptions | Azad M. Madni,

[email protected]

It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so. — Mark Twain

T

he foundation of any system is its architecture. Architecture determines the quality attributes of a system or software and reflects the tradeoffs made among the quality attributes to satisfy performance and “-ility” requirements. The term architecture has been variously defined as a top-down description of the structure of the system; 1 the structure in terms of components, connections, and constraints of a product, process, or element; 2 a set of information that defines a system’s value, cost, and risk; 3 and an arrangement of function and feature that maximizes an objective.4  Today, as software and system architectures continue to grow in size, functionality, and complexity, architectures are increasingly being viewed as a decision-aiding tool by stakeholders from vastly different communities (see table 1). Not surprisingly, system architects are increasingly turning to architecture for evaluating and balancing competing quality attributes to achieve the overall goals of a complex systems.5 This process, which is called tradeoff analysis, is

1. E. Rechtin, Systems Architecting: Creating and Building Complex Systems (Englewood Cliffs, NJ: Prentice Hall, 1991. 2. M. Maier and E. Rechtin, The Art of Systems Architecting, 2nd ed. (Boca Raton, FL: CRC Press, 2002). 3. Ibid. 4. J. Hale, The Old Way of Seeing (Boston: Houghton Mifflin, 1994), 8; R. Venturi, Complexity and Contradiction in Architecture (New York: Museum of Modern Art [distr. by Doubleday], 1966) 14. 5. A. M. Madni, “Architecture Tradeoff Analysis: Towards a Disciplined Approach to Balancing QualityRequirements” (paper presented at the USC-CSSE Executive Workshop, 14 Feb. 2007).

Table 1. Representative architecture users and uses

• Operational Community ——doctrine development and analysis • Technical Community ——portfolio management • Acquisition Community ——budgeting and planning • Test and Integration Community ——interoperability design and analysis intended to produce an effective compromise among the levels of attainment on competing quality attributes such as performance, survivability, and cost. Surprisingly, despite the growing importance of architectures, common misperceptions about architectures still linger in the software and systems engineering communities. This technical note discusses some of the more important misconceptions and erroneous assumptions that can potentially compromise architecture development and tradeoff analysis. It is also intended to clarify some of the frequently used architecture-related terminology for non-architects. Common Misperceptions Table 2 presents some of the common misconceptions and erroneous assumptions made about architecture. Modularity conquers complexity. Modularity is frequently viewed as a means to simplify design, manage complexity, and improve maintainability. Modularity has an intuitive appeal because it conjures up images of conquering complexity and achieving the elusive goal of reuse. In fact, by adhering to these notions software and system architects can fall victim to the “modularity trap”— the mistaken belief that modularity is a way out of the complexity jungle. To begin with, how does one achieve “coherent

Table 2. Common Misconceptions and Erroneous Assumptions

• Modularity conquers complexity. • Architectural complexity reflects problem complexity. • Process maturity assures quality. • Complexity can always be reduced. • Complexity can only be managed. • System complexity determines user interface complexity. • Decomposability is synonymous with modularity. • Humans are just another component in the system. • Quality attributes are absolute. • Architecture determines system’s quality attributes. • Algorithms and data structures are not part of architecture. connectivity” among modular subsystems? And how does one appropriately define mediating standards between the modules? Beyond that, modularity can have unintended consequences for system maintainability and evolvability. For example, it is unclear what level of modularity produces an effective tradeoff between maintainability and coherent connectivity. And, finally, modularity can potentially limit future innovation, resulting in only incremental improvements within modules. Counterintuitive as it may seem, modularity is not enough! Architectural complexity reflects problem complexity. Technical publications frequently point to problem complexity as the source of architectural complexity. This view is only partially correct in that architectural complexity can also result from poor design decisions. In other words, designer-induced complexity can be an unintended or incidental consequence of designer decisions. Therefore it is important to distinguish between essential, accidental, and optional complexity. Essential complexity is systemic complexity arising from complexity of the problem. Accidental complexity is the result of suboptimal decisions made by architects and designers. Optional complexity is the result of adding new, > continues on next page INCOSE INSIGHT

January 2008

33

Fellows’ Insight

Architecture Follies

continued

optional features that contribute to overall architectural complexity. From a somewhat different perspective, one also needs to distinguish between and understand the tradeoffs associated with man-machine interface (MMI) complexity and implementation complexity. MMI complexity is invariably a source of cognitive load on the human. For example, cognitive load can result from having to monitor or perform concurrent tasks. Implementation complexity, on the other hand, is often the result of a highlevel MMI that simplifies human-system interaction but shifts the processing load to the machine. The lesson to be learned in terms of architectural complexity is to avoid “feature shock” through indiscriminate introduction of MMI features. Process maturity can control quality attributes. There is often a mistaken belief that process maturity can control quality attributes. The reality is that mature processes can control and predict schedule and cost, but do not guarantee meeting other quality requirements. It is also important to realize that quality means different things to different people, as evidenced by the use of techniques such as Cost as an Independent Variable (CAIV) and Schedule as an Independent Variable (SAIV). And, finally, even with mature processes one cannot collectively maximize all quality attributes. In other words, mature processes can go only so far! Complexity can always be reduced. It is not unusual to read that complexity can always be reduced through proper design practices. The reality is that only design-induced architectural complexity can be reduced. Systemic (or structural) complexity is intrinsic to the problem and cannot be reduced! Complexity can only be managed. At the other end of the spectrum are those that believe that complexity cannot be reduced, only managed. Once again this belief is true only for systemic complexity. It is not true for design-induced architectural complexity that arises, for example, from suboptimal design decisions leading to overly complex or extraneous protocols, or indiscriminate inclusion of features that have marginal utility for users. Such complexity can be reduced through design or protocol simplification and elimination of extraneous 34

Volume 11 No. 1

INCOSE INSIGHT

features. So, the assertion that complexity can only be managed is not only a pessimistic view but also incorrect. System complexity determines user interface complexity. This belief implies a one-to-one correspondence between system complexity and user interface complexity. In fact, this belief is untrue, especially today when much of system complexity can be effectively hidden from the user through the use of composable, context-sensitive displays, and through automation. Such displays are becoming increasingly more important as large-scale systems such as FORCEnet are beginning to embrace composable architectures. The challenge in this case is to make sure that decision-relevant information is not inadvertently left out during user interface simplification either through automation or the creation of composable, contextsensitive displays. The key to avoiding the increase in human error rate following user interface simplification is to explicitly identify assumptions and usage context associated with the displays. Decomposability is synonymous with modularity. One occasionally finds decomposable systems being viewed as modular systems. There is, in fact, a telling distinction. Decomposability is a special form of modularity in that a fully decomposable system is a modular system wherein there is no interaction among the modules. A modular system (i.e., one with distinct subassemblies or components), on the other hand, often embeds complex interactions both within and among modules. Such interactions, which cannot be ignored, contribute to the overall complexity of the system. Humans are just another component in the system. This clearly erroneous assumption is what I call the “transfer function folly.” In fact, humans are the adaptive elements in the architecture. As such, while they are key to dealing with unprecedented situations, they can also be the primary source of unintended consequences. Quality attributes are absolute. In fact, quality attributes exist in the context of specific goals and are addressed as such. Thus, a system is said to be modifiable with respect to a specific kind of change, or secure with respect to a specific kind of threat, or reliable with respect to a specific kind of fault.

Architecture strictly determines all of a system’s quality attributes. This assumption is in error in that an implementation can diverge from an architectural plan and thereby compromise quality.6 Furthermore, an architecture does not strictly determine all of a system’s quality. For example, usability, an important quality attribute for manned systems, is largely a function of the user interface. While certain aspects of the user interface tend to be subsumed within the architecture (e.g., getting data to and from a user interface, the ability to change the user interface), the aesthetics of the user interface and human-machine dialogue design are not part of the architecture. Algorithms and data structures are not part of architecture. This assumption can be erroneous in many cases where, for example, the complexity of the algorithm has a dramatic impact on performance. In such cases, the algorithmic processing is often distributed among computing elements (e.g., clusters) to satisfy performance constraints. Similarly, certain properties of data structure (e.g., the need to support concurrent access) can have a direct impact on both performance and reliability, two key quality attributes.7 Concluding Comments Architecture is rapidly becoming an aid to decision making for stakeholders from a variety of venues in government and industry. Its application ranges from doctrine development to portfolio management and interoperability design. Given the growing importance of architecture in decision making, it is important to recognize and root out common misperceptions about architecture. This paper has identified several important misconceptions and erroneous assumptions that can potentially compromise architecture design and tradeoff analysis. Armed with this knowledge, a systems architect can undertake architecture design in a circumspect fashion, while systems engineers and non-architects can begin to view architectural issues without making unwarranted assumptions about “architecture.” 6. P. Clements, R. Kazman, and M. Klein, Evaluating Software Architectures (Boston: Addison Wesley, 2002). 7. Ibid.

INCOSE Forum

INCOSE Forum Desert RATS! A Field Report Jack Ring, [email protected]

N

ASA demonstrated the state of its preparations for a new manned mission to the moon in a recent session called “Desert RATS,” which stands for “Research and Technology Studies.” (British readers should note that this is not about their famed Seventh Armoured Division.) The original press release is available at http://

www.nasa.gov/home/hqnews/2007/aug/ HQ_M07112_Desert_Rats.html.

Mission NASA is conducting Research and Technology Studies to enhance their understanding of the possibilities for partnership between humans and robots in space exploration, especially as enabled by technology advancements. This year’s event focused on field-testing concepts for NASA’s planned mission to the moon by 2020. Testing After eleven months of planning for two weeks of field test operations, NASA held the Desert RATS 2007 session in Cinder Lake, northeast of Flagstaff, Arizona. Cinder Lake contains no water. Instead, it consists of approximately one thousand acres of volcanic discharge, in the form of pellets approximately two to five millimeters in diameter that crunch underfoot. NASA says this environment closely resembles the lunar surface. Cinder Lake is just over a ridge from where the Apollo astronauts trained for the original lunar exploration mission. In fact, NASA’s intent to return to manned exploration of the moon and beyond by 2020 is what brought everyone to the Desert RATS session. The test team consisted of approximately seventy-five NASA personnel. Leaders from NASA Headquarters Exploration Systems Mission Directorate included Chris Moore (program

executive of the Exploration Technology Development Program), Geoff Yoder (acting director of the Directorate Integration Office), and David Jarrett (program executive for Extravehicular Activity [EVA] systems). Leaders from NASA Johnson Space Center included Joseph Kosmo (test director for Desert Research and Technology Studies), Barbara Romig, (test conductor of Desert Research and Technology Studies), Amy Ross (lead for the Constellation spacesuit element pressure garment subsystem), Lindsay Aitchison (engineer for Constellation spacesuit element pressure garment subsystem), Frank Delgado (Science, Crew, Operations and Utility Testbed [SCOUT] project manager), and Robert Hirsh (lead for SCOUT software and for the astronaut interface device). On 12 September, NASA hosted a one-day event for the media, who were represented by fifteen personnel from NBC, the Chicago Tribune, the Houston Chronicle, Russian State Television, and INCOSE INSIGHT (Mary Lou Padilla and Jack Ring).

A poster for the RATS Test Program, which is preparing NASA for lunar exploration in 2020, and eventually, missions to Mars. The exploration will cover about four hundred times more area than did the Apollo series, partly due to improved space suits and partly due to the greater capability of the new Lunar Roving Vehicle.

An astronaut (on the right) being seated in the SCOUT vehicle. Astronaut mobility will allow them to do “what geologists do” even when wearing rock-hard pressurized suits.

According to test director Joseph Kosmo and test conductor Barbara Romig, RATS 2007 focused on these tasks: a) Conducting a representative site survey for assembly of a lunar outpost. b) Deploying an electrical power cable two hundred meters from the central station solar power system assembly. (The Apollo astronauts were limited to less than ten kilometers from the Lander, the ‘walk-back’ distance, whereas the next mission will allow the astronauts to explore two hundred kilometers from the central station because the autonomous vehicle can go get them in case of a problem.) c) Measuring the task efficiency of humans (astronaut control of SCOUT), robots (autonomous control — using terrain maps in lieu of Global Positioning System receivers — of SCOUT), and humanrobot teams (remote control either locally or from Johnson Space Center, including the five- to ten-second lunar delay) while performing the above two tasks. (The SCOUT mechanical vehicle is not a prototype of the Lunar Rover Vehicle, but only a carrier for the technologies under test.) d) Testing the suitability of advancedconcept space suits (known as Mark III and I-suit) to perform pressurized mobility operations. The concept of operations emphasizes letting geologists do what geologists need to do. The next lunar exploration will range farther than Apollo. For this reason, mobility is another goal, achieved by rotating joints at waist, > continues on next page INCOSE INSIGHT

January 2008

35

INCOSE Forum

Desert RATS!

continued

hip, knee, ankle, shoulder, and wrist. Both suit configurations are designed for rear entry so that less time is taken to get into the suit, leaving more time for extravehicular activity.

The SCOUT vehicle, moving left to right, towing a cable deployment trailer, laying power cable from the central site to an exploration site.

Test Operations The testing we observed entailed the astronauts • donning spacesuits, passing through an air shower and (with assistance) mounting the SCOUT vehicle; • with assistance, attaching a cable deployment trailer to the SCOUT vehicle; • driving the SCOUT two hundred meters, deploying the power cable; • collecting surface samples with tools and an electric drill; • taking the vehicle on a remotely controlled excursion; • returning to central camp for a recharge of liquid air (one suit would not recharge — the astronaut shed the suit and then remounted SCOUT to continue the other tests in shirt sleeves); • returning to sample collection site for more samples; • returning to central camp; and • deploying the Lunar Science Equipment Package (LSEP). Instrumentation These test operations also involved many kinds of instrumentation, control equipment, and control software as well as extensive video documentation of the test operations to help analyze the lessons learned and for the sake of public relations.

Test Staff In addition to observing the testing, we had the opportunity to talk with many of the test staff. We were impressed with the percentage of younger people, the relatively high ratio of women, and the report from many of them that they had started on a cooperative education student basis, and then converted to full time. Cooperative education students are undergraduate or graduate students who regularly alternate semesters at school with semesters at NASA, working in a paid, full-time position directly related to their field of study. This supplements lessons learned at school and gives valuable real-world experiences they will not get in a classroom. Reflection The RATS demonstration highlights several important considerations for INCOSE members. The main contribution of the engineering phase of systems realization is pragmatic foresight — selecting the technologies and manifestations thereof that, when allowed to interact, will generate acceptable behavior. Alternatives are prudent when missions are extensive, of high variety, and highly ambiguous, and the early testing of operational concepts and the interactions among them can improve the viability of concepts early in the system realization stages. RATS test results will inform the technology and concepts offices about the viability and unforeseen implications of their ideas. We asked a question about the usefulness of information generated with 2007 technologies to missions in

Astronauts clearing surface material (left) and using a power drill to probe subsurface material (right). Note the rotary joints at waist, hip, knee, shoulder, elbow, and wrist that enable needed mobility. The backpacks carry liquid oxygen and associated life support.

Jack Ring and Mary Lou Padilla, astronauts for a day. The SCOUT vehicle has a joystick for direction and speed control. Operational modes and states are chosen on moveable touchpads in front of the passengers. Batteries and solar array auxiliary chargers are in the rear. Frank Delgado, SCOUT Project Manager (not pictured), rode with photographer Mary Lou Padilla as she drove the vehicle. She did not quite reach the maximum speed of 9.2 mph.

2020, approximately three technology cycles later. An example is testing deployment of a modern electrical cable when the 2020 cable may be made of carbon nanotubes, which would exhibit quite different deployment characteristics. David Jarrett, the program executive for Extravehicular Activity (EVA) systems, explained that NASA personnel are quite aware of these time skews and have ways of mapping technology advancements onto concepts and even ways of architecting systems to enable technology insertions during the useful operational life of the system. The six-year build cycle means the 2020 mission will be predicated on 2014 technology and operational concepts. The reality brought forward by RATS informs these insights, and thus contributes to the incremental increase in confidence in the concept of operations for lunar exploration. Consider the following relevant questions for INCOSE: • When authoring or approving standards, do we include early concept testing in near-real operational environments? • Does our Systems Engineering Handbook do likewise? • Do our working groups do likewise? • Does our system-of-systems thinking include the ability to design systems that learn and then morph based on > continues opposite

36

Volume 11 No. 1

INCOSE INSIGHT

INCOSE Forum

Using the PICARD Theory of Systems to Facilitate Better Systems Thinking James N. Martin, [email protected]

S

ystems are not as real as we think they are. Weinberg (2001) said more or less the same thing when he said that a “system is a way of looking at the world … A system, any system, is the point of view of one or several observers.” It is indeed true that engineers design things that when placed into service are very real. But these things are merely constituents of perhaps many different systems. It is up to our imagination to assign these engineered things to particular systems. Assigning these things to systems is what is involved in “systems thinking.” We make assignments of things to systems before these things exist in order to examine their contribution to the system’s intended purpose. We can even make assignments of things to different systems to examine how they are currently behaving (or perhaps misbehaving). This article will explore what it means to employ systems thinking to imagine various system structures and to examine these structures for their suitability in different situations to address perceived problems.

Misperceptions There is a common misperception among systems engineers that the systems we engineer are real. They are in fact imaginary. By “real,” I mean things that actually exist in the real world. By “imaginary,” I mean things that exist in the mind. Nothing is inherently a system: Desert RATS!

systems exist only in the mind. There might be parts of the system that are real, but the system as a whole is a fabrication of our mind. Most of us believe that a system exists of its own accord. But we have free choice in choosing the constituents and boundaries of such systems. Take for example the solar system. The contents of this system were traditionally defined as the Sun plus nine planets. Then in 2006, a group of astronomers decided that the solar system really consists of the Sun plus eight planets. Did Pluto disappear from the sky? Of course not — they merely realized that the previous definition of the system was not suitable to their way of thinking. In the same manner, systems engineers should define their system of interest in a way that is most suitable to their situation. Sometimes the system of interest should be larger than just the thing being acquired to meet a mission need or to solve a particular problem. This false notion that systems are real, just waiting to be discovered, often leads us to only think about the physical aspects of systems and not their sometimes more important non-physical aspects such as behavior, information, and value. If we do not change our conception of how to define a system, we will not likely examine other possible constituents or boundaries of the system to determine if another “system” leads to better solutions.

continued

that learning, over a thirty- to fifty-year operational life? • Do we apply our thinking about semiautonomous systems to the system that accomplishes systems engineering? That is, just how autonomous should the practitioners be, especially when engaged in trade studies? Driving the SCOUT A special treat was getting to drive the SCOUT vehicle. Frank Delgado, the manager of the SCOUT project, was especially helpful in explaining the

role of the vehicle operator and riding along as Mary Lou Padilla operated the vehicle. Robert Hirsh demonstrated the operation of SCOUT by walking alongside with his hand-held controller. Appreciation Thanks to Joe Kosmo and Barbara Romig for reviewing this article. Thanks as well to Brandi Dean of the Public Affairs Office of NASA’s Johnson Space Center, who approved our participation in the media event, and to the rest of the NASA staff who hosted our visit.

Concepts The car you drive has physical traits like size, weight, and power. But in your mind you also think of the car in terms of how it grabs the road, how it feels to drive in traffic, how it propels you to work every day. The car you imagine is not the same as the car that sits in your driveway. Our mind is like that: it makes us believe that the thing is identical to our concept of the thing (Sowa 2000). Whenever we think about the car, we are really thinking about the car concept, not the car object. Of course, the car concept does have a direct connection to the physical attributes of the car object. Let’s examine these connections more closely. Relationships One way to think about these connections is through the discipline of systems thinking (Weinberg 2001). By using this way of thinking, we can better “see” the car as a system, as a collection of things that interact with each other and with the driver and the road. Our seeing of these relationships 1 is key to what constitutes systems thinking. Without relationships, there can be no system: we cannot even think about the system unless there are relationships to consider. If the parts of a system have no relationships between them, then there can be no system. Our task as systems engineers is to discover the most relevant relationships and determine how they best contribute to overall value (Hitchins 2004). What Is a System? We can think of any object (or collection of objects) as a system. When we think of a single object as a system this is called “black box” thinking. It is called a black box because we are ignorant of (or don’t care) what is inside the box. The focus is on the interaction with things outside the box (Van Daalen, Thissen, and Verbraeck 1999). When we think of a collection of 1. A relationship is an association of some sort between two or more things. The “things” can be thought of as the nouns and the “relationships” can be thought of as the verbs (italicized in these examples): A song (thing) is performed by (relationship) a singer (thing). A concert is performed by an orchestra. An orchestra consists of musicians. Orchestra members play instruments. And so on. > continues on next page INCOSE INSIGHT

January 2008

37

INCOSE Forum

PICARD Theory continued

objects as a system this is called “white box” thinking, since we are looking inside the box to see what is happening. The white box, in this case, is the collection (or container) for the things we consider together as a system. When you are not concerned with all the internal workings of the box, but only certain aspects of it, this is sometimes called “gray box” analysis. The systems approach to thinking can help us examine how the system behaves, how well it performs, what it is made of, or perhaps if it has value. This examination is often called systems analysis (Wasson 2006). Before we can do systems analysis, we must define the system in terms of its objects, their relationships, and the context in which these objects reside. Thinking of something as a system is usually not consciously done. We do not usually make a conscious effort to think of something as a system; we often do this below our level of conscious thought. People who are better at systems thinking seem to have learned to force this sort of thinking more into the conscious area of their mind. They have learned mental tricks to help manipulate their perceptions in order to consider more of the “systemness” of a situation, as opposed to the merely substantive, material aspects of those circumstances. One technique for facilitating this thinking process is to draw a context diagram. This diagram has a box that represents the system with inputs and outputs going into and out of the system (Blanchard and Fabrycky 2005). We can then decompose this system (the black box) into its constituent parts and then examine the relationships (e.g., inputs and outputs) for each of the parts (the white box). We can go into more detail by examining each part as a system itself, by going through the same decomposition process, ad infinitum, until we discover what we need to know about that system. We can recompose these lower-level parts into higher-level aggregations to discern where we have emergent behavior that is not exhibited by the parts taken individually (Hall 1989). Some of this emergent behavior is good and some is bad. We are trying to find the system configuration 38

Volume 11 No. 1

INCOSE INSIGHT

where the good behavior outweighs the bad behavior in a cost-effective manner. For the purpose of this article, let us think of a system in this way: A system is a conceptual overlay placed on top of those things we choose to consider as elements of the system. This definition should suffice for now. Later in this article I will describe the six dimensions of a system that can help us see better every important aspect of the system of interest. Systems Analysis When we do analysis of a system, we need to be careful in how we choose which “system” to examine. Making a wrong choice can possibly lead to erroneous conclusions. To illustrate this concept of system choice, consider the following situation where we have a collection of green dots; this set of dots might be “seen as” the system. (Just because it is a “set” does not necessarily qualify it as a system.)

It is quite natural, and perhaps even fitting, that we group these items into several systems as shown below based on strong interactions due to couplings of some sort—perhaps physical attractions due to gravity or some other physical force, or maybe data flows:

But we can also examine these things from another angle, such as mission threads or social relationships perhaps, and your depiction of relationships might appear like this instead: So, which depiction is correct? The answer depends on the purpose of our

analysis. What questions do we wish to answer? Different questions lead to sometimes different depictions of the situation — or perhaps more correctly we should say different depictions of the system. Imagine, for example, that you notice a problem for one of these items:

It is natural for most people to immediately group the more obvious elements into their presupposed system and then start to do analysis of the situation. The tendency is to identify the cause of a problem to be in nearby things. So we draw a system boundary around the collection of things that appear to be in more or less direct contact with the problem item. But if we happen to choose the wrong system, then the results of our analysis might lead to a wrong, or perhaps less effective, solution to the perceived problem. I once worked on a large acoustic surveillance system where, during a field trial, the electronics assembly equipment experienced failures at the interfaces (Martin 1993). These interfaces belonged to a particular device, and so that item was redesigned to help avoid such failures in the future. During subsequent testing, it was discovered that the root cause of the initial interface failures was a fault in the operation of the cable handling equipment, not the electronics assembly design. We had drawn the boundaries around what we thought to be the system and proceeded to “fix” the problem by changing the design of that system. We would have been better off by defining several different system configurations

INCOSE Forum

and then examining each of these to determine various alternative fixes to the problem. Going back to the example with the green dots, by taking the mission thread approach (which is only one among the many systems techniques available to the practitioner), this might have led to perhaps a very different solution. This approach might lead you to a different conclusion about the root cause (the real problem) of the “pain” (the perceived problem):

System Constituents Now I would like to examine the nature of a system in terms of its constituents. A “constituent” is an abstract part of something.2 Using the definitions from Word Web Online (www.wordwebonline.com), we can say that a constituent is also “an artifact that is one of the individual parts of which a composite entity is made up; especially a part that can be separated from or attached to a system.” An artifact is “a man-made object taken as a whole.” A system, then, is made of abstract and man-made elements. Furthermore, these parts can also be concrete and not made by man (for example, water used as a coolant in the car’s cooling system). Product Dimension The first type of system component to look at is the thing we call a product. These are things such as hardware and software that we produce based on engineering designs. A product is “an artifact that has been created by someone or some process” (Word Web). This col2. For example, two constituents of a musical composition are melody and harmony. Melody and harmony obviously interact with each in often complex and interesting ways. Notice that the constituents of a system are not necessarily physical entities. In fact, often the most interesting constituents of a system are non-physical—things like procedures, policies, rules, functions, states, and modes.

lection of products is what most people normally think of as the system.3 I would like to extend this notion of products to non-man-made products like water and petroleum. These are natural products produced by natural processes. We sometimes will use man-made efforts to convert these natural products to manufactured products like bottled water and gasoline (or petrol). Products can be hardware, software, data, facilities, materials, services, techniques, personnel, and so on. The types of products to be considered depend on the domain being examined. Products will have properties that might be relevant to that product’s behavior and suitability with respect to the other products or the overall system. The properties can be logical, physical, relational, conceptual, managerial, and so on. The relevant properties to consider are a function of the purpose of the analysis. It is very common to depict a system only in terms of its hardware and software components, like this:

But this is by no means a full depiction of all the various products that make up this system. Where do humans come into this schema? Can humans be a product in the system? Notice above, where I indicated that one product type could be “personnel,” which can be defined as “the body of persons employed by or active in an organization, business, or service” (American Heritage Dictionary, 4th ed.). We can consider, of course, that humans are natural products conceived in a natural, biological manner, but we can also consider humans to be “manufactured” 3. When engineers are only considering the products, then this I would call “product engineering” or “product development” as opposed to systems engineering. There is nothing wrong with this for relatively simple products or situations. It is when you have a complex situation or difficult technological issues where you really need true systems thinking.

products of our institutes of education and training. So why is it inappropriate to think of a collection of products as a system? The so-called system breakdown structure or parts list for the “system” usually only lists the products that belong to the system. It is not wrong, merely incomplete. This type of thinking does not get you very far when you have to understand the systemic nature of a problem, especially when you need to consider how something happening in one part of the system might have an impact (good or bad) on another part of the system. What is missing from this simplistic approach to systems thinking? Interaction Dimension The foremost thing to consider beyond the product dimension is the set of interactions. Internal interactions occur between the products inside the system. External interactions occur between the products and the outside world (i.e., those things beyond the system boundary). Interactions are often some sort of transfer between objects. The interactions we identify can take on various forms — data flows, material flows, forces, energy, feelings, learning, and so on. What about feelings? How in the world would feelings be relevant when doing systems analysis? What about learning? What does learning have to do with systems? Consider what exactly is being transferred between a teacher and student. Is this merely data flow? If so, then this will only result in memorized sets of words and numbers. Is there some sort of energy flow that contributes to the transfer of knowledge? What is being transferred between mother and child, the thing we call love? In systems thinking we sometimes must go beyond our common tendencies to think only of the technical flows. But in engineered systems there may indeed be non-technical flows to consider, especially when some of the system elements are non-technical like people.4 To illustrate this dimension let us consider these eight elements: 4. People, as I mentioned before, can be thought of as products, too. They are the products of their family situation, their educational experience, their social life. People interact with each other and with impersonal objects like hardware and software. INCOSE INSIGHT

January 2008

39

INCOSE Forum

PICARD Theory continued

How many possible ways can they interact? What is the best way for them to interact? What are the advantages and disadvantages of each way?

The answer to these questions is often a matter of context. Context Dimension The third thing to consider when thinking about systems is the context. Context is “the set of facts or circumstances that surround a situation or event” (Word Web). Context consists of environments, scenarios, and situations. These environmental circumstances could be in the form of physical environment (e.g., cold and wet), social environment (e.g., congenial and warm), or political environment (e.g., autocratic or democratic). The context could describe the particular scenarios of interest to be examined. Will this system need to operate only during good weather or must we also consider bad weather? Scenarios deal with postulated sequences of possible events such as in 40

Volume 11 No. 1

INCOSE INSIGHT

a war where the adversary has already breached the first line of defense, a new market with little or no competition where our new product launch is about to start, in an economic depression followed by government breakdown along with social unrest, and so on. Factual situations could be in the form of technology limitations, funding constraints, legislative mandates, human restrictions, or physical laws. Sometimes the situation is not necessarily factual since there may not be clearly established facts but merely beliefs — things that people believe to be true but that may or may not actually be true. When examining a system that includes people for proper functionality and behavior, it is often more important to understand what the people believe than what is in fact true. Hardware and software are often more directly connected to the factual situation since they usually get their data from objective sensors, verified processors, and validated databases. People, on the other hand, have “subjective” sensors and often non-transparent processing algorithms (i.e., thinking). Their thinking might be crisp and logical, or it might be soft and fuzzy. Nonetheless, the behavior of the people in this setting could have significant impact on the proper behavior of the system of interest. Action Dimension The fourth thing to consider when thinking of systems is the identification of desirable (and possibly undesirable) actions. Action of the products is what causes the interactions within different contexts to occur. Action is how the products respond to actions by other products. The action and reaction is what constitutes the interaction we considered above. Action is what each product itself does; interaction is what the products do to each other. Sometimes a certain action by a product will cause a different interaction with another product depending Context A Action 1

Action 2

Context B Action 1

Action 3

on the particular context. In other words, the appropriate action in each case is context-dependent. The action dimension of systems analysis has a long history in the discipline of systems engineering. Traditionally it is called functional analysis but lately there is a new approach called object-oriented analysis. Even more recent is an approach called service-oriented analysis. There is not a single approach that is best for all situations. The approach chosen may be dependent on the types of products that dominate our system. For example, software-dominant systems analysis might need object-oriented techniques, while people-dominant systems analysis might use the service-oriented approach. Relationship Dimension A relationship is a connection, association, or involvement between two or more things. A relationship can be spatial, temporal, or spectral: an electronic circuit can be mounted inside a chassis; a startup routine must occur before normal operations can be performed; an ultraviolet transmission occurs above the normal range of visible light. It can be social, political, or organizational. Relationships often dictate what is allowed to happen or what must happen. If a country has a treaty with another country, then certain restrictions apply that inhibit certain actions. If Susan’s mother is on the organizing committee, then this might affect whether Susan gets the appointment (and likely will affect how Susan behaves after receiving the appointment). If an anti-aircraft weapon is placed under the camouflage net, then this impacts its observability from above (and likely will increase its survivability under battlefield conditions). As you can see, relationships are not the same as interactions but they can have a definite impact on what, when and how interactions occur. Relationships are the most important aspect of systems thinking. Without relationships we cannot even imagine the system properly. However, we tend to limit our thinking only to the interfaces between products where we have flow of data, material, or energy. We must expand our repertoire of relationships beyond just interfaces. By doing so we can expand our ability to perform better systems thinking.

People On the Move

Destiny Dimension Destiny is the “predetermined, usually inevitable or irresistible, course of events” that will befall the system (Random House Unabridged Dictionary [2006], accessed at www.dictionary. com). However, destiny is not only what happens to the system over time. It is also the resultant outcome of having the system in place. These outcomes ultimately determine the value of the system. So, destiny is the ultimate reason for bringing the system into existence. The purpose of systems engineering is to influence the destiny of a system and perhaps even be the prime motivator to make the perceived course of events come about. Sometimes the destiny is called the “mission” of the system. We often define this in terms of a “concept of operations” for the system. We translate this into a set of requirements that specify the full range of behavior and performance of the system to ensure that it will fulfill its “preconceived” destiny. Systems engineering never has a completely accurate crystal ball, so there is always some element of surprise when the destiny of the system is finally realized. Nonetheless, we must keep in mind what Plato had to say about this: “Begin with the end in mind.” The PICARD Theory of Systems It is by examining these six types of things that true systems thinking can occur. I call this the PICARD theory of systems (products, interaction, context, action, relationship, and destiny). The connections between the PICARD elements of the system are what give the system its emergent behavior. Each product within a system will have its own behavior, but this behavior is often of little use by itself until it creates a system-level behavior that provides a useful feature or function to the system user or operator. We are not thinking about the whole system unless we are considering all of these elements. Systems thinking is about thinking holistically. Holistic thinking is difficult and I hope that this PICARD

System = Products + Interactions + Context + Actions + Relationships + Destiny

People On the Move David Wright, Samantha Brown, and Paul Schreinemakers at the recent INCOSE U.K. Autumn Assembly. Since the assembly attracted over one hundred delegates for each day, these three used it as an opportunity to campaign for president-elect — and yet they still found time to have a friendly chat over coffee! (Photo by Paul Davies)

theory can make such thinking easier and more commonplace. This, in the end, is what systems engineering is all about: translating user needs into a collection of engineering products to be built using technological elements. Systems engineering is, in other words, the process by which we turn the imaginary (the concept) into the real (products and services). The degree of “realness” depends on how well we have managed the risk as we progress, and what intermediate artifacts we produce to get us there (e.g., requirements documents, architecture diagrams, test specifications, prototypes). It is all about transition from the imaginary to the real.5 But the trick is not going directly from stated needs to product attributes. We must consider through the systems engineering process how interactions, context, and actions help the products meet those user needs. Furthermore, we must properly consider how relationships impact the overall behavior and how the destiny of the system can eventually be achieved. We can facilitate the systems engineering process by doing better systems thinking. The PICARD theory of 5. Private correspondence with Trevor Rickard, February 2006.

systems holds some promise in helping us think more precisely about the systems we intend to engineer. It will hopefully help us avoid the mistakes that can result from incompletely or incorrectly defining the appropriate system of interest. References Blanchard, B. S., and W. J. Fabrycky. 2005. Systems engineering and analysis. 4th ed. Upper Saddle River, NJ: Pearson Prentice Hall. Hall, A. D. 1989. Metasystems methodology: A new synthesis and unification. Oxford: Pergamon Press. Hitchins, D. K. 2004. Advanced systems thinking, engineering, and management. Boston, MA: Artech House. Martin, J. N. 1993. Reverse engineering a system using life cycle modeling. In Proceedings of the Third Annual International Symposium of the National Council on Systems Engineering (Washington, DC). Seattle: INCOSE. Sowa, J. F. 2000. Knowledge representation: Logical, philosophical, and computational foundations. Pacific Grove, CA: Brooks/Cole Thomas Learning. Van Daalen, C. E., W. A. H. Thissen, and A. Verbraeck. 1999. Methods for the modeling and analysis of alternatives. In Handbook of Systems Engineering and Management, ed. A. P. Sage and W. B. Rouse. New York: Wiley. Weinberg, G. M. 2001. An introduction to general systems thinking. Silver anniversary ed. New York: Dorset House. Wasson, C.S. 2006. System analysis, design, and development: Concepts, principles, and practices. New York: Wiley.

INCOSE INSIGHT

January 2008

41

INCOSE Infrastructure

INCOSE Infrastructure Fellows Continue to Contribute to INCOSE William Mackey, [email protected]

O

ur Council created the honor of INCOSE Fellow to recognize members who have distinguished themselves in the “interdiscipline of systems engineering.” The Fellows are nominated and evaluated through a stringent process that normally takes two months after the nomination package is complete and submitted. A Fellow is nominated and honored for distinguished accomplishments as a researcher, educator, or systems engineering practitioner. While there is no way to predict whether a Fellow once selected will continue to contribute to the systems engineering discipline or to INCOSE with the same zeal that brought such recognition, history has demonstrated that many Fellows have become the leaders of the key initiatives of INCOSE. As the current Chair of the Fellows Committee, I am pleased to report that our Fellows do contribute to INCOSE in many ways. As an example, in 2003 Paul Robitaille, chair of the Corporate Advisory Board, and I, as chair of the Technical Board, identified five major goals for the next few years and persuaded our organizations to accomplish them: Goal 1 – Identify and distribute to the entire membership all the existing products created by the INCOSE technical community. Fellow Richard Wray took charge of accomplishing this goal: he not only identified all the INCOSE technical products and technical data, but also classified these products and developed a process to ensure that new products were created, developed, reviewed, approved, and properly distributed to the INCOSE membership. He and Steve Sutton created a CD with all of the technical products and technical data and distributed it to the entire membership during 2004. 42

Volume 11 No. 1

INCOSE INSIGHT

Goal 2 – Update and distribute the Systems Engineering Handbook. There have been a large number of contributors to the handbook, which remains the most important document the Council’s technical community has produced. Fellow Dorothy McKinney led the development of version 1.0 of the handbook; Fellow Richard Wray led version 2.0; and Fellow Kevin Forsberg led versions 2.0a and 3.0. Goal 3 – Develop a future vision for systems engineering. Again, there have been a large number of contributors to the effort to create a technical vision for systems engineering. Fellow Donna Rhodes led the Fellows in creating the first Systems Engineering Technical Vision. Fellow Rich Harwell later led the effort for a while, and most recently, Fellow Harry Crisp has led the creation of three new versions of the documents. Goal 4 – Develop a systems engineering certification program. John Clouet initially led this effort through the formative stages of development. Ken Kepchar, John Muehlbauer, and Mike Krueger have continued to lead the effort. Nine INCOSE members were designated to become the Certification Advisory Group. Two of those nine members are INCOSE Fellows, Kevin Forsberg and William Mackey. Goal 5 – Develop an Integrated Process Asset Library (IPAL) for systems engineering. The idea for such an online library arose out of the Education and Research Technical Committee led by Fellow Dennis Buede. Dennis agreed to lead this effort through the System Concept Definition Phase; he also created the structure and developed the online prototype for IPAL. In addition to their work toward these goals, the Fellows also play an active role

in our journal, Systems Engineering. Fellow Andy Sage is the Editor-in-Chief and many of the members of the Editorial Board, who review and edit the articles, are Fellows. Many Fellows also lead working groups, technical committees, and standards efforts: • Anti-Terrorism International Working Group – Jim Long and William Mackey • Intelligent Enterprises Working Group – Jack Ring • Modeling and Simulation Working Group – Sandy Friedenthal • Motor Sports Working Group – William Mackey, Jack Ring and Stan Settles • Public Interest Applications Sector – Scott Jackson • SEANET Mentoring Program – Donna Rhodes • Standards Development – Stuart Arnold, Jerry Lake, and James Martin • Model-based Systems Engineering Grand Challenge 2008, Intelligent Enterprises – Jack Ring • Architecture Concepts, Principles and Terminology Workshop – Jack Ring and James Martin Several new projects are underway: 1. The Chapters Support Project will provide speakers, advice, and assistance to INCOSE local chapters. At least twelve Fellows have agreed to become champions for selected chapters. We are seeking methods to provide speakers remotely for troubled INCOSE chapters no matter where they reside. So far, the following Fellows have agreed to act as local chapter champions: • Erik Aslaksen, Australia • Terry Bahill, Southern Arizona • Sandy Friedenthal, Washington, DC, Metro Area and Chesapeake • George Friedman, Los Angeles • Jeff Grady, San Diego, CA • Rich Harwell, Atlanta • Joe Kasser, United Kingdom • William Mackey, Washington, DC, Metro Area and Chesapeake • Jack Ring, Central Arizona, San Diego and Enchantment (Albuquerque, NM)

INCOSE Foundation

INCOSE Fellows Contribute

continued

• Andy Sage, Washington, DC, Metro Area and Fredericksburg, VA • Scott Jackson, Los Angeles, Houston, and South Africa • Dennis Buede, Fredericksburg, VA 2. The Systems Engineering Vision Implementation Support Project will support the implementation effort of the Vision 2020. At least six INCOSE Fellows have agreed to help with this effort. Fellows have already volunteered to serve as reviewers of symposium papers in the following areas: • Global systems engineering – Scott Jackson • Systems and their nature – Sarah Sheard • Model-based systems engineering – Sandy Friedenthal and William Mackey • Systems engineering processes – Barry Boehm • Education and research – Wolt Fabrycky, Donna Rhodes, Stan Weiss The Kindergarten through Twelfth Grade (K-12) Outreach Project is intended to germinate ideas for reaching students before they go to college. Ideas are already are flowing in for collection and analysis. In short, history demonstrates that most of the INCOSE Fellows continue to contribute and in many cases lead many of the key efforts within the INCOSE Infrastructure. The Fellows have an extensive publication record, have written many of the books that define the systems engineering interdiscipline, and have led the engineering of their countries’ strategic systems engineering initiatives. By the time some Fellows have received this honor, many have retired from systems engineering and integration companies or academia, and they might be expected to reduce their work effort — but few Fellows show any evidence that they are putting on the brakes. It is indeed an honor to be part of this fine group of systems engineers. Thank you, INCOSE Fellows, for your continued leadership and support to INCOSE.

INCOSE Foundation INCOSE Foundation Seeks Applications for Stevens Institute Doctoral Award

T

he INCOSE Foundation, in cooperation with the Stevens Institute of Technology, is soliciting applications for the Doctoral Award for Promising Research in Systems Engineering and Integration. The purpose of this award is to inspire and recognize innovative doctoral-level research related to the field of systems engineering and integration. This award carries a US$5,000 grant to the doctoral student along with a plaque and recognition at the annual INCOSE International Symposium.

Applicants must submit a completed application form, and must have two academic faculty references submit recommendation letters on their behalf. Application and recommendation forms can be downloaded from the INCOSE Foundation Web site at www.incose.org/about/foundation/index.aspx. Completed application forms and faculty references must be received by 15 April. To be eligible, an applicant must be a qualified doctoral student in a degree program with an approved research proposal approved. The applicant must submit an application, and applicants may not receive more than one award. Please contact William Ewald, chief executive officer of the INCOSE Foundation, at [email protected] for further information.

If your enterprise, in performing projects having an engineering content, consistently meets budget and schedule and delights its stakeholders with the products of its work, then our courses are not for you. If there is room for improvement, our courses will provide a strong foundation for achieving improved results. Our courses provide an integrated approach to the set of management and technical disciplines which combine to satisfy requirements, optimize system effectiveness, enhance project and product success, and reduce risk. - Systems Engineering for Technology-Based Projects & Product Developments - Systems Engineering for Defense, Aerospace & Other Technology-Based Sectors - Requirements Analysis & Specification Writing - Requirements Engineering For a free brochure or to find out about our in-house course delivery, visit www.ppi-int.com Turn to Page 45 to see our 2008 USA Public Course Program Project Performance International is a member of the Corporate Advisory Board of INCOSE. PPI joins world-leading companies such as Lockheed, Boeing, BAe Systems, Mitsubishi and others in influencing the future direction of systems engineering. All training courses offered can be tailored to your specific needs and are available for delivery at client and third-party locations worldwide. For further details, course outlines and commendations visit www.ppi-int.com Project Performance International Tel: + 61 3 9876 7345 Tel: 1-888-772-5174 Project Performance International is a trading name of Project

PO Box 2385, Ringwood North, VIC 3134, Australia Fax: + 61 3 9876 2664 Email: [email protected] Fax: 1-888-772-5191 Web: www.ppi-int.com PROJECT PERFORMANCE Performance (Australia) Pty Ltd - ABN 33 055 311 941 INTERNATIONAL

INCOSE INSIGHT

January 2008

43

Requirements ANALYSIS & SPECIFICATION WRITING

LAS VEGAS, UNITED STATES OF AMERICA Course Dates: 25 - 29 August 2008 Course Code: P007 - 240 Course Venue: Clarion Las Vegas, 325 E. Flamingo Road, Las Vegas, NV 89109 Course Fee: USD$2,350.00 (regular fee), USD$2,115.00 (earlybird/group fee) Course Times: 8:30am to 5:00pm daily

Requirements problems are at the top of the list of reasons why projects go wrong. Commercial, military, other government, consultants... users, acquirers, product designers, suppliers. You will learn, in Requirements Analysis, systematic, effective ways to capture and validate requirements to a measurable, appropriate standard. In Specification Writing, a two day module, you will learn how to structure a specification of requirements and how to best express those requirements in natural language (English). Both the Requirements Analysis and Specification Writing modules apply to both products and services. Examples are oriented towards products.

Verification

Verification

Requirements

Requirements

RFT

Need

Verification

Verification

Requirements

Contract

Verification

Requirements

Requirements

Specs

Spec

Specs

Subcontractors Vendors Materials Suppliers Component Suppliers Programmers Manufacturing Integration Test and Acceptance

What people have said about this course: Acquirer/ Acquirer/ Supplier/ Subsystem HWCI/CSCI User Customer Customer Contractor Teams Teams - “Perfect” - delegate, Stellar Solutions, Colorado, USA - “Great course. Thanks” - delegate, Scientific Research Corporation, Washington DC, USA - “My eyes were opened and I am an evangelist for requirements now!” - delegate, Booz.Allen & Hamilton, Las Vegas - “I enjoyed having the analysis create a clear path to a clean, accurate finished product” - delegate, CAE Inc, Denver, USA - “Great course. A lot of great materials, and the handouts and course notes will help me tremendously” - delegate, CAE Inc, Florida, USA - “The material and examples were exactly what I was looking for” - delegate, General Dynamics Amphibious Systems, Washington DC, USA - “The best thing was the ability of the presenter to teach what could be dry material in a fun way” - delegate, Raytheon Technical Services, CA, USA - “The course added some very important fundamental knowledge to my understanding of requirements analysis and how to write a requirements specification” - delegate, Washington DC, USA - “The structure was excellent. I wish I could have taken this course when I started working at ..... I really got a lot out of the entire course” - delegate, United States Air Force Delegates receive a CDROM containing extensive reference resources, including copies of many standards, papers and handbooks.

PPI has joined the corporate advisory board of INCOSE. PPI joins world-leading companies in influencing the direction of systems engineering.

Less 10% Discount for Groups (3 or more registering at the same time) or Earlybird (payment received 30 days prior to the first day of the course)

REGISTRATIONS

PHONE NUMBER

COURSE CODE

NAME

TITLE

FAX NUMBER

COURSE FEE

TOTAL FEES ORGANISATION POSTAL ADDRESS EMAIL

AUTHORISED BY (SIGNATURE) PHONE NO

FAX NO

REGISTRATION FEE

STANDARD

EARLYBIRD

Fees are payable in advance. VAT may apply – please check our website for details, or contact us. Fees include the course, a comprehensive set of course notes, light lunches on all days and morning and afternoon refreshments. Cancellation of registrations must be made in writing for a full refund of fees up to 2 weeks prior to the start of the course. Delegates cancelling after that date are responsible for the full fee. Substitutions of delegates are welcome at any time. Fees are fully refundable should Project Performance International find it necessary to cancel a course. Refund of fees is the full extent of Project Performance International’s liability in these circumstances. Delegates are responsible for their own hotel arrangements, however , special hotel rates may be available – check when registering. Registrations are confirmed upon receipt. Interest is payable on overdue accounts at the rate of 0.08% per day.

"MM
USBJOJOH
DPVSTFT
Pò
FSFE
DBO
CF
UBJMPSFE
UP
ZPVS
TQFDJö
D
OFFET
BOE
BSF
BWBJMBCMF
GPS
EFMJWFSZ
BU
DMJFOU
BOE
UIJSEQBSUZ
MPDBUJPOT
XPSMEXJEF
'PS
GVUIFS
EFUBJMT
DPVSTF
PVUMJOFT
BOE
DPNNFOEBUJPOT
WJTJU
XXXQQJJOUDPN

1SPKFDU
1FSGPSNBODF
*OUFSOBUJPOBM

10
#PY

3JOHXPPE
/PSUI
7*$

"VTUSBMJB 'BY



&NBJM
DPOUBDU!QQJJOUDPN 5FM

1SPKFDU
1FSGPSNBODF
*OUFSOBUJPOBM
JT
B
USBEJOH
OBNF
PG
1SPKFDU
1FSGPSNBODF
"VTUSBMJB
1UZ
-UE

"#/



 PPI-003657-1

44

Volume 11 No. 1

INCOSE INSIGHT

PROJECT PERFORMANCE INTERNATIONAL

SYSTEMS ENGINEERING for Technology-Based Projects & Product Developments Co-named for Defense, Aerospace and Other Technology-Based Sectors A Course Over Five Days - Presented by Mr Robert Halligan, FIE Aust

PPI’s Upcoming Systems Engineering 5-Day Courses in USA Code

Location

Dates

Course Fee

P006-330

Las Vegas, USA

18 - 22 February 2008

P006-335

Las Vegas, USA

28 April - 2 May 2008

USD$2,350 USD$2,350

P006-344

Las Vegas, USA

28 July - 1 August 2008

USD$2,350

P006-355

Las Vegas, USA

8 - 12 December 2008

USD$2,350

Visit www.ppi-int.com for our full course lisiting Commercial, military, other government, consultants ....

CONCEPT OF OPERATIONS

REQUIREMENTS

If your enterprise, in performing projects having an engineering content, consistently meets budget and schedule and delights its stakeholders with the products of its work, then this course is not for you. If there is room for improvement, this course will provide a strong foundation for achieving improved results on technology-based projects. The course, already delivered to over 3000 delegates worldwide, addresses systems engineering as it is understood and practiced in world class organizations (developer, acquirer, and supplier). The course provides an integrated approach to the set of management and technical disciplines which combine to optimize system effectiveness, enhance project and product success, and reduce risk.

HARDWARE

SOFTWARE

FACILITIES

PEOPLE

PROCEDURE

SUPPORT TECHNOLOGY CONCEPT CONSTRAINTS

What people have said about this course: -

“I thought the course was excellent” - delegate, Baker Oil Tools, USA “Good entertaining style that maintained interest” - delegate, Vision Systems, USA “World-class presenter and well organized course material” - delegate, De Beers, Sth Africa “The presenter has seen it all, a thorough professional” - delegate, Tellabs Inc., Chicago, USA “I believe I can use the knowledge gained to perform my job better” - delegate, Las Vegas Company “The coverage of SE topics was very good, even exceeded my expectations. 10/10” - delegate, De Beers, Sth Africa “Robert was brilliant. Very clear and precise delivery, good fun, responsive to class needs” - delegate, Nokia, United Kingdom “Robert Halligan is an excellent instructor who comes across as a strong subject matter expert regarding SE” - delegate, Tellabs Inc., USA “I just wanted to thank you again for the excellent class you provided. It was very enjoyable as well as very informative” - delegate, JT3, USA “This was one of the few courses that has had so much relevance to my work. Apart from meeting my objectives, I have gained considerable insight over the 5-days” - delegate, Tellabs Inc., Chicago, USA

Delegates receive a CDROM containing extensive reference resources, including copies of many standards, papers and handbooks.

PPI has joined the corporate advisory board of INCOSE. PPI joins world-leading companies in influencing the direction of systems engineering.

Less 10% Discount for Groups (3 or more registering at the same time) or Earlybird (payment received 30 days prior to the first day of the course)

REGISTRATIONS

TITLE

COURSE CODE

NAME

PHONE NUMBER

FAX NUMBER

COURSE FEE

TOTAL FEES ORGANIZATION POSTAL ADDRESS AUTHORIZED BY (SIGNATURE)

EMAIL

PHONE NO

FAX NO

REGISTRATION FEE

STANDARD

EARLYBIRD

Fees are payable in advance. VAT may apply – please check our website for details, or contact us. Fees include the course, a comprehensive set of course notes, light lunches on all days and morning and afternoon refreshments. Cancellation of registrations must be made in writing for a full refund of fees up to 2 weeks prior to the start of the course. Delegates cancelling after that date are responsible for the full fee. Substitutions of delegates are welcome at any time. Fees are fully refundable should Project Performance International find it necessary to cancel a course. Refund of fees is the full extent of Project Performance International’s liability in these circumstances. Delegates are responsible for their own hotel arrangements, however , special hotel rates may be available – check when registering. Registrations are confirmed upon receipt. Interest is payable on overdue accounts at the rate of 0.08% per day.

"MM
USBJOJOH
DPVSTFT
Pò
FSFE
DBO
CF
UBJMPSFE
UP
ZPVS
TQFDJö
D
OFFET
BOE
BSF
BWBJMBCMF
GPS
EFMJWFSZ
BU
DMJFOU
BOE
UIJSEQBSUZ
MPDBUJPOT
XPSMEXJEF
'PS
GVUIFS
EFUBJMT
DPVSTF
PVUMJOFT
BOE
DPNNFOEBUJPOT
WJTJU
XXXQQJJOUDPN

1SPKFDU
1FSGPSNBODF
*OUFSOBUJPOBM

10
#PY

3JOHXPPE
/PSUI
7*$

"VTUSBMJB 'BY



&NBJM
DPOUBDU!QQJJOUDPN 5FM

1SPKFDU
1FSGPSNBODF
*OUFSOBUJPOBM
JT
B
USBEJOH
OBNF
PG
1SPKFDU
1FSGPSNBODF
"VTUSBMJB
1UZ
-UE

"#/



 PPI-003656-1

PROJECT PERFORMANCE INTERNATIONAL

INCOSE INSIGHT

January 2008

45

Technical Directions

Technical Directions From the Technical Director Samantha Brown, [email protected]

T

his past October was a beautiful month in the United Kingdom. Having started the month in Canada at the Board of Directors meeting just as the colours were starting to appear on the trees, I returned to the U.K. for some home-grown autumn (or fall, if you prefer) colour. It truly was magnificent, although perhaps not quite up to North American standards. It got me thinking. Was I just more aware of the colours now? No, because reports on TV and radio had noticed, too. So why, then? Was it the weather — unusually dry, plenty of sunshine and little wind? If so, which had the greater effect? Had the lack of rain meant that we had avoided the typically soggy time of year when “leaves on the line” have become the standard excuse for the late arrival of any train? Or had the lack of wind just meant that the leaves had stayed on the trees for long enough to develop brighter colours? And, since I accept that the colours on the other side of the Atlantic are still more dramatic, why is that? Is it the weather, the soil, the species of trees? Engineers don’t need to be told that science is all around us, and most of us have at least a passing interest, even in the areas of science that we don’t understand. Regular readers may note that this is not the first time that plants have crept into this column. My interest is as a gardener, however — certainly not as a botanist. But not really understanding the science doesn’t diminish its value. Systems science is a vitally important area for systems engineers. We face the continuous criticism that systems engineering isn’t a “real” discipline, that it lacks a “scientific” foundation. We lack equations and experimental proofs, an absolute failing in the eyes of other engineers. It might appear that, driven by industrial need, “trial 46

Volume 11 No. 1

INCOSE INSIGHT

and error” advancements in industrial application have developed in advance of the scientific discipline of systems engineering. This sort of problem is not new, and has strong parallels to the development of steam engines and the science of thermodynamics during the eighteenth and nineteenth centuries. Newcomen invented the first modern steam engine in 1712, seventy-five years before the work of Charles and the first Gas Law. The first locomotive ran in 1802, fifty years before the first and second laws of thermodynamics were established. In these cases, and for systems engineering, industrial need drove the advance — but to sustain progress the science had to follow. And yet there are areas of science that can help us to explore and to tackle our more complex problems. They do not form a coherent body of work, and some (heaven forbid) come from the social sciences. Many are contradictory. If you find that unacceptable, remember that the European “discovery” of America came from a desire to prove the world was round when others still believed it to be flat. Contradiction merely highlights those areas where further research is known to be needed. INCOSE has embraced systems science — both within our own organisation and in working with others — in recognition of the importance of the science to the continuing development of systems engineering. This issue of INSIGHT has contributions from some of our systems science community who are engaged in trying to bridge that gap between what we do and why. For the practitioner, this is not always an easy (or even an apparently necessary) step: those who are relatively new to the subject might find Peter Checkland’s thoughtprovoking account of the histories of

science and systems in Systems Thinking, Systems Practice (Chichester, U.K.: Wiley, 1981) a useful start point. As for the trees, of course the colour was the product of a particular set of circumstances coming together at a particular time. Now that time has passed, the exact effect can never be reproduced, as is the case with any truly complex system. But just a little understanding of the botanical science gives us an insight into the conditions that help to produce a perfect autumn backdrop. Likewise, I commend this edition of INSIGHT — and the work of systems scientists in general—to all systems engineers, not as a quest for great personal expertise in the subject, but just to understand a little more about the world around us, and the systems that we seek to engineer.

Renew Your Membership Today! Benefits of Membership Network with 7,000+ SE professionals in 35 countries • Quarterly publication, INSIGHT • Systems Engineering, the journal of INCOSE • Contribute and collaborate through INCOSE technical committees • Lowest prices on INCOSE publications • Exclusive access to the Members’ Only area on our Web site • Membership directory •

INCOSE Events

INCOSE Events

4  I t ' s

not too early to mark your calendar for the 18th Annual International Symposium in 2008! For more information: www.incose.org/symp2008

Could You Say That Again Please? Cecilia Haskins, [email protected]

B

y now, most readers know that the chapters of Region III will host the next INCOSE annual symposium in Utrecht in the Netherlands. Since we always stress the linguistic prowess of the citizens of the host country, it is easy to forget that English is the native language of only one country in this

region. Samantha Brown suggested the very interesting idea that we include articles in INSIGHT in languages other than English. So rather than overwhelm you with “advertising” appeals for the symposium, members from our chapters have chosen instead to introduce their chapters to you in this and upcoming

!"#$%& '()#*+, '-./, #0'" INCOSE_IL ,!"#$ ,%&&'(()* $)+,&-" $"+

issues of INSIGHT — in their native languages, with English translation close at hand. I am pleased to present the first four introductions in this issue, from Israel, Norway, South Africa, and our host country, the Netherlands. Welcome to our world!

The Challenge of Systems Engineering in Israel Avigdor Zonnenshain, [email protected]

,%)./&-0 1)&'21- !"$'&- 1.1#13 1)4$23 15+(0 123/0 &63"3 '& 1)()$."0 7&('- .!!.0) 0#)210 )34 1)#5)( 1)&'21- 7, 1)4$23 15+(0 1)&,)!)+)13 &&0 ,0&68&()3)8!/-.1)(/8 1)$-.- %4) 8/

Systems engineering is gaining momentum in the Israeli defense and aerospace industries. Efforts have been made in the past few years to implement systems engineering methodologies in other industries, such as telecommunications, hi-tech, and small and medium enterprises.

5+(03 1$'40 1(&)630 1&(41- 13&&813 14$23 & - 7&435)3 )- ,ME $")1! %)&(4/-- &5+(03 100 &5+(03 1$'40 126)-3 %4 )34 .0(' !4 14$23 .1)$-.0 9)1- 14$23

Systems engineers are trained under the excellent post-graduate systems engineering program offered by the Technion, with some one hundred systems engineering graduates yearly. Other systems engineers are trained by their own organizations.

INCOSE_IL 2+& +8)34 1)()$."0 7&('- '3'3 2+&) 2+&3 &#)1&' $6)&) 1)4$23 15+(0! %)&5&() ,%)&2 &3& ,7&5(4 &"2 1)4$23 15+(0- ,7&$(&35 &2)683 %)1&2 ,0+)-2 1)6)-8 ,7&&2)683 7&$)8&.$.")

INCOSE-IL is the hub of systems engineering know-how and experience, generating and sharing information and knowledge through conferences, technical meetings, seminars, work groups, professional journals, and a Web site.

123/0 ")0 !"$'&- 1)4$23 15+(0 !' $,1"0 123/0 ,7&8520) 1)$-.0 &,)5 !4- 1)4$23 15+(0 7&$8.3 7)*&&) $&260 $)+0 -$8- 1)&14$230 1)'&,0 .1)*&$*) 1)&($+)3 1)&14$23 1)'&, $)1&"! 7&&14$23

The challenge of systems engineering in Israel is to disseminate systems engineering into companies and businesses of all types, to impart knowledge about the systems approach to the younger generation and to initiate research in the quest for modern and agile systems approaches.

> continues on next page INCOSE INSIGHT

January 2008

47

INCOSE Events

Introduksjon til NORSEC

Introduction to NORSEC

Odd Andreas Asbjørnsen (1929-1999)

Odd Andreas Asbjørnsen (1929-1999) Translated by Terje Fossnes, [email protected]

Norsk råd for systemteknikk, eller NORwegian Systems Engineering Council (NORSEC), er den norske avdelingen av INternational Council On Systems Engineering (INCOSE). Formålet med organisasjonen er å fremme bruken av systemteknikk (systems engineering) og spre kunnskap om systemteknikkens prinsipper. Systemteknikk har bred anvendelse og samler tekniske og humanistiske fag fra ulike områder i næringsliv og forvaltning. NORSEC har i dag medlemmer fra universitets- og høyskolemiljøet, norsk næringsliv og Forsvaret.

The Norwegian Systems Engineering Council (NORSEC) is the Norwegian chapter of INCOSE. The goal of the organization is to promote the use of systems engineering and to disseminate knowledge about systems engineering principles. Systems engineering has broad applicability and brings together theory from both science and the humanities, and practices from various areas of industry and research. NORSEC members come from academia, industry and government.

NORSEC vil kunne få en meget stor betydning ved sin holdning til utdanningspolitikk slik at systemtenkning og systemteknikk blir integrerte deler av de forskjellige disipliner — på deres premisser. System-teknikk kommer derfor ikke til fortrengsel eller erstatning for en solid faglig spesialutdannelse. En god industriell forståelse og anvendelse av systemteknikken som disiplin, og som metode, vil kunne spare næringslivet for betydelige summer. Dette oppnås først og fremst ved en reduksjon av feil og senere omarbeidelse ved en nøye gjennomtenkning og bearbeiding av behov, krav og ytelser i en tidlig fase av systemenes livsløp, der grunnlaget blir lagt.

A driving objective of NORSEC is to influence the educational policy of Norway to recognize that systems thinking and systems engineering should be an integrated part of different disciplines and their underlying foundations. Systems engineering is not intended to replace or substitute for a solid education in other disciplines. Furthermore, a good understanding and industrial application of systems engineering as a discipline and a methodology will help firms save money. This will be achieved primarily with a reduction in errors and rework, and with a thorough analysis of needs, requirements, and performance in the earliest phases of the system life cycle, where the decisions with the most impact are made.

Utdannelse i systemteknikk gjennomføres ved Norges TekniskNaturvitenskapelige Universitet. Høyskoken i Buskerud tilbyr også Master i Systems Engineering i samarbeid med Stevens Institute of Technology.

Courses in systems engineering are available at the Norwegian University of Science and Technology (NTNU). The Buskerud University College also offers a master’s degree in systems engineering in cooperation with Stevens Institute of Technology.

NORSEC har sitt ti-års jubelium i 2008.

NORSEC celebrates ten years as a chapter in 2008.

INCOSE in Suid-Afrika

INCOSE in South Africa

Alwyn Smit, [email protected]

Alwyn Smit, [email protected]

Die geskiedenis van stelselingenieurswese in Suid-Afrika is baie soortgelyk aan díe van meeste ander lande. Gedurende die 1970s en 1980s het die militêre nywerheid beduidende resultate met stelselingenieurswese behaal, en wel met die ontwikkeling van gedugte wapenstelsels. Gedurende die 1990s het die regering se prioriteite dramaties verander, en het die militêre nywerheid se belangrikheid afgeneem. Die militêre nywerheid het egter daarin geslaag om op beduidend kleiner skaal tog lewensvatbaar te bly deur byvoorbeeld strategiese vennootskappe met buitelandse firmas aan te gaan en deur as subkontrakteur vir hulle op te tree.

The history of systems engineering in South Africa is very similar to that in most other countries. In the 1970s and 80s the defense industry achieved significant systems engineering results. During the 1990s, the government’s priorities changed dramatically, and as a result, the military industry’s importance diminished. However, the military industry succeeded in remaining viable on a substantially smaller scale by entering into strategic partnerships with overseas companies and by becoming their subcontractors.

Gedurende die laaste dekade het die regering begin om die ontwikkeling van ’n nuwe generasie inherent veilige siviele kernreaktor te ondersteun. Die ontwikkeling van ’n demonstrasie kragstasie, gebaseer op die sogenaamde “pebble bed modular reactor”, is vandag een van die grootste ingenieursprojekte in Suid-Afrika en absorbeer ’n groot deel van al ons

During the last decade, the government started supporting the development of a new-generation civilian nuclear reactor that would be inherently safe. The development of a demonstration power plant, based on the so-called “pebble bed modular reactor,” is one of the largest engineering projects in South Africa today and keeps a large number of our systems engineers > continues opposite

48

Volume 11 No. 1

INCOSE INSIGHT

INCOSE Events

INCOSE in Suid-Afrika

INCOSE in South Africa

stelselingenieurs. Stelselingenieurwese word ook elders benut, byvoorbeeld in die ontwikkeling van die Suid-Afrikaanse tegnologie demonstrator van die sogenaamde Square Kilometer Array radioteleskoop, wat as die Karroo Array Telescope bekend staan. Ander voorbeelde is die ontwikkeling van nuwe myne en die uitbreiding van Suid-Afrika se infrastruktuur.

employed. Systems engineering is also used elsewhere, for instance, in the development of the South African technology demonstrator of the so-called Square Kilometer Array radio telescope, known as the Karroo Array Telescope. Other examples are the development of new mines and the expansion of South Africa’s infrastructure.

Die plaaslike INCOSE tak is in 2002 gestig, het tans ongeveer 170 lede, reël soortgelyke aktiwiteite en ervaar dieselfde tipe probleme as meeste ander takke.

The local chapter of INCOSE was established in 2002, currently has about one hundred seventy members, arranges similar activities, and experiences similar types of problems as most other chapters.

Systems Engineering op zijn Nederlands

Systems Engineering the Dutch Way

Bram de Landtsheer, [email protected]; en Hans Hadderingh, [email protected]

Bram de Landtsheer, [email protected]; and Hans Hadderingh, [email protected]

Nederland heeft een actief chapter dat behoorlijk aan de weg timmert. Nationaal zijn essentiële bijdragen geleverd aan de introductie van SE in de weg- en waterbouw. Het gebruik van SE is mede daardoor verplicht bij veel aanbestedingen. Dit is onder andere bereikt door onze werkgroepen die actief zijn op het gebied van de implementatie van SE, SE in onderwijs en Embedded Systems.

The Dutch have a very active chapter. On the national level one of our working groups contributed substantially to the introduction of systems engineering in the civil engineering domain. This resulted in the mandatory use of systems engineering in most public tenders. Other working groups deal with the implementation of systems engineering, systems engineering and education, and embedded systems.

Ook internationaal levert ons chapter belangrijke bijdragen aan INCOSE. Meest opvallend is de organisatie van IS2008, samen met andere chapters van Regio III. Verder heeft het bijgedragen aan IS2004 en de regionale symposia in Edinburg en Munchen. Tevens heeft ons chapter vertegenwoordigers in de Events Committee, de Commercial Steering Board en het Technical Leadership Team. En een van onze ex-voorzitters is kandidaat voor INCOSE president-elect.

Our international contribution to the INCOSE community consists of organizing the next international symposium and concurrently the Sixth Biennial European Systems Engineering Conference in close collaboration with other Region III chapters. Moreover, the chapter has representatives in the Events Committee, the Commercial Steering Board, and the Technical Leadership Team. One of our past presidents was also a recent candidate for INCOSE president-elect.

Samengevat, een actief chapter dat iedere maand een goed bezochte bijeenkomst heeft. We organiseren een paar maal per jaar workshops en bedrijfsbezoeken en voor onze sponsoren is er de Corporate Advisory Board.

Our chapter organizes well-received monthly meetings, workshops, and company visits once or twice a year. We meet our sponsors in the Corporate Advisory Board on a regular schedule.

Kortom, het lijkt bijna perfect. Blijft er dan niets te wensen over? Jazeker, we hebben duidelijk last van groeistuipen (inmiddels bijna 500 leden). Hoe behouden we het goede van een kleine club enthousiastelingen in een grote, meer professionele organisatie.

It looks almost too good to be true! Indeed, there are improvements possible. The chapter is growing quickly (almost five hundred members). What originally began as a small club of enthusiasts has evolved into a large, more professional organization.

We hopen u allen te mogen begroeten in Utrecht tijdens IS2008 (15-18 Juni 2008).

We look forward to welcoming all of you to Utrecht for IS2008 (15-19 June 2008).

INCOSE INSIGHT

January 2008

49

Book Review

Book Review System Analysis, Design, and Development Concepts, Principles, and Practices By Charles S. Wasson

Hoboken: John Wiley & Sons, 2006 (ISBN-10: 0-47139339 and ISBN-13: 978-0471393337) Reviewed by Robert D. Jones, [email protected]

T

his is the best over-all text on the subject of systems engineering I have encountered in more than fifty years. I would unhesitatingly recommend it for use in undergraduate or graduate courses. Those who know me will be shocked to read those two sentences: they will remember that I have long thought that the old version of the Defense System Management College text on this general subject was the best treatment I had ever seen. I was somewhat surprised myself when the quality and content of Mr. Wasson’s book changed my opinion. The author has composed a logicallyarranged, clearly-stated compendium

of the practical information one needs to recognize, understand, and perform as a systems engineer. That can be said of many texts, however, but there are a number of elements that set the book apart from all the others I have read on this subject. First, the author has adopted a pattern that dramatically enhances the learning opportunity for readers at virtually all levels of experience. Beginning with an introduction that describes the language and conventions used, with specific examples to aid comprehension, he proceeds to a description of the general and organizational exercises designed to illustrate points and applicable in the organizational, classroom,

and individual study environments. Then he methodically leads the reader step by step through all the elements listed in the book’s title. Charles Wasson organizes each chapter to enhance the reader’s learning experience. He introduces each topic in a relatively short paragraph. Then he explicitly informs the reader of what he intends to communicate in the chapter by providing a straightforward list of learning objectives; definitions follow. These definitions are extremely important because effective communication depends so heavily on everyone involved sharing a common understanding of the words they are using. The definitions include the author’s perspective as well as alternatives that the reader may already be familiar with or may encounter in the future in the course of doing business. > continues opposite

Final Thoughts From the Chief Editor Bob Kenley, [email protected]

Issue

I

n a previous INSIGHT (vol. 10, no. 2), I wrote about the signs of spring outside my office window. Today, I see the signs of winter. A woman who lives across the street is shoveling snow from her driveway, and in the distance, I hear sounds of children playing in the snow. I do not want to pass any judgement on the woman across the street, but I do know that even though there are children who are part of her family system, I do not see any of the children, who are quite expert at riding skateboards and playing basketball, participating in the snow removal subsystem. I hope to understand why this is so after reading the articles on

50

Upcoming submission deadlines and themes for INSIGHT

Volume 11 No. 1

INCOSE INSIGHT

Submission Date Theme

Theme Editor

2nd Qtr 2008 15 Feb 2008

Integrating the Human in Every System

Mike Mueller and Steve Deal

3rd Qtr 2008

15 May 2008

The Best of France: Forum Académique et Robafis

Hervé Panetto

4th Qtr 2008

3 July 2008*

Systems Engineering for the Planet: International Symposium 2008 Highlights

Cecilia Haskins

1st Qtr 2009

15 Nov 2008

Space Systems: Navigating Complexity to Explore the Unknown

Jim Andary

Cognition: Pursuing the Next Level in System Performance

Steve Deal

2nd Qtr 2009 15 Feb 2009 *early submission deadline

integrating the human in every system that will appear in the next edition of INSIGHT. Theme editors Mike Mueller and Steve Deal have articles lined up

for this edition, but if you do have an article that answers my question, please submit it to them by 15 February for their consideration.

Book Review

Book Review

continued

The book’s construction shows that the author has carefully considered his reader. Each chapter is comprehensive and presented in the same general organizational pattern. At no time does the author talk down to the reader. The primary text in each chapter is followed by a summary paragraph, general exercises, organizational exercises, references, and citations additional reading material. It would be difficult to provide a better-organized, better researched book. It would be nearly impossible to improve on the author’s communication techniques or to make the book an easier read. While this book would serve extremely well in the classic role as a university text, it has the added advantage of having been written at the practical level. Having taught at four universities and reviewed a fair number of potential systems engineering textbooks, I have come to believe that producing a competent text is much easier than doing what this author has accomplished. He has produced a book that, in my opinion, should reside on the desk of every one who claims to practice “systems analysis, design and development”—in other words, systems engineering. It would directly enhance the every-day practice of the discipline in that role and serve easily as a daily-use systems engineering handbook. I cannot think of many college texts that could fill that role, and that is what makes this book unique. This book will prove to be a seminal text on systems engineering. I thoroughly enjoyed reading the book — and I am really not too fond of reading texts covering material that I have been using in practice for half a century. Besides, I truly learned something from almost every chapter, even when the author and I might disagree in terms of emphasis or focus. Mr. Wasson exposed me to some new concepts and helped me to look at old concepts in a new light — always a valuable experience. I am quite sure that every INCOSE member who is fortunate enough to obtain a copy of this book will find that it will help improve your daily practice of systems engineering.

10th Anniversary! Scandinavian

Summer School Week Sweden, 10-15 August 2008 Three courses offered in parallel:

 Systems Engineering Fundamentals  System Architecture and Design Logistics Engineering Management  The Scandinavian Summer School Week is a truly unique and intense learning exercise held annually. This year we celebrate the 10th anniversary of this event! The successful concept combines theory and practice, hard work and social activities in an inspiring environment. The week features internationally recognized lecturers and participants from industrial sectors such as aerospace, automotive, defence, telecom, transport and utilities. For more information and registration:

www.syntell.se [email protected] Syntell AB, PO Box 100 22, SE-100 55 Stockholm, Sweden. Tel +46(0)8 660 0280, Fax +46(0)8 660 0965

T ECHNOLOGY

IN

S UPPORT

OF

N ATIONAL S ECURITY

MIT Lincoln Laboratory is a premier employer applying science and advanced technology to critical, real-world problems of national interest.

Mission Assurance Quality Manager and Hardware Engineer We are seeking candidates who can perform mission assurance for MIT Lincoln Laboratory in support of complex space and missile defense projects. Work will involve ensuring that critical quality and engineering processes are established throughout the Laboratory. Must have experience with performing quality engineering and inspections in a test and fabrication environment and have the ability to perform safety and reliability analysis, such as hazard assessment, fault tree development and failure modes and effects analysis. Must have experience with spacecraft and/or electronic systems. Quality Manager will develop mission assurance infrastructure to establish safety and reliability methods, project management techniques, and system engineering tools. Will also provide matrixed support to select projects for mission assurance. Requirements: MS or PhD in Aerospace Engineering, Mechanical Engineering, Electrical Engineering, Industrial Engineering or Physics with 7+ years of experience. Experience with establishing, maintain, and complying with quality systems, such as AS9100, in a test and fabrication environment. Certification as an AS9100 internal auditor is desired. Hardware Engineer will work with projects to ensure that appropriate requirements are applied and are followed throughout the development of the project. Will work actively with the many organizations and projects in the Laboratory in order to establish, maintain and improve processes and procedures, as well as supporting specific projects to ensure their success. Requirements: PhD or MS in Electrical Engineering, Physics, Systems Engineering, Safety Engineering or Operations Research with at least 7 years of experience. Experience with project management is required, as is experience with applying systems engineering tools and techniques throughout the life cycle of a project. Please apply online at: http://www.ll.mit.edu/careers/careers.html. Lincoln Laboratory is an Equal Opportunity Employer. M/F/D/V - U.S. Citizenship required.

INCOSE INSIGHT

January 2008

51

Systems Engineering: The Journal of The International Council on Systems Engineering

Call for Papers The Systems Engineering journal is intended to be a primary source of multidisciplinary information for the systems engineering and management of products and services, and processes of all types. Systems engineering activities involve the technologies and system management approaches needed for: • definition of systems, including identification of user requirements and technological specifications; • development of systems, including conceptual architectures, tradeoff of design concepts, configuration management during system development, integration of new systems with legacy systems, integrated product and process development; and • deployment of systems, including operational test and evaluation, maintenance over an extended lifecycle, and re-engineering. Systems Engineering is the archival journal of, and exists to serve the following objectives of, the International Council on Systems Engineering (INCOSE): • To provide a focal point for dissemination of systems engineering knowledge • To promote collaboration in systems engineering education and research • To encourage and assure establishment of professional standards for integrity in the practice of systems engineering • To improve the professional status of all those engaged in the practice of systems engineering • To encourage governmental and industrial support for research and educational programs that will improve the systems engineering process and its practice The journal supports these goals by providing a continuing, respected publication of peerreviewed results from research and development in the area of systems engineering. Systems engineering is defined broadly in this context as an interdisciplinary approach and means to enable the realization of successful systems that are of high quality, cost-effective, and trustworthy in meeting customer requirements.

52

Volume 11 No. 1

INCOSE INSIGHT

The Systems Engineering journal is dedicated to all aspects of the engineering of systems: technical, management, economic, and social. It focuses on the life cycle processes needed to create trustworthy and high quality systems. It will also emphasize the systems management efforts needed to define, develop, and deploy trustworthy and high quality processes for the production of systems. Within this, Systems Engineering is especially concerned with evaluation of the efficiency and effectiveness of systems management, technical direction, and integration of systems. Systems Engineering is also very concerned with the engineering of systems that support sustainable development. Modern systems, including both products and services, are often very knowledge intensive, and are found in both the public and private sectors. The journal emphasizes strategic and program management of these, and the information and knowledge base for knowledge principles, knowledge practices, and knowledge perspectives for the engineering of systems. Definitive case studies involving systems engineering practice are especially welcome. The journal is a primary source of information for the systems engineering of products and services that are generally large in scale, scope, and complexity. Systems Engineering will be especially concerned with processor product-line – related efforts needed to produce products that are trustworthy and of high quality, and that are cost effective in meeting user needs. A major component of this is system cost and operational effectiveness determination, and the development of processes that assure products that are cost effective. This requires the integration of a number of engineering disciplines necessary for the definition, development, and deployment of complex systems. It also requires attention to the lifecycle process used to produce systems, and the integration of systems, including legacy systems, at various architectural levels. In addition, appropriate systems management of information and knowledge across technologies, organizations, and environments is also needed to insure a sustainable world.

The journal will accept and review submissions in English from any author, in any global locality, whether or not the author is an INCOSE member. A body of international peers will review all submissions, with potential author revisions as recommended by reviewers, with the intent to achieve published papers that • relate to the field of systems engineering; • represent new, previously unpublished work; • advance the state of knowledge of the field; and • conform to a high standard of scholarly presentation. Editorial selection of works for publication will be made based on content, without regard to the stature of the authors. Selections will include a wide variety of international works, recognizing and supporting the essential breadth and universality of the field. Final selection of papers for publication, and the form of publication, shall rest with the Editor. Submission of quality papers for review is strongly encouraged. The review process is estimated to take three months, occasionally longer for hard copy manuscript. Five copies of your manuscript should be submitted for review purposes to Professor Andrew P. Sage Editor in Chief, Systems Engineering School of Information Technology and Engineering George Mason University Fairfax, VA 22039-4444, USA TEL: 703-993-1506 FAX: 703-993-1521 E-MAIL: [email protected] Alternatively and preferably, electronic submission of manuscripts for review purposes is strongly encouraged, as this will speed up the review process considerably. Please send a copy of your complete manuscript in a single file with art and tables in approximately the proper location to [email protected].

Make Your Move!

Get the recognition you deserve for your Systems Engineering experience and knowledge through the INCOSE Certification Program! Become a

today.

Visit www.incose.org and click on the CSEP icon INCOSE INSIGHT

January 2008

53

INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING 2150 N. 107th St., Suite 205 Seattle, WA 98133-9009 (USA) TEL: (206) 361-6607 OR (800) 366-1164 FAX : (206) 367-8777 E- MAIL: [email protected] WEBSITE : www.incose.org

Individual Membership Application

FOR NEW MEMBERSHIPS

1. Membership Type Please circle the amount remitted

01/08

ÜÚI]\m[]\Úe]eZ]jk`ahÚ]flald]kÚl`]Úe]eZ]jÚlgÚkg^lÚ[ghqÚgfdqÚ^gjÚThe SE JournalÚYf\ÚINSIGHT.Ú ÜÚGd]Yk]Úk]]Úl`]Ú@E:FJ