Difference between pages "System Resilience" and "Organizing Business and Enterprises to Perform Systems Engineering"

From SEBoK
(Difference between pages)
Jump to navigation Jump to search
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
−
According to the Oxford English Dictionary on Historical Principles (1973), [[resilience (glossary)]] is “the act of rebounding or springing back.” This definition most directly fits the situation of materials which return to their original shape after deformation. For human-made systems this definition can be extended to say “the ability of a system to maintain capability in the face of a [[disruption (glossary)]].” The US government definition for [[infrastructure (glossary)]] systems is the “ability of systems, infrastructures, government, business, communities, and individuals to resist, tolerate, absorb, recover from, prepare for, or adapt to an adverse occurrence that causes harm, destruction, or loss of national significance” (DHS 2010). The concept of creating a resilient human-made system or resilience engineering is discussed by Hollnagel, Woods, and Leveson (2006). The techniques are elaborated by Jackson and Ferris (2013). In some sources these techniques are referred to as design principles.
+
----
−
 
+
'''''Lead Authors:''''' ''Richard Beasley, Art Pyster, Hillary Sillitto'', '''''Contributing Authors:''''' ''Alice Squires, Heidi Davidz, Scott Jackson, Quong Wang''
−
==Overview==
+
----
−
Resilience is a relatively new term in the SE realm, appearing only in the 2006 timeframe and becoming popularized in the 2010 timeframe.  The recent application of “resilience” to engineered systems has led to confusion over its meaning and a proliferation of alterative definitions. (One expert claims that well over 100 unique definitions of resilience have appeared.)  While the details of definitions will continue to be discussed and debated, the information here should provide a working understanding of the meaning and implementation of resilience, sufficient for a system engineer to effectively address it.
+
In order for a {{Term|Business (glossary)|business}} or {{Term|Enterprise (glossary)|enterprise}} to perform {{Term|Systems Engineering (glossary)|systems engineering}} (SE) well, the team must decide which specific SE capabilities the business or enterprise needs in order to be successful and then organizing to deliver those capabilities. (In the rest of this article, business or enterprise is usually abbreviated to just "business", because a business is a specific type of enterprise that has sufficiently strong central authority and motivation to take steps to enable SE).
−
 
 
−
===Definition===
 
−
It is difficult to identify a single definition that – word for word – satisfies all.  However, it is possible to gain general agreement of what is meant by resilience of engineered systems; viz.,
 
−
resilience is the ability to provide required capability in the face of [[adversity (glossary)|adversity]].
 
  
−
===Scope of the Means===
+
SE capabilities and organizational approach should support the [[Systems Engineering Organizational Strategy]] and reflect the nature of the business, its products and services, various stakeholders, business leadership focus, etc.  This topic, which is part of Part 5, [[Enabling Businesses and Enterprises]], summarizes the factors used to organize a business to perform SE.
−
In applying this definition, one needs to consider the range of means by which resilience is achieved:
 
−
The means of achieving resilience include avoiding, withstanding, recovering from and evolving and adapting to adversity.  These may also be considered the fundamental objectives of resilience, Brtis (2013).
 
−
Classically, resilience includes “withstanding” and “recovering” from adversity.  For the purpose of engineered systems, “avoiding” adversity is considered a legitimate means of achieving resilience. Jackson and Ferris (2016).  Also, it is believed that resilience should consider the system’s ability to “evolve and adapt” to future threats and unknown-unknowns.
 
  
−
===Scope of the Adversity===
+
==Components of Business and Enterprise SE Capability==
−
Adversity is any condition that may degrade the desired capability of a system.  We propose that the SE must consider all sources and types of adversity; e.g., from environmental sources, due to normal failure, as well as from opponents, friendlies and neutral parties. Adversity from human sources may be malicious or accidental. Adversities may be expected or not. Adversity may include "unknown unknowns." The techniques for achieving resilience discussed below are applicable to both hostile and non-hostile adversities in both civil and military domains. Non-hostile adversities will dominate in the civil domain and hostile adversities will predominate in the military domain.
 
  
−
Notably, a single incident may be the result of multiple adversities, such as a human error committed in the attempt to recover from another adversity.
+
=== Organization Issues - Culture, Knowledge, Information, and Infrastructure ===
  
−
===Jackson & Ferris Taxonomy===
+
The way SE is managed is described in [[Systems Engineering Organizational Strategy]], which both impacts and responds to the SE [[Culture|culture]] and approach.
  
−
Figure 1 depicts the loss and recovery of the functionality of a system. In the taxonomy proposed by Jackson and Ferris (2013) four attributes can lead to a resilient system and may posess four attributes: [[robustness (glossary)]], [[adaptability (glossary)]], [[tolerance (glossary)]], and [[integrity (glossary)]] — and fourteen design techniques and 20 support techniques that can achieve these attributes. These four attributes are adapted from Hollnagel, Woods, and Leveson (2006), and the design techniques are extracted from Hollnagel et al. and are elaborated based on Jackson and Ferris (2013) for civil systems.
+
=== Knowledge and Information ===
 +
Knowledge and Information are key assets in a business, and their management is critical. Fasser and Brettner (2002) discuss knowledge management extensively. They assert that ''“We may think that knowledge transfer is just an information technology issue, but in actuality, it is also a psychological, cultural, and managerial issue – in short a human issue” and “Only information in action can create knowledge”''.
  
−
Other sources for example, DHS (2010) lists the following additional attributes: rapidly, affordability and learning capacity.
+
Organizations need to manage SE know-how, integration of SE with other organizational processes and activities, and knowledge of their business domain. The INCOSE Intelligent Enterprise Working Group's work on knowledge management in an SE context led to the publication of a ''“Concept of Operations for a Systems Engineering Educational Community”'' (Ring et al. 2004).
  
−
[[File:Disruption_Diagram.PNG|thumb|center|400px|'''Figure 1. Disruption Diagram.''' (SEBoK Original)]]
+
Information has to be both shared and protected in complex organizations. Sharing is key to effective collaboration and is constrained by the need to protect intellectual property, as well as commercially and nationally sensitive material. Different cultures and personal styles use information in different ways and in different orders. (Levels of abstraction, big picture first or detail, principles first or practical examples, etc.) Sillitto (2011b) describes the knowledge management challenges for large, multi-national organizations.
  
−
The Robustness Attribute
+
Projects need to manage project information and establish configuration control over formal contractual information, as well as the information that defines the product/service being developed, supplied, or operated. A key role of systems engineers is to “language the project” (Ring et al. 2004). Good data management and tool support will allow people to document once, use many times, and ensures consistency of information over time and between different teams.
−
 
−
Robustness is the attribute of a system that allows it to withstand a threat in the normal operating state. Resilience allows that the capacity of a system may be exceeded, forcing the system to rely on the remaining attributes to achieve recovery. The following design techniques tend to achieve robustness:
 
  
−
*[[absorption (glossary)]]
+
System information needs to be maintained throughout the life of the system and made available to relevant stakeholders – including those designing new systems that must interface to the system-of-interest - to allow system management, maintenance, reconfiguration, upgrade and disposal, and forensics after accidents and near-misses. Elliott et al. (2008) suggest that information management is the dominant problem in SE in service systems, and that the cost and difficulty of establishing current state and legacy constraints before starting to implement a change is often underestimated.
−
*[[physical redundancy (glossary)]]
 
