Systems of Systems (SoS) Engineering: a view from the inside looking out

"#$#!%&'(&')&*+,!-!.#/#!%&)+01&2! 34*5,6424*5,!7)&8'29&:;<!7=!
! "4>;2&5,:!?!@AB@!6;!"#$#!%&'(&')*+,!!-!.#/#!%&)+01&2#!!C*60&9,'D!1)D!*9'D!6;!EF"G%$!H&:,!>'2(&99&4)#!

Abstract. The paper provides a human factors based perspective on System of Systems Engineering (SoSE), different to that usually encountered in the military and civilian arenas. This reflects the evident fact that the vast majority of System of Systems (SoS) are created, configured, controlled, supervised, maintained, upgraded and decommissioned by humans. The paper commences by outlining what an SoS feels like from the inside, and then goes on to outline a selection of issues of importance to SoS engineering and performance stated from a human factors perspective. These include tipping points, incomplete knowledge, SoS immortality, complexity, and the importance of trustworthy behaviour within the SoS. Some design approaches to address these issues are then outlined.

It is an interesting fact that when we define a system boundary, we typically exclude the overall infrastructure on which the system depends, or, if we do take it into account, we often assume it is constant and unchanging. Yet when one looks at the usual set of interfaces that a system has with its external environment, as shown in figure 1, this could be merely a convenience rather than a correct view; most times, we should engineer an individual System of Interest (SoI) from the perspective of its accommodating System-of-Systems (SoS).

The most important aspect of this was captured 2,500 years ago, by (Heracleitus 535 - 475 BCE) ‘You cannot step in the same river twice’, said he (more colloquially, ‘nothing stays the same’); the expected operational lifetime of the SoI will determine how important it is to consider the wider SoS in which the SoI is embedded. When one considers the range of SoS that, in various instantiations, have become critical to the operations of our societies and therefore, of necessity, immortal (examples are energy supply grids, transport, national security systems, national health care, public education and so on), the expectation that none of the component systems and the SoS environment can or will remain the same becomes fundamental.

On shorter timescales, there is still much pressure for change, too: for many instantiations of SoS the mantra ‘Faster, Better, Cheaper’ has strong effect. For example, in automotive manufacturing systems, it has long been an expectation that costs will drop by 3% per annum (Touche 2003), funded by greater efficiencies within the system and by reduced waste, ! !

4)D!:. usually with the effect of removing resilience from the primary function(s) of the system. Which is where. in the orthodox systems engineering paradigm. 1 Representation of a system-of-interest. it is true no longer. All of them imply another system must exist to which to interface. This may have been acceptable in the past. Jamshidi ! ! . This means that there is. development and operation of SoS have some differences to systems design. ! ! ! Fig. Legally.particularly of time. considerable human involvement in these SoS. supervision. the increasing requirement for interoperability and the pervasion of these into our societies. Humans will remain involved in strategy and policy. which in turn requires that all the complexities. Dahmann and Baldwin 2008. The result is an incremental stream of changes to the system. unexpected events. explaining and fixing the incivilities of various SoS in their interactions with the rest of humanity. and will be. Jamshidi 2009. monitoring and control. and disturbances of real life have to be addressed at the defined system boundaries and interfaces. albeit there may be contractual and other arrangements between the organisations or enterprises owning the systems (Maier 1998. and because they are still the only agents capable in moral authority and responsibility.'!64*)D12. Fisher 2006. development and change. maintenance and logistical functions. design.<!1)D! we can ignore them. and it will not have escaped our attention that armies of people are involved in Call Centres. humans are still responsible for the performance and behaviour of these SoS. By definition. ! But the design. we decide that stability lies in the systems!6'. to show a number of the external interfaces of the system. SoS comprise federations of systems. but with the growth of networks of interdependent systems around the globe. due to human capabilities in the application of knowledge and wisdom. from a human factors perspective. This can only work well in a stable process environment. where there is operational and managerial independence of individual systems within the SoS.

made with materials yet to be invented. with the attendant management issues. which captures well how many managers and other professionals in SoS environments experience their work: ! ! . There is a well-hidden ancilliary to these quotations. involving products we have not yet identified. CEO Intel Corporation. Otellini. in support of the assertions above. In the rest of this paper. Which brings us nicely to the next quotation. with money we are trying to earn now. there must be collaboration with people in other organizations to bring about a future SoS that is successful. 2008) The second is a compilation of comments generated by the authors from several senior managers in the automotive industry. expanding on the Intel version above: “In fifty years’ time. This will be accomplished by people we have not yet recruited. As these authors have pointed out. if an organization is involved in a SoS. to run products we haven't designed yet. these quotations highlight two things. with the implication that the organization will have to manage a portfolio of involvements on a range of SoS. which takes three years. it is likely that it will be involved in other SoS in parallel. We present three examples below. spend three billion dollars to build a factory in it.” Taken together. many human-centred. CES Las Vegas. firstly that that wisdom. for markets which don't exist. and all of which will be different by then. organisational systems are often heavily involved#! A view from inside an SoS What tends to be missing from discussions of SoS is the ‘view from the inside’. with processes we have yet to develop." (P.2009). some of whom will cease to exist. We do that two or three times a year. and secondly that given the uncertainties. The first is from Intel: "Our business model is one of very high risk: We dig a very big hole in the ground. We will do this in partnership with suppliers. to produce technology we haven't invented yet. we discuss a few of the human-related issues in the engineering of SoS. BBC News. it is at the SoS interfaces where SoSE has its major effects. how humans within the SoS understand what it is that these SoS do. we will be delivering services to customers we do not know now. it should be remembered that not all systems in a SoS are IT-centric. knowledge and experience is the most valuable commodity to carry forwards into the future.

