Enabling Systems Engineering
The other Parts of the SEBoK, especially Part 3 on Systems Engineering and Management, are a guide to knowledge about how to perform systems engineering (SE); e.g., about how to develop requirements, select an appropriate life cycle model, and architect a system of systems. Part 5 focuses on what an enterprise needs to do in order to be effective at performing those SE activities described elsewhere in the SEBoK; e.g., whether an organization allows 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.
For purposes of this Part, there are just three levels of an organization defined: the enterprise, a team, and individuals. Enterprises and teams can be decomposed into constituent sub-enterprises and sub-teams indefinitely.
To download a PDF of Part 5, please click here.
Knowledge Areas in Part 5
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The knowledge areas in Part 5 explore how the three levels of an organization enable SE:
Enterprises and Businesses
The introductory paragraphs above noted that Part 5 divides organizations into three levels: enterprise, team, and individual. A business is a special type of enterprise which usually has a legal structure and a relatively centralized control structure; e.g., as a corporation or a unit of a company or government agency that creates a specific product line or offers specific services. An enterprise may be a traditional business, but can also cross traditional business boundaries; e.g., the healthcare system of a nation is an enterprise which does not have a centralized legal authority and has a very loose form of governance involving hospitals, insurance companies, medical equipment manufacturers, pharmaceutical companies, government regulators, etc. Another example of an enterprise which is not a traditional business is the set of companies that form the supply chain for a manufacturer, such as the thousands of companies that contribute parts and services enabling Apple to create, distribute, and support the iPhone. Often significant actions that enable SE are conducted by traditional businesses rather than by less well-structured enterprises. Throughout this article and others in Part 5, the term "business or enterprise" may be shortened to just "business" or "enterprise" depending on the point being made. The reader should look at Enterprise Systems Engineering in Part 4 of the SEBoK for further elaboration on the distinction between businesses and enterprises and the value of systems engineering of enterprises to them. The Part 4 Systems of Systems (SoS) Knowledge Area also provides useful insight into the tighter control over SE that businesses usually have (the equivalent of a Directed SoS) relative to the looser control that enterprises that lack a traditional business structure usually have.
An enterprise operates in an organizational context that affects how it approaches SE and therefore how it enables SE performance; e.g., a business that sells to the general commercial marketplace will typically have many fewer constraints on how it practices SE 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 is creating less demanding systems, such as an app for a smartphone.
Teams
Teams are usually formed for a specific purpose of limited duration, such as creating a new system or upgrading an existing service or product. Once the new system has been created and delivered or the existing service or product has been upgraded and fielded, the team responsible for that effort is usually disbanded and the individuals associated with the effort are assigned to new tasks. For example, the U.S. Federal Aviation Administration formed a team in the last decade to create a new enterprise resource planning system for its operations and dispersed the team after the system was fielded. However, there are exceptions; e.g., a team of systems engineers housed in a corporate office to assist programs throughout the corporation that in trouble could persist indefinitely. On the other hand, businesses typically have permanence. They usually offer a portfolio of products and services, introduce new ones, retire old ones, and otherwise seek to grow the value of the business. In a corporation, management of that portfolio might be centralized under the direction of the corporate executives. In a non-business enterprise, such as a national healthcare system, there may be only loose coordination of execution among many businesses; e.g., a national healthcare system includes physicians, drug companies, hospitals, government regulatory agencies, etc. A business may offer its products and services to a single customer; e.g., a small supplier that makes a single product solely for a large manufacturer. 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; for example, the Eurofighter Typhoon aircraft was developed by a consortium of three companies that formed a holding company specifically for the purpose of providing support and upgrade services throughout the in-service life of the aircraft.
A team operates within the context of the business in which it resides; e.g., a business may choose to give a team a lot of autonomy on key technical decisions, most of which are either made by systems engineers on the team or in consultation with team systems engineers. On the other hand, a team could be constrained by business policies, practices, and culture; e.g., a business could create a generic set of SE processes that all teams are to tailor and use. The business could even require that the team gain approval for its tailored SE process from a higher level technical authority.
Common Practices
SE activities that support a business' needs and deliver intended value are enabled by many factors, such as the organization's culture (See Culture), SE competencies (See Determining Needed Systems Engineering Capabilities in Businesses and Enterprises), SE tooling and infrastructure, and how the organization grows and deploys its workforce in order to arm it with those competencies. There are as many different ways to enable SE performance as there are organizations, and every organization's approach is highly detailed and unique. Nevertheless, the many common practices, methods, and considerations that organizations use can provide a framework to structure the relevant knowledge. Part 5 discusses those enabling common practices and methods of businesses, teams, and individuals, and begins with an articulation of strategies that enable SE to be performed well by a business. Specific tools and information technology infrastructure to perform SE are not discussed here, but are addressed in Part 3: Systems Engineering and Management.
References
Works Cited
None.
Primary References
None.
Additional References
None.
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