−
*[[functional redundancy (glossary)]]
 
  
−
The Adaptability Attribute
+
"Infostructure" (information infrastructure) to support the system lifecycle will include the following:
 +
*Information assets such as process libraries, document templates, preferred parts lists, component re-use libraries, as-specified and as-tested information about legacy systems, capitalized metrics for organizational performance on previous similar projects, all with appropriate configuration control
 +
*Modeling and simulation tools, data sets and run-time environments
 +
*Shared working environments – workspaces for co-located teams, areas for people to interact with each other to develop ideas and explore concepts, work areas suitable for analysis tasks, meeting rooms, access control provision, etc.
 +
*IT facilities - computer file structures, software licenses, IT equipment, computer and wall displays to support collaborative working, printers, all with appropriate security provision and back-up facilities, procedures for efficient use, and acceptable performance and usability
 +
*Security provisions to protect own, customer, supplier and third party IPR and enforce necessary protective working practices while allowing efficient access to information for those with a need to know
  
−
Adaptability is the attribute of a system that allows it to restructure itself in the face of a threat. Adaptability can apply to any phase of the event including detecting and avoiding the adversity and restructuring to return to normal operation. The following design techniques apply to the adaptability attribute:
+
SE is a knowledge activity. Systems engineers need appropriate facilities for accessing, sharing and capturing knowledge, as well as for interacting effectively with the whole set of stakeholders.  Warfield (2006) describes collaborative workspaces, environments and processes for developing a shared understanding of a problem situation.
  
−
*[[restructuring (glossary)]]
+
=== Enabling Infrastructure ===
−
*[[human in the loop (glossary)]]
 
−
*[[complexity avoidance (glossary)]]
 
−
*[[drift correction (glossary)]]
 
  
−
The Tolerance Attribute
+
The ISO/IEC 15288 (ISO 2008) Infrastructure Management Process provides the enabling infrastructure and services to support organization and project objectives throughout the life cycle. Infrastructure to support the system life cycle will often include the following:
  
−
Tolerance is the attribute of a system that allows it to degrade gracefully following an encounter with adversity. The following design techniques apply to the tolerance attribute.
+
*Integration and test environment – bench and lab facilities, facilities for development testing as well as acceptance testing at various levels of integration, calibration and configuration management of test environments
 +
*Trials and validation environment – access to test ranges, test tracks, calibrated targets, support and storage for trials – equipment, harbor, airfield and road facilities, safe storage for fuel, ordinance, etc.  
 +
*Training and support infrastructure – training simulators, embedded training, tools and test equipment for operational support and maintenance, etc.
  
−
*[[modularity (glossary)]]
+
=== People ===
−
*[[loose Coupling (glossary)]]
+
The roles people fill are typically defined by the business/enterprise (see [[Determining Needed Systems Engineering Capabilities in Businesses and Enterprises]]), although those decisions may be pushed down to teams. [[Enabling Teams]] explains how people are used in teams; [[Enabling Individuals]] describes the development of an individual's SE competence.
−
*[[neutral state (glossary)]]
 
−
*[[reparability (glossary)]]
 
−
*[[defense in depth (glossary)]]
 
  
−
The Integrity Attribute
+
The implementation of these roles needs further consideration. Sheard (1996) lists twelve system engineering roles.  Sheard (2000) draws an important distinction between roles involved in the discovery phase, characterized by a high level of uncertainty, the program phase, which is more deterministic and defined, and the overall systems engineering approach.  Kasser et al. (2009) identify five types of systems engineer distinguished by the need to work at increasing levels of abstraction, ambiguity, scope and innovation. Sillitto (2011a) discusses a number of SE roles and the characteristics required of them, in the context of the wider engineering and business professional landscape.
  
−
Integrity is the attribute of a system that allows it to operate before, during, and after an encounter with a threat. Integrity is also called cohesion which according to (Hitchins 2009), a basic characteristic of a system. The following global design technique applies to the integrity attribute.
+
Systems engineering exists within an enterprise “ecosystem.” Two key aspects to consider:
−
*[[Internode Interaction (glossary)]]
+
*How much should the business/enterprise nurture and value the systems engineer? 
 +
*How much should the business/enterprise pull value from systems engineers, rather than wait for systems engineers to "push" value on the business/enterprise?
  
−
===MITRE Taxonomy===
+
=== Process ===
  
−
Brits (2016) builds on the cyber resilience work of Bodeau & Graubart (2011) and proposes an objectives-based three layer taxonomy for thinking about resilience. The three layers include:
+
Many SE organizations maintain a set of organizational standard processes which are integrated in their quality and business management system, adapted to their business, and with tailoring guidelines used to help projects apply the standard processes to their unique circumstances.
−
1) four fundamental objectives of resilience,
+
Guidance on organizational process management is provided by such frameworks as the Capability Maturity Model Integration (CMMI) (SEI 2010), which has two process areas on organizational process: Organizational Process Development (OPD) is concerned with organizational definition and tailoring of the SE lifecycle processes (discussed in detail elsewhere in this document) and Organizational Process Focus (OPF), which is concerned with establishing a process culture in an organization.
−
2) ten means objectives of resilience, and,
 
−
3) 23 engineering techniques for achieving resilience.
 
  
−
The four fundamental objectives, which identify the intrinsic value of resilience, are:
+
To document, assess, and improve SE processes, businesses often establish a systems engineering process group.  Members of such groups often create standard process assets and may mentor teams and business units on how to adopt those standard processes and assess how effective those processes are working.  There is a large body of literature on SE process improvement based on various process improvement models. Two of the most popular are ISO/IEC 9000 (2000) and CMMI (SEI 2010).  The Software Engineering Institute, which created the CMMI, offers many free technical reports and other documents on CMMI at http://www.sei.cmu.edu/cmmi.
−
* Avoid adversity
 
−
* Withstand adversity
 
−
* Recover from adversity
 
−
* Evolve and adapt to unanticipated adversity
 
  
−
The ten means objectives are not ends in themselves - as are the fundamental objective - but do tend to result in the achievement of the fundamental objectives: The means objectives are:
+
Assessment and measuring process performance is covered in [[Assessing Systems Engineering Performance of Business and Enterprises]].
−
* anticipate
 
−
* understand
 
−
* disaggregate
 
−
* prepare
 
−
* prevent
 
−
* continue
 
−
* constrain
 
−
* redeploy
 
−
* transform
 
−
* re-architect
 
  
−
The 23 engineering techniques that tend to achieve the fundamental objectives are:
+
=== Tools and Methods ===
−
* adaptive response
 
−
* analytic monitoring
 
−
* coordinated defense
 
−
* deception
 
−
* distribution
 
−
* detection avoidance
 
−
* diversification
 
−
* dynamic positioning
 
−
* dynamic representation
 
−
* effect tolerance
 
−
* non-persistence
 
−
* privilege restriction
 
−
* proliferation
 
−
* protection
 
−
* realignment
 
−
* reconfiguring
 
−
* redundancy
 
−
* replacement
 
−
* segmentation
 
−
* substantiated integrity
 
−
* substitution
 
−
* threat suppression
 