. unexpected visitors.) This last quotation highlights the significance of time. . Cooperrider. The unspeakable texture of process wisdom. . of course. Furthermore. preferably at the interfaces. it also embraces the point made earlier.. as in some large electricity grid failures (Andersson. One aspect lurking within the dynamics of SoS is the problem of ‘tipping points’ (Repenning. And time was not a matter of merely academic interest. and resistances to being sidetracked by other people's temporal perceptions and! priorities. 2 below. One reason for these is quite subtle. . there was nothing I could do. 2001. an unfortunate temporal concatenation of events across an SoS may cause widespread failures. by people living his kind of professional life. (1998). if his academic institution would deliver a smooth. S. summons from top administrators. heaven forbid.. long-winded faculty members. I learned sometimes painfully. Tipping points. expectations of the rates at which things ought to proceed. or. I simply had to learn to understand myself in a spatio-temporal field of relationships. The multiple time streams were. then all the disturbances to this must be handled elsewhere. Donalek et al. they competed for my attention. P. San Francisco. The calendar was filled with contingencies. there was the problem of the intrusiveness of events: things did not occur one at a time.. Frequently there were three or four places where I was supposed to be at virtually the same time. Rudolph and Repenning 2002) where operations of parts of an SoS descend inexorably into a state of near-chaos. at any moment I was flowing with the multiple... Jossey-Bass: 25-39. Goncalves et al. flowing and shifting. beginnings and endings. disjointed time streams of the various projects in which I was involved. that did not have its own rhythms and pacings. pauses and accelerations. It was a field of multiple players. 2005). for this paper. L. Srivastva and D. it was central to whether I got anything done at all. Another version of this is organisational. as is typical in many SoS. we discuss a few of the more pervasive ones before presenting possible solutions for consideration. any of those ills of the flesh and the psyche that accompany the manager's harried life." (Vaill. Relevant human/organizational issues within SoS There are many of these. and of the intrusion of events. no competence could be practiced in pristine singularity. especially for SoSs that exhibit close-coupling. not co-ordinated in space. each of whom had his or her own schedules."For example. Indirectly. but there was usually little margin for such 'errors' as delayed planes. Organizational wisdom and executive courage. Instead. B. from (Gover 1993) ! ! . consider fig. I (and even more my secretary) tried heroically to keep some harmony in this overscheduled life. Everything was interactive. efficient learning process for its students.

and ways of working will collide at the interfaces. Combined. Hence. these are likely to produce a significant tipping point into possible financial or operational failure with all the attendant dangers this may present to the SoS owners. It will be obvious that the occurrence and effects of these tipping points will be exacerbated by delays. we may expect different organisational structures. because a Japanese manufacturer of 70% of the world’s supply of polyvinylidene fluoride used in making lithium-ion batteries was incapacitated by the 2011 tsunami (leMerle 2011). policies. policy.! Fig. Other well-known examples include the disruption to the Toyota. including both delays and concatenated changes. operations and transactions. Emergent behaviour is likely. as Vaill has hinted above. ! ! . stakeholders or the general public at large. provision for resilience in the design of an SoS is of great importance. and extrinsic delays such as those imposed by the management’s structures. both intrinsic delays occasioned by the time it takes for the system’s processes to happen. though perhaps not just by piling further pressures on management to deliver this. what this example indicates is that the interface is thick rather than thin. Honda and Nissan production and procurement systems due to the same tsunami. and necessarily must include the levels of strategy. ! If an SoS in composed of organisations at the four different stages of the lifecycle. 2 A lifecycle model from the IT industry. It is well-known that SoS engineering must concentrate on the interfaces. Of interest are the different organisational drivers across the lifecycle. showing the gradual commoditisation of components. procedures and habits. A different example is a recent significant slow-down in the supply of consumer IT devices.

Perpetually working with incomplete knowledge. ‘Faster. cheaper’ as outlined above While laudable (especially from the customer’s perspective). adjustments will always be necessary. Because of confidentiality. Another issue in many SoS is the near-enshrinement of the mantra. taken from the domain of Fast-Moving Consumer Goods (FMCG). Apart from its oft-stated benefits. including what is currently known as ‘Customer Relationship Management’. incomplete knowledge. resulting in unexpected disturbances for those systems and organizations not in the know. often dictated by changes in circumstances of the owner organisation. this guarantees that not only does the SoS have to accommodate changes to the environment outside its boundaries. while discussions should occur. regulated. The dictum ‘We should consider the user to be the designer’s on-site representative’ (Rasmussen and Goodstein 1986) is significant across the SoS. in the absence of full knowledge. ! ! . the mantra can also introduce brittleness into systems by introducing too much close-coupling and by reducing manpower (which is where knowledge. as illustrated in figure 3 below. wisdom. ! Compounding the issue of incomplete knowledge is the evolution of individual systems within the SoS. in this scenario it becomes unwise to believe at any time that you have sufficient knowledge and information. and competitiveness reasons. the implication of this is that SoS design is unlikely ever to be completed and. the design or configuration of an SoS will always be associated with incomplete knowledge and information flows. leading to emergent problems in operation. security. Furthermore. manufacturing or production process. and hence resilience in the design approach is essential. better. and full-time resources must be devoted to this effort. Competitive marketing campaigns (and other coups d’oeil) demand secrecy within the supply chain. large organisations may evolve their systems without much regard to the effects on other systems – the current financial crisis in the banking world being a good example. it must accommodate continual evolution of its component systems while maintaining an ever more precise. When coupled with frequent demands for change. As an aside. designers come and go. and the main capability for resilience resides). exacerbating the usual demands for commercial confidentiality. it is the only way one can check one’s assumptions and knowledge about the reality of the SoS and the role of one’s SoI within it. for which the requisite knowledge and information will not be available beforehand (though hindsight may help to explain what has happened and why). An important aspect of the design and management of SoS is the perennial fact of working with imperfect. In fact. and knowledge conservation becomes an important issue.

! Fig. ! Fuzzy SoS boundaries. there are opportunities for information leakage. in the middle is a major supplier to them. Organisations owning a system within the SoS typically know their immediate neighbours. for example. At right are two competing supermarkets. the provision for waste removal. Even within a single organisation that owns a participating system. how often. Elsewhere. information must be kept confidential. there to perform a function and then depart. Are they part of the SoS or not and if so how does the SoS deal with their ingress and egress? It may be the case that nobody knows the full complement of who or which systems are actually participating in the SoS: emergency services SoS would be an example of this.3 Illustration of a supply chain in the Fast Moving Consumer Goods domain. Consultants are an example. there may be confusion about the extent of that system boundary. but few participating organisations beyond them. emergency services and the like? • • ! ! . do system engineers consider the local State infrastructure that supports the system. this may not be the case. there is a tier 1 supplier and a consultant. education. and warnings about changes of competitive advantage will be nearly non-existent. Nevertheless. Where there are interfaces with the rest of the SoS. The boxes indicate some of the issues affecting the SoS interfaces. the boundary is likely to be well-described. SoS boundaries can be fuzzy for four main reasons: • Component systems and their owners within the SoS may have a short-term presence. road transportation.

For an organisational system. Encompassing all of the issues mentioned above is complexity. engineers in a concurrent engineering environment) Effects of an evolving environment Effects of co-evolving agents Interactions between different goals within an agent Interactions between agents with different goals Language/culture differences ! .• Individuals within the SoS (who may have signed many security and confidentiality documents) may extend the boundaries in order to get their jobs done. phone. but given no useful answer might make a few discreet inquiries of trusted colleagues through a! >24I'99&4)10! organisation like INCOSE. individuals.g. which we may define as: ‘The behavioural characteristics of the network of agents and relationships that make up the system of interest. teams. Ignorance comes first’. ‘Stupidity is the second most expensive thing for an organisation. That SE might discuss the problem with others within the SoS. for confidentiality) the first three imply a lack of knowledge and situational awareness within the SoS. These characteristics are not decomposable to individual elements or relationships’ (Siemieniuch and Sinclair 2005). reaching design decisions with engineers at different sites) Lots of connections between agents (e. doing different tasks at different times) Some degree of behavioural autonomy for agents Multiple steady states for agents Interactions between agents in an environment (e. maybe pushing out the boundaries with unknown effects. perhaps. Consider the Systems Engineer faced with an intractable problem and a!looming deadline. etc. (Gregg 1996) has defined some attributes of complexity that make long-term behaviour unpredictable: • • • • • • • • • • • ! Many agents.g. email.g. Induced and intrinsic complexity in organizations.g. This provides some rationale for the comment by a senior manager in the aerospace industry. fax) Communicating in parallel (e. While the fourth reason may not be serious (except. of different kinds (e.

Fig. consider a global company’s factories in different regions that make a wide range of a particular product. The same applies to the organisation. there are some benefits that can accrue from translating complexity to other parts of the SoS. thus exacerbating the effects of Gregg’s attributes. However. and as Gregg pointed out. with which Systems Engineers often have to contend. But the latter is easier to manage. there is an increase in distribution complexity to deliver the same range of product to the regions’ customers. What can be done about intrinsic complexity? Not much. Fig. However. and their overlap. The former is the inescapable complexity necessary to achieve the goals of the enterprise system (if you would go to the moon and return. as (Woods and Hollnagel 2006) have said. On the other! hand. Induced complexity arises when the system’s management is neither structured. if the company reduces the range made in each factory.This set of organisational attributes is a good description of the working environment of most Systems Engineers. Intrinsic and Induced complexity. It is very expensive to reduce this figure. staffed nor operated appropriately. even a sub-set of these is sufficient for emergent behaviour. thereby reducing down-time. 4 below illustrates this. An example comes again from the FMCG domain.! and they are already running at only 3% down-time. ‘Complexity is conserved under transformation and translation’. 4 Illustration of Intrinsic and Induced Complexity. enabling the company to maximise its profits. it is possible to split organisational complexity into two parts. the system to accomplish this is necessarily complex). ! ! .

Legacy issues. given a little wisdom. be conflated. ! Information integrity and security considerations.Induced complexity is actually quite common. Over that period of time. but which amount to a significant breach. There are several parts to this. Because these are well-known. it can only be translated for better functioning. Since most SoS knowledge and wisdom is held in human heads. or because tiny bits happen to be disclosed in different parts of the SoS. there is the issue of confidentiality. ‘we observed an outsourced application with 120 COTS products. The emerging field of Enterprise Systems Engineering is of relevance here. which may occur because of different implementations of security across the SoS. they become immortal (lasting beyond the designer’s three score years and ten). however a summary of those discussed in this paper implies the following: • Many SoS are sufficiently important to society that they will be maintained for very long periods. Secondly. there is the inadvertent disclosure of information that is intended to be secure. if we consider information to comprise data with meaning. it is possible that a database passed from one system to another may. this has strong implications for on-going knowledge conservation and management (Siemieniuch and Sinclair 2001) The complexity inherent in most SoS allied to the frequent processes of change within the SoS imply that unexpected. lack of trust. While some of this complexity is induced though! the organisations that administer the SoS and can therefore be ameliorated to a large extent. it is often a product of unclear authorities. still-working software systems that perform some vital function within a SoS and that are deemed to be too costly to replaceand for which documentation is scarce. though the solutions could be applied just as easily by the companies themselves. and SoSE is lacking in addressing these. no system in the SoS will stay the same. elaborated. From an enterprise systems perspective. and it is likely that over a 40-year period there will be close to 100% staff turnover. Most of these problems are human-initiated. Thirdly. issues of organisational culture. for example. 46% of which were delivered in a vendor-unsupported state’ (Boehm 2006). effectively. there is a loud message here about knowledge conservation and distribution in order to maintain these systems in a viable operational condition. rearranged and/or clipped (thereby altering meaning). Firstly. and then be made available to the rest of the SoS. emergent behaviour is likely to occur over any reasonable period of time. condensed. for sound internal reasons. there is any number of tools and consultants ready to apply them. The classic example of these is the old. A more modern case is an SoS some of whose systems are no longer supported by their vendors. and nobody knows how they work. confused responsibilities. which may preclude the passage of useful information around the SoS (passing one competitor’s plans to another within the SOS being an example). lack of comprehensive training of staff. ! • ! . and many other well-known ills. the intrinsic complexity cannot. Summary of the issues discussed above There are many other issues that may impede SoS performance. again for good internal reasons.

Model-based design of the SoS Firstly. Whatever. Sprinkle. covering strategic. allied to emergent behaviour and unexpected environmental events. Loch et al. Policy. The possibility that nobody within the SoS organisations knows the full extent of the SoS may have expensive consequences when some disturbance happens to the SoS. Necessarily. with little knowledge of the SoS outside their own organisation. communication for mutual benefit across organizations is an important component of overall resilience and agility (though there may be necessary restrictions on this) • • • Addressing the issues raised above All of these issues above involve human activity. but deep resilience. there is the issue of necessarily-bounded knowledge for the SoS engineers. Immediate resilience comes from good design and implementation of the SoS. not just for efficiency. It will be necessary to engineer SoS for resilience. not requirements. responding to major upheavals. Clearly. or by human-centred communication methods. and even less about its potential evolution. significant parts of the model will be held in human heads. But this alone is not enough. security. tactical and operational issues. Commercial confidence. agreed specification of interfaces. in common with other authors (deMeyer. the model-based approach must include corporate and engineering governance metrics to enable unwanted ! ! . with systems developed and optimised for internal usage. operations and transactions. and we address some of these below. and that IT tools do not make much recognition of this. the clear. 2002. 2009). The design of an efficient SoS. They may then be given a patch to enable them to communicate with the rest of the SoS. their interconnections and the enterprise systems that own and operate them. either through a standards-based internet interface. that is common in software engineering (DOD 2008. under these circumstances. distributed across the SoS organizations. full flow of information round the SoS. Eklund et al. requires human wisdom and ingenuity allied to organisational competence. Alberts 2011). mean that ‘tipping points’ are a credible possibility. there is ample scope to apply some organizational SoS engineering capability in this domain. either in their occurrence. This happens for security and confidentiality reasons. Williams 2005. and the conservation of knowledge. This MBSE approach necessarily must embrace both the software systems. Knowledge conservation is a critical. is perhaps best achieved by adopting a model-based systems engineering (MBSE) approach. and hence the MBSE approach should accept that for much of the development of a given SoS. that SoS engineering starts with patterns and visions. and will extend backwards into each organization. the net effect is that the pool of SoS system designers comprise distributed groups. Daw 2007. and respect for the ownership of information mean that there is seldom a complete. but with particular emphasis on the embodiment of open standards.• SOS systems dynamics. We would emphasise that. or in their control. amelioration or enhancement. continuous issue for any long-term SoS. Inter-organisational interfaces will be thick. too.

adapted from (Mackley 2008). There is the problem of resilience and agility of the SoS. transport and energy.patterns of SoS behaviour to be made apparent and to be explored. Henshaw. from an organisational perspective: • • • • • • • Translating capability objectives into SOS requirements Understanding systems and relationships Assessing performance to capability objectives Developing and evolving an SoS architecture Monitoring and assessing changes Addressing requirements and solution options Orchestrating upgrades to SoS Reducing the likelihood of tipping points. 2012) Resilience and agility. MBSE will do much to enable frequent re-design of the SoS and its systems throughout the life of the SoS. M. particularly when one considers the key elements of SoS engineering (DOD 2008). Siemieniuch et al. whereas the former are frequently a function of the organisation’s structure and allocation of responsibilities and authorities to make decisions. Sinclair. then.Morcos et al. shown in Fig 5 below. 2012. Siemieniuch et al. essentially immortal systems. becomes a question of how much time does one have in which to adapt to changed circumstances. 2010. an almost-universal exacerbating factor is delays. Agility.S. Hubbard et al. The latter is again an area where Human Factors and other socio-technical professionals can make a big contribution in the area of enterprise systems engineering (Sinclair 2007. the latter are an artefact of systems design (and it is impressive how much effort is spent on addressing this issue in real-time software systems). Hodgson. This is best discussed by an example. one can only use built-in adaptability. one can reach back down the supply chain that is provided by the SoS to make changes that enable a greater ! ! . While there are numerous ways in which a tipping-point problem could happen in a SoS. • • • ! Are we doing the right things? Are we doing those things right? How do we know this? By taking a full approach. If there is more time. 2011. such as health care. governmental systems. These can be extrinsic or intrinsic. taken from the defence domain. especially for long-lived. particularly in relation to the three governance questions. Hubbard. If there is less than a day.

also related to time. Resilience. the design process will have to be repeated equally frequently. To have the capability to attack a ship by a drone today. While the need for change may be driven by the SoS. Consequently. Burns et al. it is likely that distinct changes to the capability delivered by the SoS will be required frequently – recall Heracleitus. this is not long enough). and the need to predict the future quite far in advance. largely due to the bounds imposed on the distribution of knowledge across the SoS. Inspection of the cells in the diagram readily reveals that there is considerable human-technology involvement in most of the cells. and for the ‘immortal’ systems mentioned above. all of which are components of a given of adaptability.4. becomes a measure of the capability of the whole SoS to adapt (but is not included in Fig. pointing yet again to a human factors or socio-technical role in bringing about this upwards shift. Vicente. 1997). 5 The development process to deploy a drone capable of attacking a ship. both resilience and agility can be increased if the activities in the cells in Fig 4 can be moved upwards. one must ‘backwards-chain’ along the arrows in the matrix to discover that the SoS that delivers this capability should have started at least a decade ago. Secondly. Firstly. Fig. perhaps extending to the swapping of organisations within the SoS (the average life expectancy of a company in Europe is 12. Possible socio-technical contributions to SoS design and operation Consideration of the topics discussed above (and many others not included) may lead to the conclusion that Human Factors specialists (or cognate specialists) involved in the design of SoS are faced with a ‘wicked’ problem (Rittel and Webber 1973. since it embraces the whole diagram).5 years (deGeus 2002). Across the top of the matrix are the MOD ‘Lines of development’. change will occur at the level of the individual organisational systems involved in ! ! . Down the side is a timescale to have the capability developed.

and it is the people within these systems who will decide what changes will be made. and excellent feedback. backed up with a handshake and subsequent behavioural integrity in the SoS. and flexible implementation may need further exploration and. Trust comes initially from company values as enunciated and strongly supported by the company Board. etc. rather than organisational power and the creation of positions that can be argued in courts of law. (Siemieniuch. and it is fortunate that some recent research (Haidt 2010. with the emphasis on flexibility and partnerships. Knowledge conservation. this will depend on the ingenuity. there may be a little less competence at the inter-organisational aspects. however. at the human-machine. perhaps. efficient. skills. Given the expectation that people will be flexible and adaptable to change in the SOS. dissemination and conservation of knowledge and wisdom (the latter being the combination of knowledge and experience) within the SoS. 2002)it ! ! . These specifications should include consideration of strategy. culture and readiness to change of these people (leaving aside all the other legal. with damaging effects for co-ordinated planning and operations. The points above carry an implication that ethical behaviour will be the norm. financial. Weick. it issued Letters of Intent. human-system and organisational levels. Organisations can be designed to embody these principles. and who will then implement them. policy. While we are knowledgeable about the management of knowledge. devolved authority and accompanying responsibility. and each will change with time. instead. Sinclair.the SoS. through good governance within a strong organizational culture. organisation and transaction. Reason 2001. how they will be implemented. issues). Human Factors and other socio-technical professionals already have the capability to address them. the management of wisdom in organisations is much less understood. 1999. The latter include: ! The specification of organisational interfaces. Hodgson. Siemieniuch and Sinclair 2004). In turn. motivation. Weick and Sutcliffe 2001. and they shared any accruing benefits in the SoS. there is a strong requirement for trustworthy behaviour by individual organisations involved in a SoS. and without trust there can be little expectation of good performance by one’s partners. As an example. well-understood processes. Siemieniuch and Sinclair 2000. Sutcliffe et al.. Hubbard et al. though contributions do exist (Hammer 2002. Sinclair et al. 2011) has explored aspects of this. Integrity of performance engenders trust. their effective. there is a significant role for the discovery. they did what they said. 1997. Given the importance of trust between organisations (necessitated by the forced bounds on knowledge and information transfer). Coupled with the notion of personal duties (Ross 1930. properly supported roles. albeit each will look different according to its circumstances. This becomes very important in the context of global SoSs. 2009) Ethical organizational behaviour. For all of these. Henshaw et al. While contracts will delineate the structure of the interface through service level and other agreements. in the 1990s a global supermarket chain refused to sign contracts with its suppliers. standardisation. formalisation. It is now one of the world’s largest chains The propagation of trust.

Understanding the Current State of US Defense Systems of Systems and the Implications for Systems Engineering. is a SoS. P. DOD. S. Daw. "Some future trends and implications for systems and software engineering processes. U. Systems engineering guide for systems of systems. D. deGeus. E. G. et al. 2002. 2006." IEEE Transactions on Engineering Management 40(2): 104-113.. A. 2006. Andersson. ! ! . Montreal. C. Office of the Deputy Under Secretary of Defense for Acquisition and Technology. An emergent perspective on interoperation in systems of systems." IEEE Transactions on Power Systems 20(4): 1922-1928. and. But is this an important consideration for society? In the opinion of the authors. Conclusion! This paper has addressed the contribution that socio-technical knowledge could make to the growing domain of SoS engineering. US DOD Command & Cpontrol research Program. J." Systems Engineering 9(1): 1-19. and recommended means to Improve system dynamic performance. "Analysis of US semiconductor collaboration. it is – especially when it is realised that just about every operating system in the world. and the interconnections between these that are occurring mean that this is a topic that is not ephemeral. with all the ensuing benefits for the SOS.I. and hence engender trust more easily. N. MD. Baldwin 2008. if only from a professional ethics perspective. responsibilities and the allocation of authority to enhance the likelihood of ethical behaviour in the organisation. Donalek." Sloan Management Review 43(2): 60-67. P. "Managing project uncertainty: from variation to chaos. including its supporting infrastructure. Dahmann.. "Causes of the 2003 major grid blackouts in North America and Europe. The agiity advantage. 1993. The living company: habits for survival in a turbulent business environment.should be possible to design roles. AIAA: 1-26. US Department of Defense. deMeyer. Gover. it behoves its inclusion.. J. Belfast. Washington. Carnegie-Mellon University. D. J. Keynote: On the wicked problem of defence acquisition. 2008. Loch. Integration and Operations Conference: Challenges in Systems Engineering for Advanced Technology Programmes. 2007. and K. 7th AIAA Aviation Technology. 2005. B. et al. Boston. H. DC. Fisher. ! References! Alberts. 2002. The steady growth of IT&T systems into almost all aspects of human life and society. 2nd Annual IEEE Systems Conference. A. A. A. 2011. Harvard business School Press. Boehm. .

" Policy Sciences 4: 155-169. 2001. June 2010. Rasmussen. E. and M.S. "Past the Tipping Point: The Persistence of Firefighting in Product Development. E. 2011. IEEE Conference on Systems of Systems Engineering. 1930. Realising Network Enabled Capability. Culture and the performance of teams in complex systems. J. Albuquerque. The dimensions of organisational resilience to operational hazards. et al. System of systems engineering . et al. W. M. British Airways Human Factors Conference: Enhancing Operational Effectiveness. Webber 1973. 2009. Ed. J. P. Heracleitus 535-475 BCE. Boca Raton. Systems of systems engineering .-M. T. Siemieniuch.. P. D. Loughborogh. Varese. ESRC Business Process Resource Centre. Hodgson. Ross. P.. Hammer.. Davenport. Ed. ESRC Business Process Resource Centre.Inter-Generational Knowledge Transfer in a Changing Public Service. and L. Hubbard. Coventry.. The Getting and Keeping Of Wisdom . 1996. University of Warwick. E. M. 64. Herakleitos and Diogenes. Leeds. "Architecting principles for systems-of-systems. Rittel. D. et al. Italy. A taste analogy in moral psychology: picking up where Hume left off Retrieved 20/09/2011. USA. UK. W. Ottawa." California Management Review 43(4): 44-63. J. 2011. Research Directorate." Systems Engineering 1(4): 267-284. A. Concepts of agility in Network Enabled Capability. BAE Systems. 2009. M. Emerging challenges in business and manufacturing decision support. Maier. M. "The new science of morality. The Science of Business Process Analysis.Gregg. Strategy+Business. M. Hubbard. Haidt. Reason.principles and applications. ! ! ." The new science of morality. Jamshidi. CRC Press. W. 1998. UK. Henshaw. Jamshidi. 2002. Wiley & Sons. Grey Fox Press.Morcos. Oxford University Press (reprinted). part 1.. N. UK. Bolinas. H. Oulton Hall. 2nd IFAC/IFIP/IFORS/IEA Conference. " Identification of induced complexity in PSS enterprises. Decision support in supervisory control. The right and the good.. M. J." Journal of Enterprise Transformation.innovations for the 21st century. M. Proceedings of the 5th IEEE International Conference on System of Systems Engineering (SoSE). Booz & Co. Mackley. 2001. leMerle. "Dilemmas in a general theory of planning. IEEE. 2010. 1979). 2012. Analysis. D. et al. 2002. Repenning. J. Working towards a holistic organizational systems model. M. Public Service Commission of Canada. . UK. design and evaluation of man-machine systems. 2008. Oxford. Goncalves. J. 2010. How to prepare for a black swan. M. (cited in G. C.. Goodstein 1986. No publisher.

" Organizing for high reliability: processes of collective mindfulness. 13th Triennial Congress of the International Ergonomics Association . D. P. Eklund." Applied Ergonomics 43(1): 176-183. Hollnagel 2006.IEA'97. "The development of a tool to predict team performance... M. K." Organisational readiness in e-supply Retrieved 12 Nov. and E. "Organisational readiness for knowledge management within e-supply chains. Contemporary Ergonomics 2009." International Journal of Operations & Production Management 24(1): 79-98.. Vicente. et al. Tampere. from http://www. 2012.sck2001. M. 2007. Sinclair. "Implications of the supply chain for role definitions in concurrent engineering. 1999. D. "Ergonomics issues in future systems. "Muddling through wicked design problems. Sinclair. C. CRC Press: 977 – 1008. M. J. C. E." Ergonomics 50(12): 1957 1986. D. London. E. Managing the unexpected : assuring high performance in an age of complexity. "Model-based design: a report from the trenches of the DARPA Urban Challenge. A. San Francisco. W.July 4th 1997. Sinclair. Taylor & Francis. Henshaw. Burns.. 2009. D. J. Siemieniuch. Governance. Weick." Research in Organisational Behaviour 21: 23-81. Siemieniuch. 23 Nov. et al. E. 2005. et al. M. M. Jossey-Bass. JJJ#! 2001. Basingstoke. K. Taylor & Francis: 100 – 108. JJJ#! 2005. Siemieniuch. and K. M. Evaluation of Human Work. et al. T." IEEE Transactions on Engineering Management 52(4): 497-508. 1997. Wilson and N... 2009. Weick. D. 2001. A. JJJ#! 2004. E. P." International Journal of Human Factors and Ergonomics in Manufacturing 10(3): 251-272. Sinclair. J. USA. Florida. et al.Rudolph. M. Repenning 2002. Supply chain issues in the fast-moving consumer goods industry. The road to world class manufacturing 2002. Sinclair 2000. J. Touche. et al. Woods. A. J. and N.. London: 56. M. Boca Raton. Corlett. Sutcliffe. C. "Organisational Readiness for Knowledge Management. Finnish Institute of Public Health. Williams. Bust. A. J. Joint cognitive systems: patterns in cognitive systems engineering. K. M." Software and System Modeling 8: 551-566." Administrative Science Quarterly 47(1): 1-30. K. The analysis of organisational processes. (2003). "Assessing and moving on from the dominant project management discourse in the light of project over-runs. Agility and Wisdom in the Capability Paradigm. Finland. Sprinkle. "Disaster dynamics: understanding the role of quantity in organizational collapse. 1997. R. ! ! ." Ergonomics in Design 5(1): 25-30. M. E. and M. Sutcliffe 2001. June 29 . C.

she has developed new understandings about: the management. With European CREE professional registration she is a registered EU ‘expert’ with evaluation. through manufacturing systems engineering to design processes and the management of knowledge. having been an academic member of Loughborough University since 1970. Electronic and Systems Engineering at Loughborough University. All of this work has necessitated close involvement with industry. and emergent system behaviours. his interests now include the assurance of ethical behaviour by autonomous and semi-autonomous systems. defence and nuclear safety domains. impact of cultural factors on system autonomy levels. Over the last five years. He is a Systems Ergonomist of some 40 years standing. enterprise system modelling. His interests have evolved from the understanding of organisational processes of manufacturing from the shopfloor. ! ! ! . Murray Sinclair is now a Visiting Fellow at Loughborough University. in the automotive domain and latterly in the aerospace. human and organisational performance. She has worked as a systems ergonomist for over 25 years in the manufacturing and aerospace domains (civilian and defence)). project reviewer and project management expertise within the Framework Programmes. She has over 100 referred publications in the area of organisational and system design. due to the steady infiltration of information technology into society and its pervasiveness in the lives of individuals. allocation of function and systems design. such as robots. EU (7) & MoD/Industry (9) funded projects. healthcare systems and the like. As a PI/CoI on a range of EPSRC (8).Carys Siemieniuch is s a Senior Lecturer in Systems Engineering in the School of Electrical. capture and utilisation of tacit knowledge.

Sign up to vote on this title
UsefulNot useful