Open Access is an initiative that aims to make scientific research freely available to all. To date our community has made over 100 million downloads. It’s based on principles of collaboration, unobstructed discovery, and, most importantly, scientific progression. As PhD students, we found it difficult to access the research we needed, so we decided to create a new Open Access publisher that levels the playing field for scientists across the world. How? By making research easy to access, and puts the academic needs of the researchers before the business interests of publishers.
We are a community of more than 103,000 authors and editors from 3,291 institutions spanning 160 countries, including Nobel Prize winners and some of the world’s most-cited researchers. Publishing on IntechOpen allows authors to earn citations and find new collaborators, meaning more people see your work not only from your own field of study, but from other related fields too.
To purchase hard copies of this book, please contact the representative in India:
CBS Publishers & Distributors Pvt. Ltd.
www.cbspd.com
|
customercare@cbspd.com
Systems engineering (SE) and SE management is the objective of all SE efforts, which defines the transformation of specific customer needs into a system product, service, or enterprise systems. Enterprise systems of systems engineering apply systems engineering fundamentals to the design of an enterprise. It is created by knowledge, principles, and processes tailored to the design of enterprise systems. Enterprise is a complex, socio-technical system that includes interdependent resources of people, information, and technology to reach a common goal. Enterprise systems is complex that a system configuration can be controlled among the different stakeholders. There are four different steps in enterprise systems process; it includes technology planning (TP), capabilities-based engineering analysis (CBEA), enterprise architecture, and enterprise analysis and assessment. This is the main reason that the enterprise work is developed and established at HAVELSAN Inc., Information and Security Technology Division. SE and technical processes for enterprise projects require establishing a systematic taxonomy and SE process customization. This chapter presents the work done on SE for enterprise projects at HAVELSAN. The chapter presents the results of the study of similarities and differences of the various applications of systems engineering of product systems oriented against enterprise systems.
*Address all correspondence to: apahsa@havelsan.com.tr
1. Introduction
SE approach is defined as [1]: “An interdisciplinary approach to evolve and verify an integrated and life cycle balanced set of systems product and process solutions that satisfy customer needs. Systems engineering: (a) encompasses the scientific and engineering efforts related to the development, manufacturing, verification, deployment, operations, support, and disposal of systems products and processes; (b) develops needed user training equipment, procedures, and data (c) establishes and maintains configuration management of the systems; (d) develops work breakdown structures and statements of work; and (e) provides information for management decision making.”
The real-world application of SE is no different than its definition. In most practical applications, the knowledge about required product, service, enterprise, and system of systems (SoS) is mandatory for the successful project realizations.
The SoS is used in the literature since the 1950s to define systems that include independent constituent systems, which behave mutually with a common goal to establish a process. An example of SoS arises in the fields of power grid technology, transport, production, business, government, and military enterprises. SoS engineering links with independence, heterogeneity, evolution, and emergence properties of SoS. SoSs are found in wide areas. For instance, emergency response (fire, police, and hospital) with independent and managed systems never collaborates to provide a service on which trusted service is placed. Many conclusions can be drawn in Figure 1 depending on the current state of SoSE.
Figure 1.
Perspectives of systems of systems [2].
Initially the literature is fragmented. Because SoSE is in the early stages, development process is preceded on the topic [2].
SoS for enterprise systems is a group of activities related to capability delivery design and establishment in enterprise mission planning. It transforms and realizes the enterprise goals (strategic policies) into an informative and consistent Enterprise Architecture as a Strategic Plan for “System of Systems” evolution of the Enterprise. It is a general principle that organization-level transformation needs are wide and detailed. They involve specific objective in mind of the enterprise requirements and transformation of those requirements in the enterprise. Since the enterprise is a complex system of systems, it needs a SoS enterprise systems engineering method with low-risk process to devise and manage such an organization-wide transformation [3].
The SoS ESE method includes a process to manage enterprise transformation throughout three critical components. Initially it needs comprehensive, integrated, and mission-service-based architecture. Secondly, it defines a management objective for using that architecture through all organization processes of the acquisition methods to minimize risk by linking the architecture’s engineering processes to the acquisition processes. Lastly, by design it defines a flexible architecture intended to do leveraging industry best practices rather than forcing a prescriptive, one-size-fits-all of the process constraints [3].
The extent to which these combinations are selected from the previously determined approaches vs. the need for system engineers to create such combinations is part of SE application. This knowledge also lays the basis for the various application domains. Some domains have very detailed set of procedures, guidelines, and standards relevant to that domain, while others take general SE and tailor it as needed by using the judgment of those involved. In general, all domains have a little of both domain-specific guidelines and experienced people [4].
As discussed above, SE approaches transform innovations and engineering challenges into specific products, services, or enterprise systems. Based on these facts, HAVELSAN has been working on in a CMMI V3-based development product life cycle system and has been applying ISO/IEC 15288 SE standards traditional product development technical and engineering processes. Based on the structural differences in projected system needs, there exists a need to customize and develop new approaches of SE technical processes for the anticipated products and services [4] for enterprise system projects. For instance, in Information and Security Technologies Division at HAVELSAN Inc., there is more than 30% of projects that can be classified as service systems, more than 50% as product development projects, 4% as enterprise systems [5] project, and 16% as a combination of these systems. These facts require devising a new methodology of technical engineering processes for the new type of systems projects according to the ISO/IEC 15288 Systems and Software Engineering—System life cycle processes. In the following sections, fundamentals of product systems and enterprise systems are discussed, and then customized SE technical process for enterprise systems is compared against the product development SE and ISO/IEC 15288 Systems and Software Engineering technical processes. Finally, a conclusion will be provided.
As defined in finance terminology, the word “product” was first defined as in economics and commerce products belonging to broader category of goods. In marketing, a product is anything that can be offered to a market that might satisfy a customer’s needs. In retail industry, products are called merchandise. In manufacturing, products are purchased as raw materials and sold as finished goods. Commodities are usually raw materials, such as metals and agricultural products, but a commodity can also be anything widely available in the open market. In project management, products are the formal definitions of the project deliverables that constitute or contribute to deliver the objectives of the project. In insurance industry, the policies are considered products offered for sale by the insurance company that created the contract [2].
A product system is the combination of “end” products and the enabling products for those “end” products. This concept of a product is illustrated in Figure 1 of Reference 5, the ANSI/EIA 632-2003 standard. The scope of the ANSI/EIA standard is clearly restricted to product systems described in Figure 2 of [7].
Figure 2.
Product System Components [7].
The end product can be defined as a system with its own elements or subsystems, each of which has its own enabling products as stated in Figure 3 [4]. The product development process usually focuses only on the SE of the end product. Performing SE processes for “Product Systems” is essential when either the enabling products are complex or their relationship to the end product is complex. Otherwise, the use of conventional product development process is sufficient [5].
Figure 3.
End products and enabling products [4].
The processes of the SE activities are used to develop and realize the end products. Fourteen levels of technical processes are described as SE activities for product realization in ISO/IEC 15288 standards [5]. These processes are Business and Mission Analysis Process, Stakeholder Analysis and Requirements Identification Process, Identification of Systems Requirements Process, Architecture Definition Process, Design Definition Process, System Analysis Process, Implementation Process, Integration Process, Verification Process, Transition Process, Validation Process, Operation Process, Maintenance Process, and Disposal Process.
For product systems, product realization processes are applied to each operational/mission product in the system structure starting from the lowest-level product and working up to higher-level integrated products. These processes are used to create the design solution for each product (e.g., by the Product Implementation or Product Integration Process) and to verify, validate, and transition up to the next hierarchical level products that satisfy their design solutions and meet stakeholder expectations as a function of the applicable life cycle phases [8].
Enterprise systems are complex, highly integrated systems comprised of processes, organizations, information, and supporting technologies, with multifaceted interdependencies and interrelationships across their boundaries. Understanding the SE and management of complex social, technical, and infrastructure dimensions of an enterprise is critical to achieving and sustaining the enterprise performance. This section attempts to address the following questions:
What are the key attributes of a successful enterprise, both today and emerging?
What are the key concepts, elements, and interrelationships that comprise an enterprise system?
What is involved in “architecting” and “engineering” an enterprise to achieve the desired characteristics in the context of environment, business model, and associated product system? [9]
Enterprises are studied by social scientists for many years; however, according to this study, all of the perspectives against the Enterprises were only concentrated on organizational structure or the information architecture [4].
Enterprise-type projects need to be looked as a system of systems (SOS), rather than as a collection of functions connected solely by information systems and shared facilities. What differentiates the design of an enterprise system from product system lies in the inclusion of people and organization (including policies, leadership, and facility) as part of the system, but not just only including as a user or operator of the s.
Most business enterprises include one or more SoSs. For instance, most businesses have integrated many of their back office systems such as employee systems, payroll systems, and accounting systems. In addition they may also have an integrated set of customer facing systems such as order of entry, pricing systems, billing, service monitoring, inventory management, and customer help. These types of SoS tend to be relatively static in that the systems are always linked and interoperating with each other to support the organization’s key business functions [6].
Enterprise acquires or develops systems or individual elements of a system. The enterprise can also create, supply, use, and operate systems, SOS, or system elements. Since there can possibly be several organizations involved in this enterprise venture, each organization can be responsible for particular systems or certain kinds of elements. Each organization brings their own organizational capability with them, and the unique combination of these organizations leads to the overall operational capability of the whole enterprise. These concepts are illustrated in Figure 4 [4].
Figure 4.
Individual competence leads to organizational, system, and operational capability [4].
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 3 that shows all the key elements that contribute to this value creation process. These elements in the enterprise can be treated as a system with SOS perspective, where the processes, methods, and tools of SE activities can be applied to.
There are three types of organizations of interest: business, projects, and teams. A typical business participates in multiple enterprises through its portfolio of projects. Large SE projects can be considered as an enterprise in their own merit, with participation by many different business areas, and may be organized as a number of sub-projects.
Enterprise system cannot be separated from their environment and its associated product system. In studying any engineering systems, it can be seen that the product system (i.e., what gets delivered to the stakeholders) and the enterprise system are truly intertwined, along with the overall environment in which they reside. An established enterprise will innately influence any new product system that is produced by that enterprise. Similarly, the characteristics of a product system to be developed will drive the enterprise architecture toward a particular structure and set of behaviors. Moreover, in enterprise architecting, we are faced with an important consideration: how do you architect an enterprise that can most effectively produce a desired “product system”? Today we can, at best, cite heuristics and emerging principles on how enterprises should be architected. Current research in enterprise systems architecting is working toward transforming enterprise architecting from an art to a science, wherein enterprises can be predictably architected and engineered [4].
The term “System of Systems” (SOS) has been used since the 1950s to define the systems that are composed of independent subsystems, which behave jointly toward a common goal through the synergism between them. For instance, energy systems, transport, production, government, and military enterprises are examples of SoS [6].
Understanding the environment in which a system or SoS is generated and established is central to understanding how best to apply SE principles within that environment. Differences between individual or subsystem observations and SoS are given in Table 1 [10].
Table 1.
Comparing system and acknowledged system of systems [10].
Today’s requirement for more complex, more capable systems in short time is leading many organizations to the integration of new and existing systems with commercial off-the-shelf (COTS) products into network-centric, knowledge-based system of systems. With this method system, development activities to make up the new multisystem architecture, identify sources to either supply or develop the necessary components, and also integrate and test the high-level components are in development and are being defined as SoS Engineering. Many people believe that software-intensive systems are widely found in human use. It is known that the software is embedded in automobiles, household appliances, and even computers and sensors on bicycles to tell us how far we have gone and our average speed. It is also easy to see, once one understands the concepts of SoS that SoS can also be found anywhere [11].
Enterprise SE is defined as the body of knowledge, principles, and practices having to do with the analysis, design, implementation, and operation of an enterprise. In a continued changing and competitive environment, systems engineers who work on enterprise projects should consider a fundamental question: “How to design and improve all system elements associated with the enterprise through the use of SE and analysis methods and tools more effectively for achieving its goals and objectives.” In Enterprise SE, there exist three schools of thoughts:
The enterprise can be viewed as a complex system.
The enterprise is to be viewed as a system of processes that can be engineered both individually and holistically.
The use of engineering rigor in transforming the enterprise.
In the enterprise engineering paradigm, the enterprise is viewed as a complex system of processes that can be engineered to accomplish specific organizational objectives. Enterprise systems engineering recognizes the ever-changing organic nature of the enterprise and therefore has a valid worldview or paradigm.
Attempts to define Enterprise SE frequently fall back on refining previous concepts of systems integration and interoperability rather than on Enterprise SE as a whole; indeed, refining all of these concepts is useful, yet the focus is still on modeling and integrating already-existing systems or components. Because it is already stated in literature of Enterprise SE that effective enterprise integration involves not only hardware, equipment, and data but also people, technology, and business processes [12].
Enterprise SE systems thinking should cover the following aspects:
Conceptual Foundation for Enterprise SE: Considering and classifying types of enterprises and their characteristics, both as in hardware and software; drawing upon the related fields of complexity science and sociology to explain and predict the interactions between processes and the behavior of enterprises undergoing in change
Enterprise Technical Strategies: Enterprise architecture and associated frameworks (TOGAF, DODAF, Zachmann, etc.); service-oriented architectures, framework architectures, and components of systems; generic platform architectures crossing multiple systems; reusable architectural patterns; strategic management of technology; and integrated technical support environments, covering modeling, integration, and organization-level information and sharing
Enterprise Process and Management: Combination of enterprise management with organizational objectives; enterprise systems of systems engineering; agile development methods to counter uncertainty; management of programs and portfolios integrated with appropriate engineering processes; commercial policies and contract management and decision-making techniques at all levels to support the above
Organizational Design and Change Management: Shaping the organization for adaptability and to match the types of complexity involved; top down vs. peer-to-peer collaboration and governance strategies; enterprise leadership styles; implementing; sustaining and measuring change
Enterprise systems architecture is a new strategic view that creates a systems perspective, viewing the entire enterprise as a complex system encompassing multiple views such as organization view, process view, and knowledge view and enabling information technology view in an integrated framework.
According to the MITRE [9], the following process areas are applied to close the gap between the Enterprise SE and Product SE:
Strategic technical planning
Enterprise architecture modeling
Capability-based planning analysis
Technology planning
Enterprise analysis and assessment
The Enterprise SE process is shown in the context of the entire enterprise in Figure 4 [13]. The Enterprise SE processes are depicted in the middle with the business processes on the left and technical systems engineering processes on the right. In Figure 5, these business processes are described as in relation to the business activities.
Figure 5.
Enterprise systems engineering process areas in the context of the entire enterprise [13].
For HAVELSAN study projects discussed in this chapter, the following table is constructed according to the needs of the enterprise projects, including technical and SE processes, and product development project systems engineering and technical processes that are not meeting the Enterprise scope of work. Table 2 provides the basis for comparison of input/output and processes of the product, service, and enterprise SE technical processes according to the INCOSE guidelines and ISO/IEC 15288 standards.
Process no.
Project type technical processes
Product development project systems engineering technical process and outputs
Enterprise system project type systems engineering technical process and outputs
1
Business and mission analysis process
Statement of work
Technical specifications
Technical solution documents
Engineering analysis (trade-off analysis)
Regulations and/or business processes
National and international standards
Concept of operations document
Customer meeting records
Statement of work
Technical specifications
Technical solution documents
Engineering analysis (trade-off analysis)
Regulations and/or business processes
National and international technical standards
Customer meeting records
Organizational strategic plan
Capability-based planning analysis
Technology standards planning
2
Stakeholder analysis and requirement identification process
System/subsystem design model (SysML/UML, system IT models, etc.)
Data configuration lists
Interface design model (SysML/UML, etc.)
Software design model (UML, etc.)
Data model (UML)
Database design model (UML, etc.)
Hardware design model (AutoCad mechanical and design drawings, Ansys or CATIA 3D models and engineering analysis, cable/wire drawings, mass model, structure model, electromagnetic model analysis, RF propagation, communication link budget analysis, etc.)
Engineering analysis reports (trade-off analysis, safety, ergonomy, security, reliability, maintainability, survivability, availability, material and process analysis)
Enterprise architecture design model (based on TOGAF or DODAF standards, etc.)
Enterprise architecture interface design model (based on TOGAF or DODAF standards)
Enterprise architecture configuration data list
Enterprise architecture data model (SysML/UML, etc.)
Organizational enterprise architecture system model (SysML/UML, etc.)
Enterprise architecture operation model (BPM, etc.)
Enterprise architecture organization model Kurumsal (SysML/UML, etc.)
Engineering analysis reports (enterprise architecture trade-off analysis, enterprise architecture service level performance calculations, enterprise architecture service level time and human source analysis, enterprise architecture operation security analysis, service flow simulation and calculations)
In conclusion, several remarks can be made based on the results presented in Table 2. Table 2 defines the differences in the system types and explains technical engineering life cycles for each system type. The table provides data to compare the technical engineering life cycle process’s inputs and outputs according to the INCOSE SE book and ISO/IEC 15288 standards. Enterprise systems of systems engineering applies systems engineering fundamentals to the design of an enterprise. It is created by knowledge, principles, and processes tailored to the design of enterprise systems. Enterprise is a complex, socio-technical system that includes interdependent resources of people, information, and technology to reach a common goal. Enterprise systems engineering is needed when the complexity is faced which breaks down the assumptions upon which textbook systems engineering is based, such requirements being stable and well understood; a system configuration can be controlled among the different stakeholders. There are four different steps in Enterprise systems process; it includes technology planning (TP), capabilities-based engineering analysis (CBEA), enterprise architecture, and enterprise analysis and assessment.
At HAVELSAN Inc., for software product development projects, the CMMI V3-based Development product life cycle management is used. For systems development process, the ISO/IEC 15288 Systems Engineering standards are used. However, because of the structural differences required by the project’s needs for a specific system type, it is necessary to customize and develop new SE and technical approaches for the required products and services of enterprise system projects. For instance, in our Information and Security Technologies Division at HAVELSAN Inc., there is 30% or more projects classified as Service Systems, about 50% classified as product development projects, about 4% as enterprise systems projects, and 16% is classified as combination of the three mentioned systems. Our current product development technical processes are not useful enough to use them in enterprise system projects. HAVELSAN has devised a new methodology of technical systems engineering processes for the service and enterprise systems projects to accomplish customer needs and required quality assurance. Enterprise system projects require enterprise resources such as people, processes, infrastructure, and strategic objectives. To fulfill the enterprise system project requirements related to enterprise resources, one needs to define new SE and technical engineering processes. Table 1 will help system engineers to compare the enterprise system project perspectives in development stages with the product system development stages.
References
1.David ES, Michael B, Obaid Y. Systems Engineering and Program Management-Trends and Costs for Aircraft and Guided Weapons Programs. United States Air Force; 2006. ISBN: 0-8330-3872-9
2.Keating C, Rogers R, Unal R, Dryer D, Poza SA, Safford R, et al. Systems of systems engineering. Journal Engineering Management Journal. 2003;15(3):36-45
3.Carlock P, Lane AJ. System of Systems Enterprise Systems Engineering, the Enterprise Architecture Management Framework and System of Systems Cost Estimation. SoS, USCCSE; 2006. Article 618
4.INCOSE, Guide to the Systems Engineering Body of Knowledge (SEBoK), The Trustees of the Stevens Institute of Technology, Stevens, Part-4, INCOSE BKCASE, v1.7 2016
5.Cardoso J, Schmitz B, Kieninger A. Service Design - Service Research. New York, US: Springer International Publishing; 2015. pp. 325-357
6.Lane JA. What Is System of Systems and Why Should I Care? Daniel J. Epstein Department of Industrial and systems Engineering, University of Southern California, USC, CSSE-2013; 2013
7.ANSI/EIA. EIA-632, Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA); Government Electronics and Information Technology Association Engineering Department. VA, US; 2003
8.NASA. Systems Engineering Handbook, NASA/SP-2007-6105 Rev1. Washington DC, US: NASA Headquarters; 2007
9.Rebovich G Jr. Volume 2: Systems Thinking for the Enterprise: New and Emerging Perspectives. MITRE Corporation; 2005
10.Nielsen BC, Larsen GP, Fitzgerald J, Woodcock J, Peleska J. Systems of systems engineering: basic concepts, model-based techniques, and research directions. ACM Computing Surveys. 2015;48(2):18
11.Systems and Software Engineering Director, Systems Engineering Guide for Systems of Systems, Deputy Under Secretary of Defense (Acquisition and Technology Office of the Under Secretary of Defense (Acquisition, Technology and Logistics)), Version 1; 2008
12.Saenz AO, Ronald EG, Centeno M. Defining enterprise systems engineering. International Journal of Industrial and Systems Engineering. 2009. DOI: 10.1504/IJISE.2009.024155
13.DeRosa JK. Enterprise Systems Engineering. Presented at Air Force Association, Industry Day, Day 1, August 4, 2005; Danvers, MA, USA; 2005
Written By
Alper Pahsa
Submitted: 21 November 2019Reviewed: 10 December 2019Published: 07 July 2021
Open access peer-reviewed chapter