−
* unpredictability
 
  
−
The relationships between the three layers of this taxonomy are many-to-many relationships.
+
SE organizations often invest in SE tools and models, develop their own, and/or integrate off-the-shelf tools into their particular business/enterprise processes. Tools require great attention to culture and training; to developing a consistent “style” of use so that people can understand each others’ work; and proper configuration and management of the information so that people are working on common and correct information.
  
−
The Jackson & Ferris taxonomy comes from the civil resilience perspective and the Brtis/MITRE taxonomy comes from the military perspective. Jackson and Brtis (2017) have shown that many of the techniques of the two taxonomies are equivalent and that some techniques are unique to each domain.
+
It is important that methods are used as well as tools, particularly to support [[Systems Thinking]].
  
−
===Techniques for Achieving Resilience===
+
It is common practice in large SE organizations to have a tool support infrastructure which ensures that tools support the organizational standard processes and are fully integrated with training, and that projects and teams can use the tools to do their job and are not distracted by tool management issues that are more efficiently handled centrally. Smaller SE organizations often operate more informally.
  
−
Techniques for achieving resilience have been identified for both the civil and military domains.  Jackson and Ferris (2013) have identified techniques for the civil domain and Brtis (2016) has identified techniques for the military domain.  There is overlap between these two sets and also some differences. Jackson and Brtis (2017) compare the techniques in the two domains and show their commonalities and their differences.
+
== Fitting It All Together ==
 +
The concept map in Figure 1 below shows the relationships between the various aspects of organization, resource, responsibility, and governance.
  
−
====Techniques for the Civil Domain====
+
[[File:Part_5_(Organization)_Concept_maps_additions_hgs_15_Aug.png|thumb|center|750px|'''Figure 1. Businesses, Teams, and Individuals in SE.''' (SEBoK Original)]]
−
 
−
34 techniques and support techniques for the civil domain described by Jackson and Ferris (2013) include both design and process techniques that will be used to define a system of interest in an effort to make it resilient. These techniques were extracted from many sources. Prominent among these sources is Hollnagel et al (2006). Other sources include Leveson (1995), Reason (1997), Perrow (1999), and Billings (1997). Some techniques were implied in case study reports, such as the 9/11 Commission report (2004) and the US-Canada Task Force report (2004) following the 2003 blackout.
 
−
These techniques include very simple and well-known techniques as physical redundancy and more sophisticated techniques as loose coupling. Some of these techniques are domain dependent, such as loose coupling, which is important in the power distribution domain as discussed by Perrow (1999). These techniques will be the input to the state model of Jackson, Cook, and Ferris  (2015) to determine the characteristics of a given system for a given threat.
 
−
In the resilience literature the term technique is used to describe both scientifically accepted techniques and also heuristics, design rules determined from experience as described by Rechtin (1991). Jackson and Ferris (2013) showed that it is often necessary to invoke these techniques in combinations to best enhance resilience. This concept is called defense in depth. Pariès (2011) illustrates how defense in depth was used to achieve resilience in the 2009 ditching of US Airways Flight 1549.
 
−
Uday and Marais (2015) apply the above techniques to the design of a system-of-systems. Henry and Ramirez-Marquez (2016) describe the state of the U.S. East Coast infrastructure in resilience terms following the impact of Hurricane Sandy in 2012. Bodeau & Graubert (2011) propose a framework for understanding and addressing cyber-resilience. They propose a taxonomy comprised of four goals, eight objectives, and fourteen cyber-resilience techniques. Many of these goals, objectives and practices can be applied to non-cyber resilience.
 
−
Jackson and Ferris (2013) have collected 14 design techniques from various authoritative sources.  These techniques are applicable primarily to civil systems including civil infrastructure, aviation, and power grids. In addition to the 14 design techniques, Jackson and Ferris (2013) also identify 20 support techniques that are narrower in scope than the above design techniques.
 
  
−
====Techniques for the Military Domain====
+
== Enterprise Structures and Their Effects on SE==
 +
Enterprises manage SE resources in many different ways.  A key driver is the extent to which they seek to optimize use of resources (people, knowledge, and assets) across teams and across the enterprise as a whole.  Five common ways of organizing resources to support multiple projects are: project; matrix; functional; integrated; and product centered (CM Guide 2009, Handy 1985, PMI 2013, section 2.1.3). A large enterprise would likely apply some combination of these five ways across its constituent sub-enterprises and teams. Browning (2009) offers a way to optimize project organizational structure. Eisner (2008) offers a good overview of different organizational models.
  
−
Brtis (2016), in the third level of his taxonomy discussed above identifies 23 engineering techniques for achieving resilience in the military domain. Jackson and Brtis (2017) have shown that many of the civil and military techniques are equivalent though some are unique to each domain.
+
===Project Organization===
 +
A project organization is one extreme in which projects are responsible for hiring, training, and terminating staff, as well as managing all assets required for delivery. In this model, systems engineers on a project report to the project manager and resources are optimized for the delivery of the project. This model has the advantage of strongly aligning the authority and responsibility of the project with the project manager. However, it operates at the expense of sub-optimizing how the staff is deployed across the larger enterprise, how technology choices are made across projects, etc.  ''Systems Engineering Fundamentals'' (DAU 2001) offers a DoD view of good practice project organizations.
  
−
===The Resilience Process===
+
===Functional Organization===
−
Implementation of resilience in a system requires the execution of both analytic and holistic processes. In particular, the use of architecting with the associated heuristics is required. Inputs are the desired level of resilience and the characteristics of a threat or disruption. Outputs are the characteristics of the system, particularly the architectural characteristics and the nature of the elements (e.g., hardware, software, or humans).
+
A functional organization demonstrates the opposite extreme. In a functional organization, projects delegate almost all their work to functional groups, such as the software group, the radar group or the communications group. This is appropriate when the functional skill is fast-evolving and dependent on complex infrastructure. This method is often used for manufacturing, test engineering, software development, financial, purchasing, commercial, and legal functions.
−
Artifacts depend on the domain of the system. For technological systems, specification and architectural descriptions will result. For enterprise systems, enterprise plans will result.
 
−
Both analytic and holistic methods, including the techniques of architecting, are required. Analytic methods determine required robustness. Holistic methods determine required adaptability, tolerance, and integrity.
 
−
One pitfall is to depend on just a single technique to achieving resilience. The technique of defense in depth suggests that multiple techniques may be required to achieve resilience.
 
  
−
===Practical Considerations===
+
===Matrix Organization===
−
Resilience is difficult to achieve for infrastructure systems because the nodes (cities, counties, states, and private entities) are reluctant to cooperate with each other. Another barrier to resilience is cost. For example, achieving redundancy in dams and levees can be prohibitively expensive. Other aspects, such as communicating on common frequencies, can be low or moderate cost; even there, cultural barriers have to be overcome for implementation.
+
A matrix organization is used to give systems engineers a “home” between project assignments. Typically, a SE functional lead is responsible for career development of the systems engineers in the organization, a factor that influences the diversity and length of individual project assignments.
 +
===Integrated Organization===
 +
In an integrated organization, people do assigned jobs without specific functional allegiance. Those that perform SE tasks are primarily identified as another type of engineer, such as a civil or electrical engineer. They know systems engineering and use it in their daily activities as required.
  
−
==System Description==
+
=== Product Centered Organization ===
−
A system is “[a]n integrated set of elements, subsystems or assemblies that accomplish a defined objective.” INCOSE (2015) A capability is “…an expression of a system … to achieve a specific objective under stated conditions.” INCOSE (2015)
+
−
 
