Enabling Systems Engineering

Part 5 of the Guide to the SE Body of Knowledge (SEBoK) is a guide to knowledge about how an enterprise prepares and positions itself to effectively perform the systems engineering (SE) activities described elsewhere in the SEBoK.

Figure 1 SEBoK Part 5 in context (SEBoK Original). For more detail see Structure of the SEBoK

SE activities—how to develop requirements, select an appropriate life cycle model, and architect a system of systems, and so on—are covered elsewhere, especially in Part 3, Systems Engineering and Management. An organization that desires to do these things effectively must work through questions like whether to allow a project manager to select the systems engineers he or she employs, and, if so, what competencies the project manager might seek in those systems engineers. These are the kinds of questions that Part 5 explores.

The discussion defines three levels of organization: enterprise or business, team, and individual. To adapt an example to a more complex organizational structure, simply decompose enterprises into sub-enterprises and teams into sub-teams, as needed. For more about the different types of enterprises, see Types of Systems in Part 2.

Knowledge Areas in Part 5

Each part of the SEBoK is composed of knowledge areas (KA). Each KA groups topics around a theme related to the overall subject of the part.

The KAs in Part 5 explore how to enable an organization to perform SE:

• Enabling Businesses and Enterprises
• Enabling Teams
• Enabling Individuals

Common Practices

There are as many different ways to enable SE performance as there are organizations, and every organization's approach is detailed and unique. Nevertheless, common practices, methods, and considerations do exist. Part 5 uses them as a framework to structure the relevant knowledge.

SE activities that support business needs and deliver value are enabled by many factors, including

• Culture (see Culture),
• SE competencies (see Determining Needed Systems Engineering Capabilities in Businesses and Enterprises) and how the organization grows and deploys its workforce to acquire them, and
• SE tooling and infrastructure (see Systems Engineering and Management in Part 3).

Enterprises and Businesses

The fact that Part 5 uses two terms, “Enterprise” and “Business,” to name a single level of organization, indicates that the two are closely related. In many contexts it is not necessary to make any distinction between them: an enterprise may be a traditional business, and a business can be seen as a special type of enterprise. For the sake of brevity, the term “business” is used to mean “business or enterprise” throughout most of Part 5.

Traditional businesses usually have a legal structure and a relatively centralized control structure. Such a business may be a corporation, or a unit of a company or government agency, that creates a product line or offers services.

On the other hand, an enterprise can be structured in a way that excludes description as a business. This happens when the enterprise crosses traditional business boundaries, lacks a centralized legal authority, and has relatively loose governance. One example is the healthcare system in the US which encompasses hospitals, insurance companies, medical equipment manufacturers, pharmaceutical companies, and government regulators. Another is the set of companies that form the supply chain for a manufacturer, such as the thousands of companies whose parts and services Apple uses to create, distribute, and support the iPhone.

Significant actions that enable SE are often conducted by traditional businesses rather than by less tightly-structured enterprises. Even so, organizational context affects how the business approaches SE and therefore how it enables SE performance. A business that sells to the general commercial marketplace typically has far fewer constraints on its SE practices than one which performs contract work for a government agency. A business that creates systems with very demanding characteristics, such as aircraft, typically has a much more rigorous and planned approach to SE than one which creates less demanding systems, such as an app for a smartphone.

Traditional businesses are intended to be permanent, and typically offer a portfolio of products and services, introduce new ones, retire old ones, and otherwise seek to grow the value of the business. Sometimes a single product or service has such value and longevity that it spawns a business or enterprise just for its creation, maintenance, and support. The Eurofighter Typhoon aircraft, for example, was developed by a consortium of three corporations that formed a holding company specifically to provide support and upgrade services throughout the in-service life of the aircraft.

For more on the distinction between businesses and enterprises and the value of systems engineering of enterprises to them, see Enterprise Systems Engineering in Part 4. Systems of Systems (SoS), also in Part 4, contrasts the tighter control over SE that is usual for businesses with the looser control that is usual for enterprises lacking a traditional business structure. Groupings of Systems in Part 2, discusses the Directed SoS, to which the traditional business may be equivalent.

Teams

Teams operate within the context of the businesses in which they reside. This context determines how the team is enabled to perform SE.

For example, a business may grant a team wide autonomy on key technical decisions, which are made either by systems engineers on the team or in consultation with team systems engineers. On the other hand, the same business could instead create a generic set of SE processes that all teams are to tailor and use, constraining the team to adhere to established business policies, practices, and culture. The business could even require that the team gain approval for its tailored SE process from a higher level technical authority.

Teams are usually formed for a limited duration to accomplish a specific purpose, such as creating a new system or upgrading an existing service or product. Once the purpose has been fulfilled, the team responsible for that effort is usually disbanded and the individuals associated with the effort are assigned to new tasks. Exceptions do happen, however. For example, a team of systems engineers tasked with assisting troubled programs throughout a corporation could persist indefinitely.

References

Works Cited

None.

Primary References

None.

Additional References

None.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus