Systems Engineering Organizational Strategy
THIS WILL BECOME A TOPIC IN THE KA: ENABLING SE IN BUSINESSES AND ENTERPRISES
Virtually every significant business or enterprise that creates products or services benefits from performing a wide variety of systems engineering (SE) activities to increase the value that those products and services deliver to its owners, customers, employees, regulators, and other stakeholders. (A business is a specific type of enterprise, usually a legal entity with a management structure that allows for relatively tight control of its components, including how it enables SE. The term business is often used in this article in lieu of enterprise because specific actions to enable SE are typically done by businesses. This is discussed further in the parent article Enabling Systems Engineering.) How the enterprise goes about organizing to conduct SE activities is important to their effectiveness. For example, every enterprise has a purpose, context, and scope determined by some of its stakeholders and modified over time to increase the value the enterprise offers to them. Some enterprises are for-profit businesses. Still others are not-for-profit businesses that work for the public good. Still others are not traditional businesses, but more loosely structured entities without legal structure, such as a national healthcare system. Some enterprises have a single site, while others are far-flung "empires" with locations around the globe. Some work in highly regulated industries such as medical equipment, while others work with little government oversight and can follow a much wider range of business practices. All of these variations in the purpose, context, and scope of an enterprise shape the strategy for performing SE. The Systems Engineering Organizational Strategy Topic explores how an enterprise establishes its organizational strategy for SE and how that strategy is implemented.
To download a PDF of all of Part 5 (including this topic), please click here.
Primary Considerations
SE business strategy is properly driven by the goals of the business and the resources and constraints available to achieve those goals. SE strategy in particular is influenced by several considerations, especially:
- The purpose of the business
- What value the business offers its stakeholders; e.g., profits, public safety, entertainment, or convenience
- The characteristics of the system which the SE activities support; e.g., the size, complexity, primary design factors, major components, required products, critical specialties, or areas of life cycle
- The phases of the life cycle in which the SE activities are being performed; e.g., development, deployment, operations, or maintenance of a product or service
- The scale of the business and the systems and services of interest; e.g., is it a single site company or a global venture? Is the business creating a relatively modest product for internal use, such as a new Web application to track employee training, or a new hybrid automobile complete with concerns for engineering, manufacturing, servicing, and distribution?
- The culture of the business in which the SE activities are performed; e.g., is the business risk-averse? Do people normally collaborate or work in isolated organizations?
- The business structure and how well the current structure aligns with what is needed to create new products and services; e.g., does the structure of the business align with the architecture of its major products and services?
- The degree of change or transformation that the business is undertaking in its operation, products, and markets
Rouse (2006) offers a thorough look at enterprise strategy, especially as it relates to delivering value to the enterprise in various phases of the life cycle, beginning with research and development through operations. Rouse provides a number of techniques to determine and improve the value offered to enterprises using SE methods, especially useful when an enterprise is undergoing significant transformation rather than conducting "business as usual"; e.g., the enterprise could be trying to:
- Do current business better; e.g., drive down costs or improve quality of its current products and services
- Cope with a disruption in the market, a competitive threat, or changing customer expectations and ways of doing business
- Reposition itself in its value chain; e.g., move from being a part supplier to a subassembly supplier
- Launch a new generation product, or enter a new market
The organizational strategy for SE could vary significantly depending on the degree of transformation the business is undertaking. Eisner (2008) provides a thorough look at different SE organizational approaches.
Systems Engineering Strategy Elements
Based on these primary considerations, the SE strategy generally addresses:
- How SE activities provide value to the business (See Economic Value of Systems Engineering)
- How SE activities are allocated among the various business entities (See Organizing Business and Enterprises to Perform Systems Engineering)
- What competencies are expected from the parts of the business in order to perform these SE activities (See Deciding on Desired Systems Engineering Capabilities within Businesses and Enterprises)
- How parts of the business gain and improve competencies (See Developing Systems Engineering Capabilities within Businesses and Enterprises)
- Who performs SE activities within each part of the business (See Organizing Teams to Perform Systems Engineering)
- How people who perform SE activities interact with others in the business ((See Part 6: Related Disciplines)
- How SE activities enable the business to address transformation (See Enterprise Systems Engineering).
Depending on the business' approach to SE, there may not be a single coherent SE strategy common across the business. Different business units may have their own SE strategies, or development of a strategy may be delegated to individual projects. Often, the SE strategy is not even explicitly documented or may only be found in multiple documents authored by different groups across the business. Some businesses publish guidebooks and policies that describe their organizational strategy. These are usually proprietary documents unless the business is a government agency or quasi-government agency. Two publicly documents are available from NASA and MITRE (See (NASA 2007) and (MITRE 2012)).
Product and Service Development Models
There are three basic product and service development models that most businesses employ:
- Market-driven commercial
- Product-line
- Contract
The biggest differences between the three business models are where the requirements risks lie and how an understanding of user needs and usage environment is fed into the design and delivery process. The way SE supports the business is different in each case.
Market-driven commercial products and services are sold to many customers and are typically developed by organizations at their own risk. The requirements come from marketing based on understanding the market, relevant regulation and legislation, and good ideas from within the organization (Pugh 1991; Smith and Reinertsen 1997). (Sillitto 1999) contends that market-driven commercial product development is a form of systems engineering with adapted techniques for requirements elicitation and validation.
Product-line products and services are variants of the same product and service, usually customized for each customer. Extra investment is required to create the underlying product platform. Architecting such a platform in a way that supports cost-effective customization is usually more complex both technically and organizationally than market-driven commercial products and services. Systems engineers typically play a central role in establishing the platform architecture, understanding the implications of platform choices on manufacturing and service, etc. There are a number of examples of good practices in product line; e.g., automobile models from virtually all major manufacturers such as Toyota, General Motors, and Hyundai; Boeing and Airbus aircraft such as the B-737 family and the Airbus 320 family; Nokia and Motorola cellphones; and Lexmark and Hewlett-Packard printers. The Software Engineering Institute has done extensive research on product lines for software systems and has developed a framework for constructing and analyzing them. (Northrop et.al. 2007) For a reference on product line principles and methods, see (Simpson et al. 2006).
'Contract products and services often demand tailor-made system/service solutions which are typically specified by a single customer to whom the solution is provided. The supplier responds with proposed solutions. This style of development is common in defense, space, transport, energy, and civil infrastructure. Customers that acquire many systems often have a specific procurement organization with precise rules and controls on the acquisition process, and mandated technical and process standards. The supplier typically has much less flexibility in SE process, tools, and practices in this model than the other two.
Any single business or enterprise is likely to apply some combination of these three models with varying importance given to one or more of them.
Organizations That Use and Provide SE
There are five basic types of organizations that use SE or provide SE services. These are:
- A business with multiple project teams
- A project that spans multiple businesses
- An SE team within either of the above
- A business with a single project team
- An SE service supplier that offers a specific SE capability or service (tools, training, lifecycle process) to multiple clients, either as an external consultancy or as an internal SE function.
The kind of business determines the scope and diversity of SE across the organization. This is shown in abstract form in Figure 1, which illustrates the fundamental form of an extended enterprise. This also shows how organizational structure tends to match system structure.
The “problem owners” are the people, communities, or organizations involved in and affected by the “problem situation”. Example problems they face, and the ultimate value of the system of interest, might be to defend a country, improve transport links in a community, or deal with an environmental challenge. The “respondent system” might be a new fighter aircraft, a new or improved transportation infrastructure, or new low-emission electricity generation systems. The organizations responsible for the respondent systems would be the Air Force, transport operator or regulator, or electricity supply company. The prime role of these organizations would be to operate the systems of interest to deliver value to the problem owners. They might reasonably be expected to manage the entire system lifecycle.
This same concept is expanded in Figure 2.
References
Works Cited
Jackson, S. 2010. Architecting Resilient Systems: Accident Avoidance and Survival and Recovery from Disruptions. New York, NY, USA: Wiley.
Northrop, L., P. Clements, et. al. 2007. A Framework for Software Product Line Practice, Version 5.0. With F. Bachmann, J. Bergey, G. Chastek, S. Cohen, P. Donohoe, L. Jones, R. Krut, R. Little, J. McGregor, and L. O'Brien. Pittsburgh, PA, USA: Software Engineering Institute.
Pugh, S. 1991. Total Design: Integrated Methods for Successful Product Engineering. New York, NY, USA: Addison-Wesley.
Reinertsen, D. and P. Smith. 1997. Developing Products in Half The Time, New Rules, New Tools. New York, NY, USA: Wiley.
Senge, P.M. 2006. The Fifth Discipline: The Art and Practice of the Learning Organization, 2nd ed. New York, NY, USA: Currency Doubleday.
Sillitto, H. 1999. “Simple Simon Met A System”. Proceedings of the 9th Annual International Council on Systems Engineering (INCOSE) International Symposium, 6-10 June, 1999, Brighton, UK.
Sillitto, H. 2010. “Design Principles for Ultra-Large-Scale(ULS) Systems”. Proceedings of the 20th Annual International Council on Systems Engineering (INCOSE) International Symposium. 12-15 July 2010. Chicago, IL, USA. Also published in “The Singapore Engineer”, IES, April 2011
Simpson, T.W., Z. Siddique, R.J. Jiao (eds.). 2006. Product Platform and Product Family Design: Methods and Applications. New York, NY, USA: Springer Science & Business Media, Inc.
Smith, P.G. and D.G. Reinertsen. 1997. Developing Products in Half the Time. New York, NY, USA: Wiley and Sons.
Primary References
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.
Senge, P. M. 2006. The Fifth Discipline: The Art and Practice of the Learning Organization, 2nd ed. New York, NY, USA: Currency Doubleday.
Additional References
Northrop, L., P. Clements, et al. 2007. A Framework for Software Product Line Practice, version 5.0. With F. Bachmann, J. Bergey, G. Chastek, S. Cohen, P. Donohoe, L. Jones, R. Krut, R. Little, J. McGregor, and L. O'Brien. Pittsburgh, PA, USA: Software Engineering Institute. Accessed on September 14, 2011. Available at http://www.sei.cmu.edu/productlines/frame_report/index.html.
Chastek, D., P. Donohoe, and J.D. Mcgregor. 2009. Formulation of a Production Strategy for a Software Product Line. Pittsburgh, PA, USA: Software Engineering Institute, CMU/SEI-2009-TN-025. Accessed on September 14, 2011. Available at http://www.sei.cmu.edu/reports/09tn025.pdf
Sillitto, Mazzella, and Fromenteau. 2001. “The development of Product Lines in THALES: methods, examples, lessons learnt,” Paper presented at the INCOSE UK Spring Conference.
Simpson, T.W., Z. Siddique, R.J. Jiao (eds.). 2006. Product Platform and Product Family Design: Methods and Applications. New York, NY, USA: Springer Science & Business Media, Inc.
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 DisqusReferences
Works Cited
Eisner, H. 2008. Essentials of Project and Systems Engineering Management, 3rd ed. Hoboken, NJ, USA: John Wiley and Sons.
MITRE. 2012. "Systems Engineering Guidebook". Accessed on August 4, 2012. Available at http://www.mitre.org/work/systems_engineering/guide/index.html.
NASA. 2007. "NASA Systems Engineering Handbook". Accessed on August 4, 2012. Available at http://education.ksc.nasa.gov/esmdspacegrant/Documents/NASA%20SP-2007-6105%20Rev%201%20Final%2031Dec2007.pdf.
Rouse, W. 2006. "Enterprise Transformation: Understanding and Enabling Fundamental Change." Hoboken, NJ, USA: John Wiley and Sons.
Primary References
Eisner, H. 2008. Essentials of Project and Systems Engineering Management, 3rd ed. Hoboken, NJ, USA: John Wiley and Sons.
Rouse, W. 2006. Enterprise Transformation: Understanding and Enabling Fundamental Change. Hoboken, NJ, USA: John Wiley and Sons.
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