+
In accordance with the {{Term|Heuristic (glossary)|heuristic}} that “the product and the process must match” (Rechtin 1991, 132), a common method for creating an organizational structure is to make it match the {{Term|System Breakdown Structure (glossary)|system breakdown structure (SBS)}}. According to Browning (2009), at each element of the SBS there is an assigned {{Term|Integrated Product Team (IPT) (glossary)|integrated product team (IPT)}}. Each IPT consists of members of the technical disciplines needed to design the product system. The purpose of the IPT is to assure that the interactions among all the technical disciplines are accounted for in the design and that undesirable interactions are avoided.
−
Resilience is the ability of a system to provide required capability in the face of adversity.  Resilience in the realm of systems engineering involves identifying:
 
−
1) the capabilities that are required of the system,
 
−
2) the adverse conditions under which the system is required to deliver those capabilities, and
 
−
3) the systems engineering to ensure that the system can provide the required capabilities.
 
−
 
 
−
Put simply, resilience is achieved by a systems engineering focus on adverse conditions.
 
−
 
 
−
===Resilience of Processes===
 
−
It is important to recognize that processes are systems – in fact Systems Engineering is a system.  Discussions relating to the resilience of such “process” systems include seven key resiliencies that successful sociotechnical systems intending to accomplish system engineering must have, Warfield (2008). Ashby’s Law of Requisite Variety and Pareto’s Law of Requisite Saliency are the most familiar.  The scope and time of arrival of Contract Change Orders that require system engineering attention pose significant risk. Ones that occur during detailed design that affect the requirements baseline and system design baseline and occur faster than can be accommodated are particularly threatening.
 
−
 
 
−
==Discipline Management==
 
−
Most enterprises, both military and commercial, include organizations generally known as Advanced Design. These organizations are responsible for defining the architecture of a system at the very highest level of the system architecture. This architecture reflects the resilience techniques described in Jackson and Ferris (2013) and Brtis (2016) and the processes associated with that system. In many domains, such as fire protection, no such organization will exist. However, the system architecture will still need to be defined by the highest level of management in that organization. In addition, some aspects of resilience will be established by government imposed requirements.
 
  
−
==Discipline Relationships==
+
=== Interface to Other Organizations ===
  
−
===Interactions===
+
Outside official engineering and SE organizations within an enterprise, there are other organizations whose charter is not technical. Nevertheless, these organizations have an important SE role.
−
=====Outputs=====
 
−
The primary outputs of the resilience discipline are a subset of the principles described by Jackson and Ferris (2013) which have been determined to be appropriate for a given system, threat, and desired state of resilience as determined by the state-transition analysis described below. The processes requiring these outputs are the system design and system architecture processes.
 
  
−
=====Inputs=====
+
*'''Customer Interface Organizations:''' These are organizations with titles such as Marketing and Customer Engineering. They have the most direct interface with current or potential clientele. Their role is to determine customer needs and communicate these needs to the SE organization for conversion to product requirements and other system requirements. Kossiakoff and Sweet (2003, 173) discuss the importance of understanding customer needs.
−
Inputs to the state model described in Jackson, Cook, and Ferris (2015) include (1) type of system of interest, (2) nature of threats to the system (earthquakes, terrorist threats, human error, etc.) (3) techniques for potential architectural design, and (4) predicted probability of success of individual techniques.
 
  
−
===Dependencies===
+
*'''Contracts Organizations:''' These organizations interface with both customer and supplier organizations. Their role is to develop clearly stated contracts for the developer or the supplier. These contracts convey tasks and responsibilities for all SE roles of all parties. Technical specifications are attached to the contracts. Responsibilities for verification and validation are specified.  
−
The techniques identified for the achieving resilience may also be used by other systems engineering areas of concern such as safety, reliability, human factors, availability, maintainability, human factors, security, and others.    For example, the physical redundancy technique may help achieve resilience, reliability, and safety. Resilience design and analysis should be conducted in concert with the various ‘ilities. The goal being to create a system which -- from the beginning -- meets the requirements for resilience and other ‘ilities.
 
  
−
==Discipline Standards==
+
*'''Supplier Management Organizations:''' These organizations are responsible for selecting and managing suppliers and assuring that both contractual and technical products are in place. These organizations balance cost and risk to assure that supplier products are delivered, verified, and validated for quality product.  Blanchard and Fabrycky (2005, 696-698) discuss the importance of supplier selection and agreement.
−
ASIS (2009) has published a standard pertaining to the resilience of organizational systems.  
 
  
−
NIST 800-160 considers resilience of physical systems.
+
==References==  
−
 
 
−
==Personnel Considerations==
 
−
Humans are important components of systems for which resilience is desired. This aspect is reflected in the human in the loop technique identified by Jackson and Ferris (2013).  Decisions made by the humans are at the discretion of the humans in real time. Apollo 11 described by Eyles (2009) is a good example.
 
−
 
 
−
==Metrics==
 
−
Uday & Marais (2015) performed a survey of resilience metrics.  Those identified include:
 
−
* Time duration of failure
 
−
* Time duration of recovery
 
−
* Ratio of performance recovery to performance loss
 
−
* A function of speed of recovery
 
−
* Performance before and after the disruption and recovery actions
 
−
* System importance measures
 
−
 
 
−
Jackson (2016) developed a metric to evaluate various systems in four domains: aviation, fire protection, rail, and power distribution, for the principles that were lacking in ten different case studies. The principles are from the set identified by Jackson and Ferris (2013) and are represented in the form of a histogram plotting principles against frequency of omission. The data in these gaps were taken from case studies in which the lack of principles was inferred from recommendations by domain experts in the various cases cited.
 
−
 
 
−
Brtis (2016) surveyed and evaluated a number of potential resilience metrics and identified the following: [Note: This reference is going through approval for public release and should be referenceable by the end of July 2016.]
 
−
 
 
−
* Maximum outage period
 
−
* Maximum brownout period
 
−
* Maximum outage depth
 
−
* Expected value of capability: the probability-weighted average of capability delivered
 
−
* Threat resiliency (the time integrated ratio of the capability provided divided by the minimum needed capability)
 
−
* Expected availability of required capability (the likelihood that for a given adverse environment the required capability level will be available)
 
−
* Resilience levels (the ability to provide required capability in a hierarchy of increasingly difficult adversity)
 
−
* Cost to the opponent
 
−
* Cost-benefit to the opponent
 
−
* Resource resiliency (the degradation of capability that occurs as successive contributing assets are lost)
 
−
 
 
−
Brtis found that multiple metrics may be required, depending on the situation.  However, if one had to select a single most effective metric for reflecting the meaning of resilience, it would be the expected availability of the required capability.  Expected availability of the required capability is the probability-weighted sum of the availability summed across the scenarios under consideration. In its most basic form, this metric can be represented mathematically as:
 
−
 
 
−
<math>
 
−
    R = \sum_{1}^{n} \left ( \frac{^{P_{i}}}{T} \int_{0}^{T} Cr(t)_{i}, dt\right )
 
−
    </math>
 
−
where,
 
−
 
 
−
R = Resilience of the required capability (Cr);
 
−
 
 
−
n = the number of exhaustive and mutually exclusive adversity scenarios within a context (n can equal 1);
 
