Determining Needed Systems Engineering Capabilities in Businesses and Enterprises

---

Lead Authors: Richard Beasley, Hillary Sillitto, Scott Jackson, Contributing Authors: Alice Squires, Heidi Davidz, Garry Roedler, Richard Turner, Art Pyster, Ray Madachy

---

Enabling a business or enterprise to perform systems engineering (SE) well requires deciding which specific SE capabilities the business or enterprise needs in order to be successful. (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 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 the Enabling Businesses and Enterprises knowledge area (KA) of Part 5, summarizes the factors used to decide which SE capabilities a business needs; e.g., the interactions between SE and other functional areas in the business, and consideration of social dynamics and leadership at the team and business levels. Needed capabilities may be decided and developed centrally by a business, or within teams and individuals, or through some combination of the two. Determination of team SE capability is discussed in the article Team Capability, and individual SE competencies are discussed in the article Roles and Competencies.

Relationship of this Topic to Enterprise Systems Engineering

Enterprise Systems Engineering and Capability Engineering techniques can be used to establish needed SE capabilities. At a high level of abstraction, the following are basic steps that could be used to decide the desired SE capabilities within the business:

1. understand the context;
2. determine the required SE roles;
3. determine the competencies and capabilities needed for each of the SE roles;
4. assess the ability and availability of the needed SE organizations, teams, and individuals;
5. make adjustments to the required SE roles based on the actual ability and availability; and
6. organize the SE function to facilitate communication, coordination, and performance.

See the article Organizing Business and Enterprises to Perform Systems Engineering for additional information. More information on context and required SE roles is provided below.

Contextual Drivers

The following discussion illustrates some of the contextual factors that influence the definition of the SE capability needed by a business.

Where the SE Activities are Performed in the Value Chain

The SE approach adopted by the business should depend on what role the organization plays. Ring (2002) defines a value cycle, and where the business sits in that cycle is a key influence of SE capability need.

• Problem owner: focus on identifying and scoping the system problem (defining system-of-interest (SoI)(glossary))and understanding the nature of the appropriate respondent system using Enterprise Systems Engineering and Capability Engineering approaches.
• System operator: focus on establishing all the necessary components of capability (glossary) to deliver the required services, as well as on integrating new system assets into the system operation as they become available (see Service Systems Engineering). The definition of the components of capability varies by organization - e.g.,
  • The US Department of Defense defines the components of capability as DOTMLPF: doctrine, organization, training, materiel, logistics, people, and facilities.
  • The UK Ministry of Defense defines the components of capability as TEPIDOIL; i.e., training, equipment, people, information, doctrine, organization, infrastructure, and logistics.
  • Other domains and organizations define the components of capability with similar, equivalent breakdowns which are either explicit or implicit.
• Prime contractor or primary commercial developer: focus on understanding customer needs and trading alternative solution approaches, then establishing a system team and supply chain to develop, deliver, support, and in some cases, operate the system solution. This may require enterprise SE (see Enterprise Systems Engineering) as well as "traditional" product SE (see Product Systems Engineering).
• Subsystem/component developer: focus on understanding the critical customer and system integrator issues for the subsystem or component of interest, define the component or subsystem boundary, and integrate critical technologies. This may exploit re-usable elements and can be sold in identical or modified forms to several customers. (In Part 4 of the SEBoK, see Systems of Systems, Enterprise Systems Engineering, and Product Systems Engineering for more information and references to the literature.)
• Specialist service provider: focus on specific process capabilities and competences which are typically sold on a time and materials or work package basis to other businesses.

Where the Enterprise Operates in the Lifecycle

The SE capabilities required by the business will depend on the system life cycle (glossary) phase(s) in which it operates (see Life Cycle Models in Part 3).

• Concept definition phase: requires the SE capability to identify a “problem situation,” define the context and potential concept of operations for a solution system, assess the feasibility of a range of possible solutions in broad terms, and refine the definition to allow the development of system requirements for the solution (see Concept Definition in Part 3).
• System Definition phase: requires the SE capability to influence concept studies (ensure feasible and understood by the development team), establish the trade space that remains at the end of the concept study, perform the system definition activities, including architecture design, and create a detailed definition of the system elements.
• System realization phase: requires the SE capability to configure the manufacturing and logistics systems for the system assets, and manufacture system assets (see System Realization in Part 3).
• System deployment and use: requires the SE capability to maintain business continuity during the transition to operation, bring the system into service, support system, monitor system performance, and respond to emerging needs (see System Deployment and Use. Elliott et al. (2008) describe the different emphases that should be placed in SE during the "in-service" phase. This phase particularly requires the business to be able to perform SE at an appropriate operational tempo.
• Retirement phase: requires the SE capability for ensuring the safe retirement of systems and keeping them in a state ready for re-activation (“mothballed”), safe disposal of the system assets.

Nature of Responsibility to End Users and Society

Depending on the business model and the contracting environment, the business may find that its responsibility to end users is

• explicit, or spelled out by clear requirements and prescriptive legislation; or

• implicit; i.e., a legal or ethical obligation to ensure “fitness for purpose” which may be enforced by commercial frameworks, national or international standards, and specific product liability legislation.

Typically, businesses whose business model is contract driven focus on satisfying explicit requirements, whereas market-driven businesses have to be more aware of implicit responsibilities.

Nature of Responsibility to Customers

The business may contract with its customers to deliver any of the following:

• an outcome: The intended benefits the system is expected to provide, requires enterprise systems engineering;
• an output: Deliver or operate the system or part of it against agreed acceptance criteria; requires product systems engineering;
• an activity: Perform a specified set of tasks, requires service systems engineering; and
• a resource: Provide a specified resource; requires focus on individual competencies - see Enabling Individuals.

Scale of Systems

The business or enterprise may need very different SE approaches depending on the scale of the system at which the business operates. The following categories are based on Hitchins’ five layered system model (Hitchins 2005):

• Level 1: Subsystem and technical artifacts – focus on product systems engineering and on technology integration.
• Level 2: Project systems – focus on product systems engineering with cross-discipline and human integration.
• Level 3: Business systems – focus on enterprise systems engineering , service systems engineering to implement them, and on service management (Chang 2010) and continuous improvement (SEI 2010b); see also Quality Management) for the day to day running of the business.
• Level 4: Industry systems – If there is a conscious effort to treat an entire industry as a system, the focus will be on Enterprise Systems Engineering, and on the long-term economic and environmental sustainability of the overall industry.
• Level 5: Societal systems – Enterprise systems engineering is used to analyze and attempt to optimize societal systems (see Singapore Water Management in Part 7).

Sillitto (2011) has proposed extending this model to cover sustainability issues by adding two additional layers, the “ecosystem” and the “geosystem”.

Complexity of Systems Integration Tasks and Stupples’ levels

Creating Systems That Work – Principles of Engineering Systems for The 21st century identifies three “kinds” of SE, originally proposed by Stupples (2006), that have to do with the level of cross-disciplinary integration involved (Elliot et al. 2007)

1. Within a discipline (e.g., software, hardware, optics, or mechanics), the SE focus is on taking a systems view of the architecture and implementation to manage complexity and scale within a single engineering discipline.
2. In multiple disciplines (e.g., software, hardware, optics, and mechanics), the SE focus is on holistic integration of multiple technologies and skills to achieve a balanced system solution.
3. In socio-technical systems integration, the SE focus is on getting people and the non-human parts of the system working synergistically.

Sillitto (2011) proposed extending this model properly to cover sustainability issues by adding one additional level, “Environmental Integration”. He describes this level and show how the Stupples’ levels relate to other dimensions used to categorize systems and professional engineering skills.

Criticality of System and Certification Requirements

The level of rigor in the SE approach adopted by the business will depend on the criticality of various classes of requirement. (See Systems Engineering and Specialty Engineering.)

• Safety and security requirements often demand specific auditable processes and proof of staff competence.
• Ethical and environmental requirements may require an audit of the whole supply and value chain.
• Extremely demanding combinations of performance requirements will require more design iteration and more critical control of component characteristics; e.g., see Quality Management and Management for Quality in High-Technology Enterprises (Fasser and Brettner 2010).

The Nature of a Contract or Agreement

The nature of the contractual relationship between a business and its customers and end users will influence the style of SE.

• Fixed price, cost plus, or other contracting models influence the mix of focus on performance and cost control and how the business is incentivized to handle risk and opportunity.
• In mandated work share arrangements, the architecture of the product system may be compromised or constrained by the architecture of a viable business system; this is often the case in multi-national projects and high profile government procurements (Maier and Rechtin 2009, 361-373).
• In self-funded approaches, the priorities will be requirements elicitation approaches designed to discover the latent needs of consumers and business customers, as well as development approaches designed to achieve rapid time to market with a competitive offering, or to have a competitive offering of sufficient maturity available at the most critical time during a customer’s selection process.
• In single phase or whole-life approaches, the business may be able to optimize trade-offs across the development, implementation, and in-service budgets, and between the different components of capability (glossary).

The Nature and Predictability of Problem Domain(s)

Well-defined and slowly-changing technologies, products, and services permit the use of traditional SE life cycle models based on the waterfall model because the requirements risk and change is expected to be low (see Life Cycle Models).

Poorly defined and rapidly changing problem domains, with operators subject to unpredictable and evolving threats, demand more flexible solutions and agile processes. SE should focus on modular architectures that allow rapid reconfiguration of systems and systems-of-systems, as well as rapid deployment of new technologies at a subsystem level to meet new demands and threats.

Fundamental Risks and Design Drivers in the Solution Domain

When the solution domain is stable, with a low rate of technology evolution, and systems use mature technology, the focus is on optimum packaging and configuration of known and usually well-proven building blocks within known reference architectures, and on low-risk incremental improvement over time.

When there is rapid technology evolution, with pressure to bring new technologies rapidly to market and/or into operational use, the SE approach has to focus on technology maturation, proof of technology and integration readiness, and handling the technology risk in the transition from the lab to the proof of concept to the operational system.

There is usually a trade-off between lead time expectations and the level of integrity/certification. In the development of new systems, short lead times are seldom compatible with high levels of system integrity and rigorous certification.

Competitive Situation and Business Goals

The business drivers for SE deployment may be one or more of the following:

• To perform existing business better;
• To recover from a competitive shock or a shift in clients' expectations;
• To develop a new generation product or service;
• To enter a new market; and/or
• To reposition the business or enterprise in the value chain.

In the first case, SE can be deployed incrementally in parts of the business process where early tangible benefits can be realized. This could be the early steps of a business-wide strategic plan for SE. (See Systems Engineering Organizational Strategy for more on setting SE strategy and Developing Systems Engineering Capabilities within Businesses and Enterprises for improving SE capabilities.)

In the other cases, the business is going through disruptive change and the early priority may be to use systems thinking (see Systems Thinking) and enterprise SE approaches to scope the transformation in the context of a major change initiative.

Type of System or Service

There are three distinct flavors of products or service types (see Systems Engineering Organizational Strategy):

1. In a product or productized service, the focus will be on predicting how the market might change during the development period, eliciting, anticipating, and balancing requirements from a variety of potential customers, and optimizing features and product attractiveness against cost and reliability.
2. In a custom solution (product or service) the focus will be on feasible and low-risk (usually) approaches to meet the stated requirement within budget, using system elements and technologies that are known or expected to be available within the desired development timescale.
3. Tailored solutions based on standard product and/or service elements require a much more sophisticated SE process that is able to use a “product line approach” to blend standard modules with planned adaptation to meet clients’ specific needs more quickly and cheaply than would be possible with a single contract solution. The business needs to manage the life cycle and configuration of the standard modules separately from, but coherently with, the life cycle and configuration of each tailored solution.

Needed Systems Engineering Roles

After understanding the context for the business, the next step is to determine the SE capabilities required in the role in the business. The SEI Capability Maturity Models for acquisition, development, and services (SEI 2007; SEI 2010a; SEI 2010b) provide a framework for selecting SE capabilities relevant to different types of business. Existing SE competency models can be used to assist in determining the needed capabilities. An example is the INCOSE SE Competencies Framework (INCOSE 2010). (See Roles and Competencies for more information on competency models.).

There can be a wide spectrum of the spread of SE focus, from SE being focused in a specialist role, an interface or glue role (Sheard 1996), or the idea that “SE is good engineering with special areas of emphasis… including interfaces between disciplines” (Blanchard and Fabrycky 2005) and so it is shared by all. In any organization where activities and skills are shared, there is always a danger of silos or duplication.

As part of the role definition, the business must define where an individual doing SE fits into career progression (what roles before SE, what after?). Developing Individuals describes how individuals improve SE; the organization must define the means by which that development can be enacted. Businesses need to customize from a range of development strategies; see, for example, Davidz and Martin (2011).

As shown in Figure 1 below, management action on workforce development will be required if there are systemic mismatches between the competencies required to perform SE roles and the actual competencies of individuals. The organizational culture may have a positive or negative effect on team performance and the overall value added by the business (see Culture).

Figure 1. Culture, Competence, Team Performance and Individual Competence. (SEBoK Original)

Required SE Processes and Methods

The decisions on how to implement SE capability must be embedded in the businesses processes and its availability methodologies and toolsets. Embedding SE principles, processes, and methods in the organization’s quality management system means that senior management and the quality system will help embed SE in the organizational business process and make sure it is applied (INCOSE 2012; ISO/IEC 2008; see Quality Management).

When defining the processes and tools, a balance between the need for a systematic and standardized approach to SE processes, such as that seen in INCOSE (2012), with the flexibility inherent in systemic thinking is critical. Systems thinking helps the organization understand problem situations, remove organizational barriers, and make the most of the organization’s technical capabilities (see Beasley (2011)).

Need for Clarity in the SE Approach and the Dangers of Implementing SE

Clarity on how the organization does SE is important. Typically, implementing SE may be part of an organization’s improvement, so Kotter’s principles on creating a vision, communicating the vision, and empowering others to act on the vision are extremely relevant (Kotter 1995). The way an organization chooses to do SE should be part of the vision of the organization and must be understood and accepted by all.

Many of the major obstacles in SE deployment are cultural (see Culture).

One of the lean enablers for SE is to "pursue perfection" (Oppenheim et al. 2010). The means of improvement at a business or enterprise level are discussed in detail elsewhere, but the starting point has to be deciding what SE capabilities the organization wants. It needs to be recognized that the needed capabilities change over time (learning, improving, or losing capability). Thus, balancing SE with everything else that it involves is an ever changing process.

References

Works Cited

Beasley, R. 2011. "The Three T's of Systems Engineering." Paper presented at the 21st Annual International Council on Systems Engineering (INCOSE) International Symposium. June 2011. Denver, CO, USA.

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

Chang, C.M. 2010. Service Systems Management and Engineering: Creating Strategic Differentiation and Operational Excellence. Hoboken, NJ, USA: John Wiley and Sons.

Davidz, H. L. and J. Martin. 2011. "Defining a Strategy for Development of Systems Capability in the Workforce." Systems Engineering. 14(2) (Summer, 2011): 141-143

Elliott, B. 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. 2001. Management for Quality in High-Technology Enterprises. New York, NY, USA: Wiley.

Hitchins, D. 2005. Systems Engineering 5 Layer Model. Accessed on April 24,2013. Available at http://www.hitchins.net/systems/world-class-systems-enginee.html.

INCOSE. 2010. SE Competencies Framework, Issue 3. Somerset, UK: International Council on Systems Engineering (INCOSE), INCOSE Technical Product 2010-0205.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

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

Kotter, J. 1995. Leading Change: Why Transformation Efforts Fail. Boston, MA, USA: Harvard Business Review (March–April 1995).

Maier, M. and E. Rechtin. 2009. The Art of System Architecting, Third Edition. Boca Raton, FL, USA: CRC Press.

Oppenheim et al. 2010. Lean Enablers for Systems Engineering. New York, NY, USA: Wiley and Sons, Inc.

Ring J. 2002. Toward an Ontology of Systems Engineering. INSIGHT, 5(1): 19-22

SEI. 2007. CMMI for Acquisition. Version 1.2. Technical Report CMU/SEI-2007-TR-017. Pittsburgh, PA, USA: Software Engineering Institute, Carnegie Mellon University.

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

SEI. 2010b. CMMI for Services. Version 1.3. Technical Report CMU/SEI-2010-TR-034. Pittsburgh, PA, USA: Software Engineering Institute, Carnegie Mellon University.

Sheard, S. 1996. "12 Systems Engineering Roles." Paper presented at the 6th Annual International Council on Systems Engineering (INCOSE) International Symposium. Boston, MA, USA. Accessed September 14, 2011.

Sillitto, H. 2011. "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.

Stupples, D. 2006. "Systems Engineering – a road from perdition." Published on Royal Academy of Engineering website - available at http://www.raeng.org.uk/education/vps/systemdesign/pdf/David_Stupples.pdf

Primary References

Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Chichester, UK: Wiley and Sons, Inc.

Oppenheim, B. 2011. Lean for Systems Engineering - with Lean Enablers for Systems Engineering. Hoboken, NJ, USA: Wiley and Sons, Inc.

Sheard, S. 1996. Twelve Systems Engineering Roles. Paper presented at the 6th Annual International Council on Systems Engineering (INCOSE) International Symposium. Boston, MA, USA. Accessed September 14, 2011.

Additional References

Rhodes, D., and G. Roedler (eds.). 2007. Systems Engineering Leading Indicators Guide, version 1.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2005-001-02.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 2.1, released 31 October 2019