−
 
 
−
Pi = the probability of adversity scenario I;
 
−
 
 
−
Cr(t)_i = timewise availability of the required capability during scenario I;  --- 0 if below the required level  --- 1 if at or above the required value (Where circumstances dictate this may take on a more complex,  non-binary function of time.);
 
−
 
 
−
T = length of the time of interest.
 
−
 
 
−
==Models==
 
−
The state-transition model described by Jackson et al (2015) describes a system in its various states before, during, and after an encounter with a threat. The model identifies seven different states as the system passes from a nominal operational state to minimally acceptable functional state as shown in the figure below. In addition, the model identifies 28 transition paths from state to state. To accomplish each transition the designer must invoke one or more of the 34 principles or support principles described by Jackson and Ferris (2013). The designs implied by these principles can then be entered into a simulation to determine the total effectiveness of each design.
 
−
 
 
−
[[File:StateTransitionModel.png|thumb|center|600px|'''Figure 2. State-Transition Model.''' (SEBoK Original)]]
 
−
 
 
−
==Tools==
 
−
 
 
−
No tools dedicated to resilience have been identified.
 
−
 
 
−
==Practical Considerations==
 
−
 
 
−
===Pitfalls===
 
−
 
 
−
Information to be provided at a later date.
 
−
 
 
−
===Proven Practices===
 
−
 
 
−
Information to be provided at a later date.
 
−
 
 
−
===Other Considerations===
 
−
 
 
−
Information to be provided at a later date.
 
−
 
 
−
==References==
 
 
===Works Cited===
 
===Works Cited===
−
9/11 Commission. (2004). 9/11 Commission Report.
+
Blanchard, B. and W. Fabrycky.  2005.  ''Systems Engineering and Analysis,'' 4th ed. Upper Saddle River, NJ, USA: Prentice Hall.
  
−
ASIS International. (2009). Organizational Resilience: Security, Preparedness, and Continuity Management Systems--Requirements With Guidance for Use. Alexandria, VA, USA: ASIS International.
+
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations." In A.P. Sage and W.B. Rouse (eds.), ''Handbook of Systems Engineering and Management,'' 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
  
−
Billings, C. (1997). Aviation Automation: The Search for Human-Centered Approach. Mahwah, NJ: Lawrence Erlbaum Associates.
+
Construction Management (CM) Guide. 2009. ''Project Organization Types''. Accessed on September 14, 2011. Available at http://cmguide.org/archives/319.
  
−
Bodeau, D. K, & Graubart, R. (2011). Cyber Resiliency Engineering Framework, MITRE Technical Report #110237, The MITRE Corporation.
+
DAU. 2001. ''Systems Engineering Fundamentals''. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU), U.S. Department of Defense (DoD). Accessed on September 14, 2011. Available at http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf.
  
−
Brtis, J. S. (2016). How to Think About Resilience, MITRE Technical Report, MITRE Corporation.
+
Eisner, H. 2008. ''Essentials of Project and Systems Engineering Management'', 3rd ed. Hoboken, NJ, USA: John Wiley & Sons.
  
−
Hollnagel, E., D. Woods, and N. Leveson (eds). 2006. ''Resilience Engineering: Concepts and Precepts.'' Aldershot, UK: Ashgate Publishing Limited.
+
Elliott et al. 2008. ''INCOSE UK Chapter Working Group on Applying Systems Engineering to In-Service Systems''.  Final Report. Somerset, UK: INCOSE UK Chapter Working Group. Accessed September 6, 2011. Available at http://www.incoseonline.org.uk/Documents/Groups/InServiceSystems/is_tr_001_final_report_final_1_0.pdf.
  
−
INCOSE (2015). Systems Engineering Handbook, a Guide for System Life Cycle Processes and Activities. San Diego, Wiley.
+
Fasser, Y. and D. Brettner. 2002. ''Management for Quality in High-Technology Enterprises''. Hoboken, NJ, USA: John Wiley & Sons.
  
−
Jackson, S., & Ferris, T. (2013). Resilience Principles for Engineered Systems. Systems Engineering, 16(2), 152-164.
+
ISO/IEC. 2000. ''International standards for quality management.'' Genève, Switzerland: International Organization for Standardization. ISO 9000:2000.
  
−
Jackson, S., Cook, S. C., & Ferris, T. (2015). A Generic State-Machine Model of System Resilience. Insight, 18.
+
ISO/IEC. 2008. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.
  
−
Jackson, S. & Ferris, T. L. (2016). Proactive and Reactive Resilience: A Comparison of Perspectives.
+
Kasser, J., D. Hitchins, and T. Huynh. 2009. "Re-engineering Systems Engineering." Proceedings of the 3rd Annual Asia-Pacific Conference on Systems Engineering (APCOSE). 20-23 July 2009. Singapore.
  
−
Jackson, W. S. (2016). Evaluation of Resilience Principles for Engineered Systems. Unpublished PhD, University of South Australia, Adelaide, Australia.
+
Kossiakoff, A., and W.N. Sweet. 2003. ''Systems Engineering: Principles and Practice''. Edited by A. Sage, Wiley Series in Systems Engineering and Management. Hoboken, NJ: John Wiley & Sons.
  
−
Leveson, N. (1995). Safeware: System Safety and Computers. Reading, Massachusetts: Addison Wesley.
+
PMI. 2013. ''[[A Guide to the Project Management Body of Knowledge|A Guide to the Project Management Body of Knowledge (PMBOK® Guide)]]'', 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
  
−
Madni, Azad,, & Jackson, S. (2009). Towards a conceptual framework for resilience engineering. Institute of Electrical and Electronics Engineers (IEEE) Systems Journal, 3(2), 181-191.
+
Rechtin, E. 1991. ''Systems Architecting: Creating and Building Complex Systems.'' Englewood Cliffs, NJ, USA: CRC Press.
  
−
Pariès, J. (2011). Lessons from the Hudson. In E. Hollnagel, J. Pariès, D. D. Woods & J. Wreathhall (Eds.), Resilience Engineering in Practice: A Guidebook. Farnham, Surrey: Ashgate Publishing Limited.
+
Ring, J. and A.W. Wymore (eds.). 2004. ''Concept of Operations (conops) of A Systems Engineering Education Community (SEEC)''. Seattle, WA, USA: INCOSE Education Measurement Working Group (EMWG), INCOSE-TP-2003-015-01.  
  
−
Perrow, C. (1999). Normal Accidents: Living With High Risk Technologies. Princeton, NJ: Princeton University Press.
+
SEI. 2010. ''Capability Maturity Model Integrated (CMMI) for Development,'' version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
  
−
Reason, J. (1997). Managing the Risks of Organisational Accidents. Aldershot, UK: Ashgate Publishing Limited.
+
Sheard, S. 1996. "12 Systems Engineering Roles." Paper presented at the Sixth Annual International Council on Systems Engineering (INCOSE) International Symposium. 7-11 July 1996. Boston, MA, USA.
  
−
Rechtin, E. (1991). Systems Architecting: Creating and Building Complex Systems. Englewood Cliffs, NJ: CRC Press.
+
Sheard, S. 2000. "The 12 Systems Engineering Roles Revisited." Paper presented at the INCOSE Mid-Atlantic Regional Conference. April 2000. Reston, VA, USA. p 5.2-1 - 5.2-9.
  
−
US-Canada Power System Outage Task Force. (2004). Final Report on the August 14, 2003 Blackout in the United States and Canada: Causes and Recommendations. Washington-Ottawa.
+
Sillitto, H. 2011a. "Unravelling Systems Engineers from Systems Engineering - Frameworks for Understanding the Extent, Variety and Ambiguity of Systems Engineering and Systems Engineers." Paper presented at the 21st Annual International Council on Systems Engineering (INCOSE) International Symposium. 20-23 June 2011. Denver, CO, USA.
  
−
Uday, P., & Morais, K. (2015). Designing Resilient Systems-of-Systems: A Survey of Metrics, Methods, and Challenges. Systems Engineering, 18(5), 491-510.
+
Sillitto, H. 2011b. ''Sharing Systems Engineering Knowledge through INCOSE: INCOSE as An Ultra-Large-Scale System?'' INCOSE ''Insight.'' 14(1) (April): 20.  
  
−
Warfield, J. N. (2008) "A Challenge for Systems Engineers: To Evolve Toward Systems Science" INCOSE INSIGHT, Volume 11, Issue 1, January 2008.
+
Warfield, J. 2006. ''An Introduction to Systems Science''. Washington, DC, USA:  The National Academies Press, World Scientific.
  
 
===Primary References===
 
===Primary References===
−
Hollnagel, E., Woods, D. D., & Leveson, N. (Eds.). (2006). [[Resilience Engineering: Concepts and Precepts]]. Aldershot, UK: Ashgate Publishing Limited.
+
Eisner, H. 2008. ''[[Essentials of Project and Systems Engineering Management]]'', 3rd ed. Hoboken, NJ, USA: John Wiley and Sons.
−
 
 
−
Jackson, S., & Ferris, T. (2013). [[Resilience Principles for  Engineered Systems]]. Systems Engineering, 16(2), 152-164.
 
  
−
Jackson, S., Cook, S. C., & Ferris, T. (2015). [[Towards a Method to Describe Resilience to Assist in System Specification]]. Paper presented at the INCOSE Systems 2015. 
+
Kotter, J. 1995. "[[Leading Change]]: Why Transformation Efforts Fail''." ''Harvard Business Review''. 73(2): 59–67.''
  
−
Jackson, S.: [[Principles for Resilient Design - A Guide for Understanding and Implementation]]. Available at https://www.irgc.org/irgc-resource-guide-on-resilience Accessed 18th August 2016
+
Sheard, S. 2000.  "[[Systems Engineering Roles Revisited]]." Paper presented at the INCOSE Mid-Atlantic Regional Conference. April 5-8 2000. Reston, VA, USA. p 5.2-1 - 5.2-9.
−
 
 
−
Madni, Azad,, & Jackson, S. (2009). [[Towards a conceptual framework for resilience engineering]]. Institute of Electrical and Electronics Engineers (IEEE) Systems Journal, 3(2), 181-191.
 
  
 
===Additional References===
 
===Additional References===
 +
Blanchard, B. and W. Fabrycky.  2005.  ''Systems Engineering and Analysis,'' 4th edition. Upper Saddle River, NJ, USA: Prentice Hall.
  
−
ASIS International. 2009. Organisational Resilience: Security, Preparedness, and Continuity Management Systems--Requirements With Guidance for Use. Alexandria, VA, USA: ASIS International.
+
Construction Management (CM) Guide. 2009. ''Project Organization Types.''  Accessed on September 6, 2011. Available at http://cmguide.org/archives/319.
−
 
 
−
Billings, Charles. 1997. Aviation Automation: The Search for Human-Centered Approach. Mahwah, NJ: Lawrence Erlbaum Associates.
 
−
 
 
−
Bodeu, D. K., and R. Graubart. 2011. Cyber Resiliency Engineering Framework.
 
−
 
 
−
Eyles, Don. 2009. "1202 Computer Error Almost Aborted Lunar Landing." Massachusetts Intitute of Technology, MIT News, accessed 6 April http://njnnetwork.com/2009/07/1202-computer-error-almost-aborted-lunar-landing/
 
−
 
 
−
Henry, Devanandham, and Emmanual Ramirez-Marquez. 2016. "On the Impacts of Power Outages during Hurrican Sandy -- A Resilience Based Analysis."  Systems Engineering 19 (1):59-75.
 
−
 
 
−
OED. 1973. The Shorter Oxford English Dictionary on Historical Principles. edited by C. T. Onions. Oxford: Oxford Univeristy Press. Original edition, 1933.
 
−
 
 
−
Pariès, Jean. 2011. "Lessons from the Hudson." In Resilience Engineering in Practice: A Guidebook, edited by Erik Hollnagel, Jean Pariès, David D. Woods and John Wreathhall, 9-27. Farnham, Surrey: Ashgate Publishing Limited.
 
−
 
 
−
Rechtin, Eberhardt. 1991. Systems Architecting: Creating and Building Complex Systems. Englewood Cliffs, NJ: CRC Press.
 
−
 
 
−
Uday, Payuna, and Karen Morais. 2015. "Designing Resilient Systems-of-Systems: A Survey of Metrics, Methods, and Challenges."  Systems Engineering 18 (5):491-510.
 
  
 +
Defense Acquisition University (DAU). 2001. ''Systems Engineering Fundamentals.'' Fort Belvoir, VA, USA: Defense Acquisition University Press. Accessed on September 6, 2011. Available at http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf.
  
 +
Handy, C.B. 1985. ''Understanding Organizations.'' London, UK: Penguin Business.
 
----
 
----
−
<center>[[Electromagnetic Interference/Electromagnetic Compatibility|< Previous Article]] | [[Systems Engineering and Specialty Engineering|Parent Article]] | [[Manufacturability and Producibility|Next Article >]]</center>
+
<center>[[Determining Needed Systems Engineering Capabilities in Businesses and Enterprises|< Previous Article]] | [[Enabling Businesses and Enterprises|Parent Article]] | [[Assessing Systems Engineering Performance of Business and Enterprises|Next Article >]]</center>
−
 
 
  
 +
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
  
−
[[Category: Part 6]][[Category:Topic]]
+
[[Category: Part 5]][[Category:Topic]]
−
[[Category:Systems Engineering and Specialty Engineering]]
+
[[Category:Enabling Businesses and Enterprises]]
−
{{DISQUS}}
 

Revision as of 04:46, 9 November 2019

Lead Authors: Richard Beasley, Art Pyster, Hillary Sillitto, Contributing Authors: Alice Squires, Heidi Davidz, Scott Jackson, Quong Wang

In order for a businessbusiness or enterpriseenterprise to perform systems engineeringsystems engineering (SE) well, the team must decide which specific SE capabilities the business or enterprise needs in order to be successful and then organizing to deliver those capabilities. (In the rest of this article, business or enterprise is usually abbreviated to just "business", because a business is a specific type of enterprise that has sufficiently strong central authority and motivation to take steps to enable SE).

SE capabilities and organizational approach should support the Systems Engineering Organizational Strategy and reflect the nature of the business, its products and services, various stakeholders, business leadership focus, etc. This topic, which is part of Part 5, Enabling Businesses and Enterprises, summarizes the factors used to organize a business to perform SE.

Components of Business and Enterprise SE Capability

Organization Issues - Culture, Knowledge, Information, and Infrastructure

The way SE is managed is described in Systems Engineering Organizational Strategy, which both impacts and responds to the SE culture and approach.

Knowledge and Information

Knowledge and Information are key assets in a business, and their management is critical. Fasser and Brettner (2002) discuss knowledge management extensively. They assert that “We may think that knowledge transfer is just an information technology issue, but in actuality, it is also a psychological, cultural, and managerial issue – in short a human issue” and “Only information in action can create knowledge”.

Organizations need to manage SE know-how, integration of SE with other organizational processes and activities, and knowledge of their business domain. The INCOSE Intelligent Enterprise Working Group's work on knowledge management in an SE context led to the publication of a “Concept of Operations for a Systems Engineering Educational Community” (Ring et al. 2004).

Information has to be both shared and protected in complex organizations. Sharing is key to effective collaboration and is constrained by the need to protect intellectual property, as well as commercially and nationally sensitive material. Different cultures and personal styles use information in different ways and in different orders. (Levels of abstraction, big picture first or detail, principles first or practical examples, etc.) Sillitto (2011b) describes the knowledge management challenges for large, multi-national organizations.

Projects need to manage project information and establish configuration control over formal contractual information, as well as the information that defines the product/service being developed, supplied, or operated. A key role of systems engineers is to “language the project” (Ring et al. 2004). Good data management and tool support will allow people to document once, use many times, and ensures consistency of information over time and between different teams.

System information needs to be maintained throughout the life of the system and made available to relevant stakeholders – including those designing new systems that must interface to the system-of-interest - to allow system management, maintenance, reconfiguration, upgrade and disposal, and forensics after accidents and near-misses. Elliott et al. (2008) suggest that information management is the dominant problem in SE in service systems, and that the cost and difficulty of establishing current state and legacy constraints before starting to implement a change is often underestimated.

"Infostructure" (information infrastructure) to support the system lifecycle will include the following:

  • Information assets such as process libraries, document templates, preferred parts lists, component re-use libraries, as-specified and as-tested information about legacy systems, capitalized metrics for organizational performance on previous similar projects, all with appropriate configuration control
  • Modeling and simulation tools, data sets and run-time environments
  • Shared working environments – workspaces for co-located teams, areas for people to interact with each other to develop ideas and explore concepts, work areas suitable for analysis tasks, meeting rooms, access control provision, etc.
  • IT facilities - computer file structures, software licenses, IT equipment, computer and wall displays to support collaborative working, printers, all with appropriate security provision and back-up facilities, procedures for efficient use, and acceptable performance and usability
  • Security provisions to protect own, customer, supplier and third party IPR and enforce necessary protective working practices while allowing efficient access to information for those with a need to know

SE is a knowledge activity. Systems engineers need appropriate facilities for accessing, sharing and capturing knowledge, as well as for interacting effectively with the whole set of stakeholders. Warfield (2006) describes collaborative workspaces, environments and processes for developing a shared understanding of a problem situation.

Enabling Infrastructure

The ISO/IEC 15288 (ISO 2008) Infrastructure Management Process provides the enabling infrastructure and services to support organization and project objectives throughout the life cycle. Infrastructure to support the system life cycle will often include the following:

  • Integration and test environment – bench and lab facilities, facilities for development testing as well as acceptance testing at various levels of integration, calibration and configuration management of test environments
  • Trials and validation environment – access to test ranges, test tracks, calibrated targets, support and storage for trials – equipment, harbor, airfield and road facilities, safe storage for fuel, ordinance, etc.
  • Training and support infrastructure – training simulators, embedded training, tools and test equipment for operational support and maintenance, etc.

People

The roles people fill are typically defined by the business/enterprise (see Determining Needed Systems Engineering Capabilities in Businesses and Enterprises), although those decisions may be pushed down to teams. Enabling Teams explains how people are used in teams; Enabling Individuals describes the development of an individual's SE competence.

The implementation of these roles needs further consideration. Sheard (1996) lists twelve system engineering roles. Sheard (2000) draws an important distinction between roles involved in the discovery phase, characterized by a high level of uncertainty, the program phase, which is more deterministic and defined, and the overall systems engineering approach. Kasser et al. (2009) identify five types of systems engineer distinguished by the need to work at increasing levels of abstraction, ambiguity, scope and innovation. Sillitto (2011a) discusses a number of SE roles and the characteristics required of them, in the context of the wider engineering and business professional landscape.

Systems engineering exists within an enterprise “ecosystem.” Two key aspects to consider:

  • How much should the business/enterprise nurture and value the systems engineer?
  • How much should the business/enterprise pull value from systems engineers, rather than wait for systems engineers to "push" value on the business/enterprise?

Process

Many SE organizations maintain a set of organizational standard processes which are integrated in their quality and business management system, adapted to their business, and with tailoring guidelines used to help projects apply the standard processes to their unique circumstances. Guidance on organizational process management is provided by such frameworks as the Capability Maturity Model Integration (CMMI) (SEI 2010), which has two process areas on organizational process: Organizational Process Development (OPD) is concerned with organizational definition and tailoring of the SE lifecycle processes (discussed in detail elsewhere in this document) and Organizational Process Focus (OPF), which is concerned with establishing a process culture in an organization.

To document, assess, and improve SE processes, businesses often establish a systems engineering process group. Members of such groups often create standard process assets and may mentor teams and business units on how to adopt those standard processes and assess how effective those processes are working. There is a large body of literature on SE process improvement based on various process improvement models. Two of the most popular are ISO/IEC 9000 (2000) and CMMI (SEI 2010). The Software Engineering Institute, which created the CMMI, offers many free technical reports and other documents on CMMI at http://www.sei.cmu.edu/cmmi.

Assessment and measuring process performance is covered in Assessing Systems Engineering Performance of Business and Enterprises.

Tools and Methods

SE organizations often invest in SE tools and models, develop their own, and/or integrate off-the-shelf tools into their particular business/enterprise processes. Tools require great attention to culture and training; to developing a consistent “style” of use so that people can understand each others’ work; and proper configuration and management of the information so that people are working on common and correct information.

It is important that methods are used as well as tools, particularly to support Systems Thinking.

It is common practice in large SE organizations to have a tool support infrastructure which ensures that tools support the organizational standard processes and are fully integrated with training, and that projects and teams can use the tools to do their job and are not distracted by tool management issues that are more efficiently handled centrally. Smaller SE organizations often operate more informally.

Fitting It All Together

The concept map in Figure 1 below shows the relationships between the various aspects of organization, resource, responsibility, and governance.

Figure 1. Businesses, Teams, and Individuals in SE. (SEBoK Original)

Enterprise Structures and Their Effects on SE

Enterprises manage SE resources in many different ways. A key driver is the extent to which they seek to optimize use of resources (people, knowledge, and assets) across teams and across the enterprise as a whole. Five common ways of organizing resources to support multiple projects are: project; matrix; functional; integrated; and product centered (CM Guide 2009, Handy 1985, PMI 2013, section 2.1.3). A large enterprise would likely apply some combination of these five ways across its constituent sub-enterprises and teams. Browning (2009) offers a way to optimize project organizational structure. Eisner (2008) offers a good overview of different organizational models.

Project Organization

A project organization is one extreme in which projects are responsible for hiring, training, and terminating staff, as well as managing all assets required for delivery. In this model, systems engineers on a project report to the project manager and resources are optimized for the delivery of the project. This model has the advantage of strongly aligning the authority and responsibility of the project with the project manager. However, it operates at the expense of sub-optimizing how the staff is deployed across the larger enterprise, how technology choices are made across projects, etc. Systems Engineering Fundamentals (DAU 2001) offers a DoD view of good practice project organizations.

Functional Organization

A functional organization demonstrates the opposite extreme. In a functional organization, projects delegate almost all their work to functional groups, such as the software group, the radar group or the communications group. This is appropriate when the functional skill is fast-evolving and dependent on complex infrastructure. This method is often used for manufacturing, test engineering, software development, financial, purchasing, commercial, and legal functions.

Matrix Organization

A matrix organization is used to give systems engineers a “home” between project assignments. Typically, a SE functional lead is responsible for career development of the systems engineers in the organization, a factor that influences the diversity and length of individual project assignments.

Integrated Organization

In an integrated organization, people do assigned jobs without specific functional allegiance. Those that perform SE tasks are primarily identified as another type of engineer, such as a civil or electrical engineer. They know systems engineering and use it in their daily activities as required.

Product Centered Organization

In accordance with the heuristicheuristic that “the product and the process must match” (Rechtin 1991, 132), a common method for creating an organizational structure is to make it match the system breakdown structure (SBS)system breakdown structure (SBS). According to Browning (2009), at each element of the SBS there is an assigned integrated product team (IPT)integrated product team (IPT). Each IPT consists of members of the technical disciplines needed to design the product system. The purpose of the IPT is to assure that the interactions among all the technical disciplines are accounted for in the design and that undesirable interactions are avoided.

Interface to Other Organizations

Outside official engineering and SE organizations within an enterprise, there are other organizations whose charter is not technical. Nevertheless, these organizations have an important SE role.

  • Customer Interface Organizations: These are organizations with titles such as Marketing and Customer Engineering. They have the most direct interface with current or potential clientele. Their role is to determine customer needs and communicate these needs to the SE organization for conversion to product requirements and other system requirements. Kossiakoff and Sweet (2003, 173) discuss the importance of understanding customer needs.
  • Contracts Organizations: These organizations interface with both customer and supplier organizations. Their role is to develop clearly stated contracts for the developer or the supplier. These contracts convey tasks and responsibilities for all SE roles of all parties. Technical specifications are attached to the contracts. Responsibilities for verification and validation are specified.
  • Supplier Management Organizations: These organizations are responsible for selecting and managing suppliers and assuring that both contractual and technical products are in place. These organizations balance cost and risk to assure that supplier products are delivered, verified, and validated for quality product. Blanchard and Fabrycky (2005, 696-698) discuss the importance of supplier selection and agreement.

References

Works Cited

Blanchard, B. and W. Fabrycky. 2005. Systems Engineering and Analysis, 4th ed. Upper Saddle River, NJ, USA: Prentice Hall.

Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations." In A.P. Sage and W.B. Rouse (eds.), Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.

Construction Management (CM) Guide. 2009. Project Organization Types. Accessed on September 14, 2011. Available at http://cmguide.org/archives/319.

DAU. 2001. Systems Engineering Fundamentals. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU), U.S. Department of Defense (DoD). Accessed on September 14, 2011. Available at http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf.

Eisner, H. 2008. Essentials of Project and Systems Engineering Management, 3rd ed. Hoboken, NJ, USA: John Wiley & Sons.

Elliott et al. 2008. INCOSE UK Chapter Working Group on Applying Systems Engineering to In-Service Systems. Final Report. Somerset, UK: INCOSE UK Chapter Working Group. Accessed September 6, 2011. Available at http://www.incoseonline.org.uk/Documents/Groups/InServiceSystems/is_tr_001_final_report_final_1_0.pdf.

Fasser, Y. and D. Brettner. 2002. Management for Quality in High-Technology Enterprises. Hoboken, NJ, USA: John Wiley & Sons.

ISO/IEC. 2000. International standards for quality management. Genève, Switzerland: International Organization for Standardization. ISO 9000:2000.

ISO/IEC. 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.

Kasser, J., D. Hitchins, and T. Huynh. 2009. "Re-engineering Systems Engineering." Proceedings of the 3rd Annual Asia-Pacific Conference on Systems Engineering (APCOSE). 20-23 July 2009. Singapore.

Kossiakoff, A., and W.N. Sweet. 2003. Systems Engineering: Principles and Practice. Edited by A. Sage, Wiley Series in Systems Engineering and Management. Hoboken, NJ: John Wiley & Sons.

PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

Rechtin, E. 1991. Systems Architecting: Creating and Building Complex Systems. Englewood Cliffs, NJ, USA: CRC Press.

Ring, J. and A.W. Wymore (eds.). 2004. Concept of Operations (conops) of A Systems Engineering Education Community (SEEC). Seattle, WA, USA: INCOSE Education Measurement Working Group (EMWG), INCOSE-TP-2003-015-01.

SEI. 2010. Capability Maturity Model Integrated (CMMI) for Development, version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).

Sheard, S. 1996. "12 Systems Engineering Roles." Paper presented at the Sixth Annual International Council on Systems Engineering (INCOSE) International Symposium. 7-11 July 1996. Boston, MA, USA.

Sheard, S. 2000. "The 12 Systems Engineering Roles Revisited." Paper presented at the INCOSE Mid-Atlantic Regional Conference. April 2000. Reston, VA, USA. p 5.2-1 - 5.2-9.

Sillitto, H. 2011a. "Unravelling Systems Engineers from Systems Engineering - Frameworks for Understanding the Extent, Variety and Ambiguity of Systems Engineering and Systems Engineers." Paper presented at the 21st Annual International Council on Systems Engineering (INCOSE) International Symposium. 20-23 June 2011. Denver, CO, USA.

Sillitto, H. 2011b. Sharing Systems Engineering Knowledge through INCOSE: INCOSE as An Ultra-Large-Scale System? INCOSE Insight. 14(1) (April): 20.

Warfield, J. 2006. An Introduction to Systems Science. Washington, DC, USA: The National Academies Press, World Scientific.

Primary References

Eisner, H. 2008. Essentials of Project and Systems Engineering Management, 3rd ed. Hoboken, NJ, USA: John Wiley and Sons.

Kotter, J. 1995. "Leading Change: Why Transformation Efforts Fail." Harvard Business Review. 73(2): 59–67.

Sheard, S. 2000. "Systems Engineering Roles Revisited." Paper presented at the INCOSE Mid-Atlantic Regional Conference. April 5-8 2000. Reston, VA, USA. p 5.2-1 - 5.2-9.

Additional References

Blanchard, B. and W. Fabrycky. 2005. Systems Engineering and Analysis, 4th edition. Upper Saddle River, NJ, USA: Prentice Hall.

Construction Management (CM) Guide. 2009. Project Organization Types. Accessed on September 6, 2011. Available at http://cmguide.org/archives/319.

Defense Acquisition University (DAU). 2001. Systems Engineering Fundamentals. Fort Belvoir, VA, USA: Defense Acquisition University Press. Accessed on September 6, 2011. Available at http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf.

Handy, C.B. 1985. Understanding Organizations. London, UK: Penguin Business.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=System_Resilience&oldid=57872"